GNOME Bugzilla – Bug 630794
The main window menu should allow acting on the selected items
Last modified: 2010-11-12 13:12:51 UTC
It isn't good that the right-click on an item is mostly the only way to act on a contact in the roster or an item in the call history.
Of course, the main window will only be able to do that when the call history and the roster widgets will make it easy to know when something is selected, so that feature depends on solving the other bugs I just added.
I just had a new look : in fact we do already have something like this. It only works for presentities, and it's hidden as a Chat->Contact submenu. Would a "Selection" submenu, with "Selection" a toplevel, be good? (aside: can I add a new string in the ui without upsetting the translators)
Ok, I made the call history view better, and already reworked the way that menu works -- that should make things pretty easy. Assigning to myself, so nobody steps on my toes.
Question : when will it be possible to rename that "contact" menu to something like "selection" -- and move it to toplevel?
If you speak about when string changes are allowed, then I say that they are allowed right now in master and for a few months. If you speak about when we should decide that such renaming can be done, then I need to think, I will reply afterwards.
I did not change the string, but mostly fixed that bug : now the menu is in toplevel, and it updates nicely whatever happens. The problem is that "Contact" was nice as long as you could only select a presentity in the roster or a contact in the call history. Now you can additionnally select a heap or a group in a heap! That name needs changing. I propose "Selection" or "Selected"... any better idea?
*** Bug 570629 has been marked as a duplicate of this bug. ***
So, how do we name that menu?
I am reluctant to change UI so easy. We must discuss UI changes before doing them, so that we can be 100% sure that they are good. I feel that currently this change is not good, we need to think more about it. I find confusing a menu whose items change based on the selection. Also, I find confusing for users to have Call in Chat menu and also in the new Contact menu. Moreover, I see in http://interface.free.fr/Archives/hig-gnome-1.0.pdf: 2.1 Do not add or remove individual menu items while the application is running, make them insensitive instead (i.e. menu items should stay unchanged) 2.2 Do not create submenus with fewer than three items, unless the items are added dynamically (i.e. submenu items can be created dynamically). Conclusion: I strongly prefer to put that menu back in Chat (even if that could change afterwards, once we agree on some other menus). It could be renamed, if you prefer, to Selection, or Selected item, or tell us if you have another name. Afterwards, this bug report could be closed. Finally, NEEDINFO is for bugs where developers need info from a *non-developer* reporter.
Just put it back there, then. The HIG is wonderful. The idea to just make the items unsensitive when not applicable is indeed much better. There is a caveat. That works when you know the full list of possible actions. If I look at my roster, I see SIP presentities, XMPP presentities and mDNS/DNS-SD presentities. Some actions are shared among those, but not all. So the idea is that we have a really dynamic menu because we deal with a really dynamic situation. Finally, NEEDINFO is when information is needed -- and those bugs marked NEEDINFO have a special meaning in the bugzilla user interface, where they are shown separately, with a "NEEDINFO by last changed" (see https://bugzilla.gnome.org/browse.cgi ). When there will be a "NEEDINFOFROMOTHERDEVELOPPER" with the same properties, I'll use that, I promise.
(In reply to comment #10) > Just put it back there, then. Could you do it please? You know that the code better than me. > The HIG is wonderful. The idea to just make the items unsensitive when not > applicable is indeed much better. > > There is a caveat. That works when you know the full list of possible actions. > If I look at my roster, I see SIP presentities, XMPP presentities and > mDNS/DNS-SD presentities. Some actions are shared among those, but not all. > > So the idea is that we have a really dynamic menu because we deal with a really > dynamic situation. We will think about that later, after the release. > Finally, NEEDINFO is when information is needed -- and those bugs marked > NEEDINFO have a special meaning in the bugzilla user interface, where they are > shown separately, with a "NEEDINFO by last changed" (see > https://bugzilla.gnome.org/browse.cgi ). When there will be a > "NEEDINFOFROMOTHERDEVELOPPER" with the same properties, I'll use that, I > promise. Developers are supposed to know all the (new) bugs, there is no need for a NEEDINFOFROMDEVS. If they do not answer, well... there is a problem with that developer, e.g. he is currently absent ; however, he must reply sooner or later. NEEDINFO is needed because users are not so responsive to bugs; it allows to track them when a sine qua non information from them is needed (and they do not answer).
I'll move that menu around later. There are a lot of bugs I'm sure concern me -- but I don't really know about them until someone says "Eh, Snark, this is for you!" and I get to know about them in my mail that way.
I pushed it deeper in the menu interface. I find it pretty inconvenient, but since it's pretty easy to fix...