GNOME Bugzilla – Bug 374871
If Combobox menu must scroll, it creates blank space above/below the items
Last modified: 2018-05-02 14:22:53 UTC
If the combobox is placed in the bottom of the screen, it hides the entire content of the box. I know that this is made, so that the current selected item is places at the cursor, but as shown in the screenshot, it really makes it much less usable in some contents. I think that making an exception to the above rule, when perhaps more than 50% is hidden, would be worthy to consider. Other information:
Created attachment 76523 [details] Shot of the gimp, with 100% height budylist
I think it is a bug as well. It frustrates me every time I change status in gajim. It just looks very strange to have a lot of lines empty in the upper part of the box. I would appreciate if a combobox looked like after scrolling it down manually by default if it does not fit into the screen.
Created attachment 108232 [details] How it looks like in gajim
I understand why the blank space is left there. So when you scroll from the current item down, it has space to scroll into, but is there someway that the blank space could be made invisible or the menu window (the thing that holds the menu) be resized as you scroll? Having all that blank space is confusing to users (and programmers who are trying to debug their combo boxes) and not intuitive. I don't know what the limitations are the authors of GTK have to work within, but it would be nice is the blank space was invisible... looks better and would reduce confusion and frustration. Thanks for considering!
Also present with nm-applet when there's many wireless networks around. Very odd looking.
IMHO the best approach (in cases where a ComboBox is really the best widget, vs some other type of list picker widget) would be: - Automatically move the mouse cursor to keep it on top (of the previously selected item) when showing the combobox's popup menu - If the list is too long to fit on the screen height, allow scrolling, but do a best effort to scroll it as little as possible to minimize the distance delta of the mouse cursor (that would be moved as per the point above) if the list is very long.
*** Bug 622938 has been marked as a duplicate of this bug. ***
*** Bug 613312 has been marked as a duplicate of this bug. ***
Also marking bug #333470 as a requirement because my approach suggested in comment #6 will depend heavily on that not misbehaving (someone please review & merge the patch in bug #333470 anyway, it would be really awesome to merge on its own already, because it addresses the precision bug making comboboxes and menus unreliable to use regardless of scroll behavior).
> - Automatically move the mouse cursor to keep it on top (of the previously > selected item) when showing the combobox's popup menu That is not going to happen. The cursor position is under the control of the user, and we're not going to yank it around like that.
*** Bug 775783 has been marked as a duplicate of this bug. ***
*** Bug 789914 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/270.