40974 - /away needs enhanced options in chatzilla (e.g. a drop-down menu)

Status: VERIFIED FIXED

(Other Applications Graveyard :: ChatZilla, enhancement, P3)

Description

[David Krause]

Overview Description:
It would be useful if the /away command in chatzilla would have several options.
 The first option should be to have the /away command send a ctcp action to the
channel announcing you are away (/me is away.)  Also, an option to change your
nick to user_away or something similar when you use /away.

Steps to Reproduce:
1) Start chatzilla
2) type /away testing away
3) observe that you are away but no one knows unless they whois you

Actual Results:
it is not announced in the channel (this should be an option though,not required)

Expected Results:
possibly announce that you are away in the channel and/or change your nick

Reproducibility:
everytime

Build Date & Platform Bug Found:
tested on 2000052919 linux but should be the same on all platforms

Additional Builds and Platforms Tested On:
none

Additional Information:
i think that changing your nick would be prefered over announcing that you are away

Comment 1

[Josh Gough]

I'll work on this in a couple days...
My idea is to allow you to specify several things:
1) Whether you want to change the nick
2) Whether to announce to the current channel
you are on / Announce to all channels on the server / make
no announcement...........

-Josh

Comment 2

[David Krause]

*MASS SPAM*

Changing QA contact on all open or unverified ChatZilla bugs to me, David
Krause, as I am now the QA contact for this component.

Comment 3

[David Krause]

Putting rginda in the CC list since I bumped him from this bug.

Comment 4

[Robert Ginda]

taking.

I'd like to make the nickname a dropdown element.  you'd get options for states
like "rginda_gone", "rginda", "rginda_home", and "new state..."

A state would include /away status (here or gone), a nickname, and something to
say to all channels on the network (either a plain message or a /me.)  Any of
the fields could be left in a "don't change" setting.

Comment 5

[Benoit]

Using an alternate nickname is _definately_ better than flooding all channels
with those "*** <nick> is away - [Back in 20mins]".

Comment 6

[timeless]

nickname changes don't work well for your average network w/ 11 character nick 
limits.

Comment 7

[David Krause]

Remove myself from QA of 33 open Chatzilla bugs and change to default QA
contact, since I have no way to verify these easily.  Still no working Mozilla
on my primary platform and it doesn't look like it will happen anytime soon. :(

Comment 8

[Ulrich Drepper]

I have one big problem with the use of nicks: each server can have a different
nick (see bug #180873).  The /away state change is supposed to affect all
servers.  How would this play together?  You might want to say 'append _away' or
'append _gone' to the server's nick but then you are in the realm of transaction
handling: if on one server the nick with the extension _away is available but on
a second server it is not you have to undo the nick change on the first server.

This problem could be avoided by enforcing the use of exactly one nick per
ChatZilla but I cannot say I like this very much.

Comment 9

[Karsten Düsterloh]

Since CZ now has visual /away feedback and both options requested here are
generally frowned upon, should this bug be WONTFIX?

Comment 10

[Prognathous]

(In reply to comment #9)
> Since CZ now has visual /away feedback and both options requested here are
> generally frowned upon, should this bug be WONTFIX?

Not really, comment #4 suggests someting very useful that *isn't* implemented:

> I'd like to make the nickname a dropdown element.  you'd get options for 
> states like "rginda_gone", "rginda", "rginda_home", and "new state..."

Any progress on this one, Robert?

Prog.

Comment 11

[:Gijs (he/him)]

We now have the possibility to change our nicks when going away. Is this enough
or do we want what rginda mentioned, the possibility to have multiple away
nicknames for several 'kinds' of away states? (Kind of like IM clients have the
'Away', 'Busy', 'Sleep', 'Lunch', 'brb' etc. )

Personally, I think what we have right now is pretty good, announcing to the
channel would be a nice thing, but when we add that it might even pay to have a
separate dialog for an 'advanced' away state or something similar :-).

Comment 12

[David Barr]

/away also doesn't have a default option. Use of 

/away

without a message always results in "You are no longer marked as away."
regardless of previous status. The only way to actually mark yourself as away is
to do

/away < message >

A default message should exist, either in the system or user-selectable, so that
actually typing in a message each time one goes away is no longer necessary.

(I'm adding this here because my thought is an RFE, not a bug, and I figure
starting a new bug would just get dup'ed to here anyway.)

Comment 13

[James Ross]

I have a patch that turns the nickname into a button w/ popup menu with
statuses. It also changes /away to use a default message when you don't specify
one, and you need to use /back to mark yourself not away (this will confuse the
hell out of most people initially, though). The popup includes "Back", "Away
(default)", "Away (custom)..." and an option to change nickname. It also
functions on the *client* tab.

Comment 14

[:Gijs (he/him)]

Dropdown nickname button is in cvs (patch was on bug 273507 and some later fixes
on bug 299454).

We also support changing nicks from that dropdown, and have a per-network pref
to change nicks when going away. Personally, I think this bug ought to be closed
as FIXED now. Reason being, spamming an away notice to every possible channel
does not appeal to me as being a good idea.

Any thoughts? :-)

Comment 15

[David Barr]

(In reply to comment #14)
> Dropdown nickname button is in cvs (patch was on bug 273507 and some later fixes
> on bug 299454).
> 
> We also support changing nicks from that dropdown, and have a per-network pref
> to change nicks when going away. Personally, I think this bug ought to be closed
> as FIXED now. Reason being, spamming an away notice to every possible channel
> does not appeal to me as being a good idea.
> 
> Any thoughts? :-)

< whine>
Well, I'd be happier if the default away message was customizable...
< /whine>

This works. I just have to remember to use the drop down list instead of /away.
I didn't submit the bug, though, so my opinion is worth what you paid for it...

Thanks!

Comment 16

[:Gijs (he/him)]

Attachment: Patch for storing the away messages in a file

Patch to store custom away stuff in a file, and load that on startup. 

Again, additional review from Silver to make sure I got everything.

As you can see from the jar.mn thing, this needs the serializer.

Comment 17

[James Ross]

Attachment: Updated awayMsgs code for new serialiser

This code uses the new ability to save an array object directly with the serialiser, and changes the client.awayMsgs array to match exactly what we want to save. The load code copes with both the original format (a sequence of objects) and the new format (a single array).

I've testing this loading the old format, and loading/saving the new.

Comment 18

[Samuel Sieb]

Comment on attachment 204288 [details] [diff] [review]
Updated awayMsgs code for new serialiser

needs an error message displayed if saving fails

Comment 19

[James Ross]

Attachment: [checked in] Updated to show error message if save fails

Comment 20

[James Ross]

Attachment: [checked in] Add messages to nickname button

This changes the nickname button menu to show the stored away messages.

Comment 21

[:Gijs (he/him)]

OK. Per discussion on IRC, we don't really like the idea of having a pref for the default away message. We do, however, want to have the nickname changing menu thing in the main menus somewhere, so it is accessible. I think we should then probably put it in the IRC menu somewhere. Taking this bug, hopefully I'll have time to fix it either in a bit or this afternoon/evening (talking CET here).

Comment 22

[:Gijs (he/him)]

Attachment: Patch to add the nickname menu to the IRC main menu

Patch that adds the menu.

While I was at it, I thought I might as well fix some other nits with the menus:
* The Help menu didn't have a placeholder, which made it not appear on XULRunner. This was clearly visible during Brian King's talk on FOSDEM (though I don't think anyone but me noticed it there). See my Flickr pictures :P
* The Help menu was semi-useless. Added a FAQ and homepage link.
* All the links spread everywhere still pointed to the ~ginda directory on hacksrus. Since we moved the homepage to chatzilla.hacksrus.com, I changed those links. I think I got everything except the ones in irc/xul/prefpanel/, which is not used anymore (are we going to keep it forever? :-) )

That's it, I think...
I must confess I was in doubt whether it'd be okay if I add my name to the list of contributors, as I was mucking around in install.rdf anyway. I decided to at least do the patch without it. :-)

Requesting review.

Comment 23

[:Gijs (he/him)]

Eh.
irc/xul/content/prefpanel/
Obviously.

Sorry for bugspam.

Comment 24

[James Ross]

Comment on attachment 213979 [details] [diff] [review]
Patch to add the nickname menu to the IRC main menu

>+         // Shortcuts to useful URLs:
>+         ["faq",              "goto-url http://chatzilla.hacksrus.com/faq/", 0],
>+         ["homepage",         "goto-url http://chatzilla.hacksrus.com/",     0],

These will fail on XULRunner.

>     client.menuSpecs["mainmenu:help"] = {
>         label: MSG_MNU_HELP,
>         domID: "menu_Help",
>         items:
>         [
>-         ["about"],
>+         ["homepage"],
>+         ["faq"],
>+         ["-"],
>+         ["about"]

On SeaMonkey (and Mozilla) we are appending to an existing menu. The new items will look out of place, and at least need a separator above them.

>+    client.menuSpecs["popup:nickname"] = {
>+        label: MSG_STATUS,
>+        getContext: getDefaultContext,
>+        items:
>+        [
>+         ["nick"],
>+         ["-"],
>+         ["back", {type: "checkbox", checkedif: net + " and !" + netAway}],
>+         ["away", {type: "checkbox",
>+                     checkedif: awayChecked,
>+                     repeatfor: "client.awayMsgs",
>+                     repeatmap: "cx.reason = item.message" }],
>+         ["-"],
>+         ["custom-away"]
>+        ]
>+    };

The items property is exactly the same as the mainmenu:nickname menu, isn't it? If so, at least share that part.

>         <!-- Help menu -->
>         <!-- Mac expects a help menu with this ID, and there is nothing we can
>              do about it. -->
>-        <menu id="menu_Help"/>
>+        <menu id="menu_Help"><menupopup/></menu>

This causes the Help menu in SeaMonkey and Mozilla to only show *our* items, and all the standard help menu items are missing.

Comment 25

[:Gijs (he/him)]

Attachment: Better Patch

Better patch.

This should fix the problems pointed out for the previous patch.

Comment 26

[James Ross]

Comment on attachment 214015 [details] [diff] [review]
Better Patch

r=silver with a short comment in the hide/show menubar hack to explain that this is to work around bug 98997.

Comment 27

[James Ross]

Checked in --> FIXED

Comment 28

[Matus UHLAR - fantomas]

just FYI: changing nickname on away is in many places considered lame (not much less abusing than flooding channels with away notices) and useless. It also broadcast over whole IRC networks instead of only those servers who have clients on the same channels behind.

What is really important, is the away status with the away message, which can users check by using /whois on you (usually remote whois, because remote servers on some networks do not know the comment).

I would better advise to focus on users using proper away comments (e.g. by removing "Away (User is away.)" button and always using popup, even with prefilled default (customized) away message.

For the comment 12: It's a definition of away command in IRC - when used without comment, it means to set user back, it only sets user away when user uses a comment.

for the comment 21: I'm really sorry to see this. Default away comment is imho much more useful than away nick option.