GNOME Bugzilla – Bug 113957
different applets in panel behaving diferently
Last modified: 2020-11-07 12:15:01 UTC
This enhacement will be sent too to the gnome-applets module. This bug is sent because there are several applets that behave completely different with the mouse pointer interaction, the menu bar applet shows the button appearance when clicking an option, the clock applet shows it when the mouse is over it, the volume applet shows a bavel when clicking it, the "show desktop" applet does already have button appearance. it could be much better if all the applets behaved in the same way, just to seem more consistent. I personally prefer how the menu bar buttons behave :-P
gnome-applets bug is #113958
a very good point ... cc:ing usability-maint. It probably would be good to have recommended behaviour for applets ...
The menu bar applet shows the "menu selected" highlight, whatever that happens to be. Arguably (very arguably) menus should have never looked different from buttons in the first place, but they do, and its better to keep consistency with menus than to make all the applets "consistent". Furthermore, non-menus should not use this (even if they could, which I don't know that they can). With respect to the differing behavior between the volume control and the clock.... The clock's behavior is probably smarter because it at least gives some indication that its clickable. This was probably more important in the case of the clock than with the volume control, because its less obvious that the clock is clickable (whereas the volume control looks like a launcher, and has no obvious use/mode of interaction besides clicking)... but it would be a good idea to have the volume control "button" on mouse over too (assuming this can be done without decreasing the icon size, or increasing the sizse of the smallest panel :-)
Less in the interest of consistency, and more in the interest of minimizing the number of clicks to do quick "utility" items... It would be nice if applets with "clickable to expand into something more useful" behavior like the volume control and the clock popped out on mouse down rather than on click, and then allowed continued dragging over their contents which would be activated on mouse release. For example, on the volume control, you could click and then move the mouse down immediately without releasing the button to change the slider value. To avoid sudden spikes in volume it should probably not move the slider until you move the mouse all the way over/down to the current slider value and then the slider should "grab" onto the mouse as if you had just grabbed the slider by clicking on it normally. This will allow one click volume adjustment, which is especially nice if the applet's click area is flush with the edge of the screen. On the calendar, you could click and when you move the mouse around it would change what day was selected (and presumably when you release it would have your calendar program display that day).
Some more thoughts. We have lots of varying behaviour for applets. Some have icons that expand to the panel (mailcheck), others don't change size (gweather). Some do things on double click (multiload) some are more button like(clock). Some pop something up on button press (mixer now), others on button release (clock). Some draw a little frame around the edge (multiload) and others don't (mailcheck). Some buttons only look like a button when the mouse is over them (clock), and others don't (cdplayer). I think it would be nice for some usability folks to come up with a concrete proposal for consistent behavior for the various types of applets. I'd love to go through and implement any proposal for all the applets and it would be really great to do it in the 2.4 timeframe. Also, it seems to me that launchers aren't all that different from applets. Why not include them for consistency? Should there be a difference between the panel menu, a launcher, and the clock/mixer applet?
Any news here? It'd be really great to have some guidelines so we could have real consistency.
I've got some time to spend on the HIG over the next couple of weeks, so I'd be happy to try and come up with something for discussion.
That would be great Calum. I'd love to try to implement your suggestions as soon as possible.
See also http://mail.gnome.org/archives/usability/2003-November/msg00036.html for some more feedback on applet behaviour peculiarities.
This bug is almost resolved, most applets nowadays do something on single click as well as highlight themselves in the menu highlight colour if they have a dropdown open (see menus, windows list, mixer). Clock does not highlight in blue, and instead has a raised/depressed bevel while this is a visual indication that the clock is clickable, it is inconsistant with the rest of the panel. Somewhat related, if you have clicked on one item, perhaps when you move off it onto another item the one dropdown should close and the next should open. Like happens with the menus. This is going to be a little hard to implement, and would probably require the addition of two new signals "dropdown-lost-focus" and "dropdown-gained-focus" for applets to open and close their dropdowns appropriately.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.