GNOME Bugzilla – Bug 129463
Give visual hint about why pop-up menus have big empty areas
Last modified: 2011-06-02 15:37:35 UTC
According to the discussion in bug #72695, the presence of a large empty area at the top of the pop-up menus is intentional: it allows the menu to pop up with the default option under the mouse, while still allowing some room for scrolling the other entries. But there is no visual hint that could lead the user to understand why there is a large empty area in the pop-up menus, so this has been reported several times as a bug for the GIMP (see bug #126111, bug #129416, bug #121306) and other applications (bug #72695 and duplicates). This problem could be solved by implementing something similar to what Owen Taylor suggested on 2002-02-26 in bug #72695: add an insensitive arrow at the top of the empty area, suggesting that this empty space has something to do with scrolling.
This is reported relatively frequently as a bug, so we should probably try to get this done sometime.
*** Bug 135330 has been marked as a duplicate of this bug. ***
*** Bug 136553 has been marked as a duplicate of this bug. ***
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
*** Bug 150350 has been marked as a duplicate of this bug. ***
*** Bug 150404 has been marked as a duplicate of this bug. ***
*** Bug 142868 has been marked as a duplicate of this bug. ***
*** Bug 158102 has been marked as a duplicate of this bug. ***
*** Bug 159143 has been marked as a duplicate of this bug. ***
It should probably be mentioned here that the look and feel of combo-boxes can be changed by means of editing your gtkrc (or by using a theme that uses the other style): style "default-style" { GtkComboBox::appears-as-list = 1 } class "GtkWidget" style "default-style"
Perhaps it would also be good to merge the following change from the HEAD branch: Sun Sep 19 23:56:18 2004 Søren Sandmann <sandmann@redhat.com> * gtk/gtkmenu.c (MENU_SCROLL_TIMEOUT2): Change from 50 to 20 to make the menus scroll faster. This is IMO a great improvement for the usability of combo-boxes with many items.
I have applied this change in my gtk+-2.4 tree and it works flawlessly. Not very surprising since it's a very simple change. But it appears to be a great usability improvement. I would thus like to get your approval to commit this to the gtk-2-4 branch: Index: gtk/gtkmenu.c =================================================================== RCS file: /cvs/gnome/gtk+/gtk/gtkmenu.c,v retrieving revision 1.168.2.10 diff -u -p -r1.168.2.10 gtkmenu.c --- gtk/gtkmenu.c 17 Nov 2004 20:53:01 -0000 1.168.2.10 +++ gtk/gtkmenu.c 29 Nov 2004 10:07:13 -0000 @@ -59,7 +59,7 @@ #define MENU_SCROLL_ARROW_HEIGHT 16 #define MENU_SCROLL_FAST_ZONE 8 #define MENU_SCROLL_TIMEOUT1 50 -#define MENU_SCROLL_TIMEOUT2 50 +#define MENU_SCROLL_TIMEOUT2 20 #define ATTACH_INFO_KEY "gtk-menu-child-attach-info-key"
I committed that change.
The latest OS X version doesn't have the weird blank area anymore, so the apple-does-it-so-it-must-be-right excuse doesn't apply anymore. Can't we just have the menu pop up below (or above, if there isn't room below) the button?
IMHO there are good reasons for the current behaviour. People who would like to see a list of options instead of a menu with the current choice under their mouse can change the combo-box to appear-as-list.
*** Bug 160647 has been marked as a duplicate of this bug. ***
A great usability improvement would be not use Combobox when there are many options (more then 5 or something). The GtkComboboxEntry would be much more apropriate with many options. But that doesnt mean that you guys should not patch the GtkComboBox to not have that big empty space which is so ugly and surely does look like a bug to most users (as can be seen by the large number of duplicate bug reports).
Created attachment 35251 [details] [review] a patch Here is a minimal patch which displays the scroll arrow at the "empty" end of a pushed in menu.
Created attachment 35350 [details] a screenshot
If i click the combobox its because i want to change the option. If i quit the idea of changing the option i would click outsite the menu items.. Makes sense doesnt it? Let's forget the idea of "MacOS does it so lets do it too". The current behaviour is just sooooooo ugly and the current solution continues to be ugly. Its not just about being ugly, but why would i want the current item to be selected? it's not helpful. Seriously, name a use case that it would be handy? Like i mentioned above, if i click the combo its because: 1 - I want to see what other options i have 2 - I want to change the option For 1 i just can click outside the menu list and dont change the option For 2 i just click the new option (1 can become 2 if i see a better option) The current solution is just for 1 in the case that i just want to see the other options but i dont find any better option so i continue with the current one. This can be done, again, clicking outside the menu. I Hope this gives you guys some ideas.. :)
I agree with sayao, it is only occasionally useful for the default option to automatically be placed under the mouse cursor. I had submitted a bug report because I didn't understand the behavior, but now that I know the purpose I still find it slightly irritating to have to scroll the list to see my options. It saves more time to see the list in its entirety than to have the mouse cursor closer to the most likely option. Just my personal opinion..
I really hate this behavior. Thought it was some serious bug for the longest time. Read comment 21. This behavior is really annoying. If I click a combobox, I want to change the option or see my other options. In either case, this behavior really wastes my time, because I have to scroll to do either, and those little arrow scrollbars are really slow and hard to use (They're kind of small too, so if you wave your mouse around, they're hard to use when you're doing things fast). The appears-as-list works, but it changes how the developer intended things to look. Besides, I don't like the white background, engrave look, etc. Also, most importantly, it doesn't work for any application that still uses the GtkOptionMenu, and there are a lot of those. In fact, even Gedit uses it, even though its been deprecated. (If you don't believe me, try to save, and the encoding box uses it). I don't think I'm skilled enough to patch these things, but I could try. I just need someone to tell me where to look.
*** Bug 165227 has been marked as a duplicate of this bug. ***
The patch for GtkOptionMenu has been sumbitted at bug #153829.
*** Bug 167096 has been marked as a duplicate of this bug. ***
*** Bug 169212 has been marked as a duplicate of this bug. ***
Well said in comment 23. Seeing the full list of choices is more important than presevering the currently selected item. What's so frutstrating is I have to hover and wait a few seconds for the right option to scroll into place. How do I get the workaround in comment 11 to work? If I place it it my .gtkrc file, I don't get anything. Do I need to log our or restart the X session?
*** Bug 169305 has been marked as a duplicate of this bug. ***
*** Bug 172886 has been marked as a duplicate of this bug. ***
*** Bug 303384 has been marked as a duplicate of this bug. ***
*** Bug 304229 has been marked as a duplicate of this bug. ***
Created attachment 47137 [details] Screenshot OK, I am not a GUI guru, so someone please tell me, what is better in the left screenshot, that in the right "screenshot" ? I don't see any difference, except a big bug-looking empty space. (the right part was hand-drawn, obviously) PS: Why is the width of the menu not the same as the width of the button ?
*** Bug 308285 has been marked as a duplicate of this bug. ***
sven@gimp.org : "IMHO there are good reasons for the current behaviour." What reasons ? Currently I read : - the current selection is under cursor - this can be done without a big empty part (for example, see my picture above) - MacOS did it like this once - huh !? - some good reason, but I can't tell you - really ? As you see, there was no real explanation why the current behavior is good. Is it an implementation problem to change it ?
*** Bug 309976 has been marked as a duplicate of this bug. ***
*** Bug 315107 has been marked as a duplicate of this bug. ***
*** Bug 319018 has been marked as a duplicate of this bug. ***
*** Bug 324403 has been marked as a duplicate of this bug. ***
I really don't understand you. You're all sick. This is not ok, it's a BUG. It's annoying and ugly.
Insults won't help fixing this.
Ok sorry. But i just don't understand how you developers actually claim it is a wanted feature whereas other people consider it as a bug. It is 2 years old report, no move since then. I guess it wouldn't be a problem to fix it but the problem is you are persuaded it is not bug. Why don't you change your mind?
Would a patch that simply doesn't have this empty area be accepted by the maintainers of GTK??
The NeXT used something like this [item1 ] Pick an option: [curr_item ] [ \/ ] ------------------------------ bottom of screen Moving the mouse over the arrow would make the menu slide upwards, showing you the rest of the items. A patch for that would be very nice.
(In reply to comment #44) > > Moving the mouse over the arrow would make the menu slide upwards, showing you > the rest of the items. A patch for that would be very nice. > Frederico, I agree. Does this also mean that a patch (assuming the code is of good quality) implementing that will be accepted? Otherwise somebody is putting energy in it and if in the end it does not get accepted it will lead to frustration.
I don't see a reason to reject such a patch. Once you have implemented it, could you run a little usability test on a friendly passer-by? Let's see if they can figure out that they need to move over the arrow to get the extra menu items.
Check out the patch in bug 323028 That will likely make it into 2.10 in some form
*** Bug 328315 has been marked as a duplicate of this bug. ***
The latest version of the patch in bug #323028 does actually fix this problem.
Fixed in CVS: 2006-02-22 Michael Natterer <mitch@imendio.com> * gtk/gtksettings.c: added boolean property gtk-touchscreen-mode, which essentially means "there are no motion notify events", so widgets can't use the pointer hovering them for anything. * gtk/gtkmenu.c: if gtk-touchscreen-mode is TRUE, scroll menus when clicking the scroll arrows, since hovering goes undetected. Fixes bug #323028. Added boolean style property "double-arrows" which always makes both scroll arrows visible when the menu is too long. For pushed-in popup menus, both arrows are always shown (regardless of double-arrows), in order to fix user confusion about the blank area. Fixes bug #129463.
*** Bug 340587 has been marked as a duplicate of this bug. ***
For what reason was it decided that gtk would draw part of the menu offscreen, when the blank space it leaves above the first entry would be sufficient to store the entire menu?
if you cared to read the bug report you are commenting on, you would be able to find the original reasons for the current behaviour.
If gtk developers looked at Qt how UI should be drawn we wouldn't have to deal with problems like this one. GTK Combo box is the worst widget ever. I mean it seriously. Don't take me wrong, I'm just expressing what me and other users dislike.
good that this bug is already closed. otherwise I would be tempted to WONTFIX it at this point.
*** Bug 438026 has been marked as a duplicate of this bug. ***
*** Bug 382291 has been marked as a duplicate of this bug. ***
*** Bug 468172 has been marked as a duplicate of this bug. ***
But if the user has clicked on a combo-box, doesn't he/she already know the default option and probably intends to change it? Anyway aren't there prettier ways to indicate the default option? You could use a special font, a different background, some special decoration on the combo-box, even move the mouse pointer. I remember this from Fedora Core 3 and have always considered it to be a rather ugly bug. I'm sure that many other users feel the same.
*** Bug 362483 has been marked as a duplicate of this bug. ***
*** Bug 482592 has been marked as a duplicate of this bug. ***
*** Bug 505118 has been marked as a duplicate of this bug. ***
And here's the next : http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2258
*** Bug 553480 has been marked as a duplicate of this bug. ***
*** Bug 344220 has been marked as a duplicate of this bug. ***
*** Bug 568333 has been marked as a duplicate of this bug. ***
*** Bug 559775 has been marked as a duplicate of this bug. ***
*** Bug 630557 has been marked as a duplicate of this bug. ***