GNOME Bugzilla – Bug 559775
The menu-style GtkComboBox has a big blank area above the position of its control in the app
Last modified: 2010-06-08 05:54:03 UTC
Please describe the problem:
I have a combo box to which I add about 150 entries, and I see that the look of the combo box has changed between these releases. With GTK 2.12.3 when the list opened it would extend from its location in the app up to the top of the screen, and would have a traditional scroll bar on its right side.
With GTK 2.12.12 and 2.12.14 it extends all the way from to top bottom of the screen and has separate scroll-up and scroll-down arrows at top and bottom.
The problem is that when the list in the new version first opens, entries are only populated in the bottom half of the visible list area, from the position of the control in the app down. The top half from there to the top of the screen is empty - a big blank area. If I scroll down, the entries scroll up into that area, and once I've scroll far enough for them to reach the top, then it is OK and the blank area is gone (if I scroll back up it does not reappear).
I see this with with GTK 2.12.12 / Glib 2.16.6 in my Fedora 9 Linux system and with GTK 2.14.4 / GLib 2.18.2 in Windows, but not with GTK 2.12.3 / Glib 2.14.4 which is the previous installation that I have on Windows.
Steps to reproduce:
1. Run a program that has a GtkComboBox with a lot of entries (or the attached test program).
2. Open the combo's list and see how it is displayed.
3. Press the "Up" cursor key. This causes the combo list to wrap down to the end.
4. Press the "Down" cursor key. This causes the combo list to wrap back up to the start. Now the entries are properly displayed from the top of the list.
5. Close and reopen the list so the blank space is back.
6. Mouse over its bottom scroll arrow so it scrolls up until the blank area has gone.
7. Mouse over its top scroll arrow so it scrolls down. It stops when the 1st entry comes into view at the top and the blank area does not come back.
From the position of the control in the app upwards is empty - a big blank area.
Entries should appear from the top of the list when it opens.
Does this happen every time?
I posted this on the GTK email list and this was sent in reply:
2008/11/6 Carlos Pereira <email@example.com>:
> I use ubuntu 7.10 (dont know gnome version, sorry), and allways see
> this behavior, when I use "brasero".
Created attachment 122193 [details]
Small program that demos the problem
I've attached a small program that demos the problem.
Created attachment 122194 [details]
Screenshot of the problem in brasero
I've attached a screenshot of the problem in brasero (from Carlos Pereira).
A correction. In paragraph 1 of Comment #1 I said that the style of the combo box had changed between GTK 2.12.3 and 2.12.12, and in the 3rd paragraph I said that I don't see the problem with 2.12.3. In fact I hadn't realized that the list type (menu or list style) was themeable, and my 2.12.3 installation had the Windows theme selected which my 2.12.12 installation did not, hence the difference.
So this problem is only with the menu-style combo, and it shows up with GTK 2.12.3 too.
This bug can be reproduced on OpenSolaris too.
I've been doing some debugging, and the problem comes down to how the GtkComboBox sets the "y" and "push_in" values when its GtkMenuPositionFunc "gtk_combo_box_menu_position_over" is called. I found that it was setting "y" to the vertical position of the combo box control on the screen (i.e. to about 400 when its about 400 pixels from the top of the screen) and setting "push_in" to TRUE. I've attached a 2nd small test program that uses a GtkMenu and does the same, and it exhibits the same behavior.
The test program has 4 buttons which cause return of these values from its
1: y = 0, push_in = FALSE
2: y = 0, push_in = TRUE
3: y = 400, push_in = FALSE
4: y = 400, push_in = TRUE
Only the last combination shows this undesirable behavior.
I think that the bug is actually in GtkMenu rather than in GtkComboBox.
Created attachment 122630 [details]
Small program that demos the problem using GtkMenu
Created attachment 122651 [details] [review]
Don't "push in" when positioning the menu
Thanks for investigating. I personally find this issue very annoying and I see it often enough.
The attached patch sets push_in to FALSE. I lack the understanding of GtkMenu to estimate if it is actually broken and this works perfectly for me.
Created attachment 122714 [details] [review]
Patch to gtkmenu.c
I've now got to the bottom of where the problem is. It is in function gtk_menu_position() in gtkmenu.c, in the "if (private->initially_pushed_in)" case at line 4164. The menu list is initially position with its top at the location of the control embedded in the app (so that it drops down from there). But when the menu is too long and "push-in" is set, this code first moves the menu up so that it doesn't extend past the bottom of the monitor, and then moves the menu's top down so that it isn't above the top of the monitor.
The problem is that while doing that it adjusts a "scroll_offset" to implement this (quoted from the manual): "moving and possibly resizing the menu around will alter the scroll position to keep the menu items "in place", i.e. at the same monitor position". So in this case the first menu item stays at its original position where the control is located, which means that we get a -ve scroll_offset value and the blank area above it.
I believe that not moving the menu items up in this particular instance is not the desireable behavior. If the menu top is moved up above the position of the first menu item, then the menu items should move up to avoid this blank area, and that can easily be achieved by preventing scroll_offset from going -ve.
I've attached a patch to gtkmenu.c that makes that change (and adds some comments to the piece of code too).
The same for the Clock Applet when choosing the Locations.
Created attachment 128219 [details]
The problem in Tasque at the bottom of the screen
The issue also appears in Tasque, when the window is placed at the bottom of the screen and user wants to change a task's date.
Can't wait to get this fixed, as Christian Dywan said it's very annoying.
This is not a bug, but by design. See bug 129463 and its many duplicates.
Than presumably it's a bug *in design*.
In the bug you point to, Panayiotis made a good comment:
"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?"
That's exactly the situation! When I click a date's box in Tasque, all I want to do is to choose a date. I don't want to scroll anything.
Ovidiu Gheorghioiu (2002-03-23) also pointed to the desirable solution:
"I think the widget should *try* to keep the currently selected item
under the cursor, but not at the expense of displaying fewer items."
The blank area just make user feel that the application is corrupted.
In other words:
You claim to support and empower the user when she wants to make a choice, but you may end up hiding 90% of available options, when there is a plenty of space to show them.
When the user clicks the combo, she knows what was selected. When there is a space, placing this item under the mouse cursor is nice, but she already has the item in her short-term memory, so it isn't something necessary. And then, if she wants to abandon the choice and leave the option as it was, she would probably press Escape or click at some point on the screen other then the menu.
There is something wrong in this design :) As it was shown, it certainly fails to assist the user in some corner cases (long lists, widget at the bottom of the screen). Instead of "being invisible", as a good interface should be (users are then able to focus on their work), it disrupts their workflow, making them think "why the big ugly space is there?" and forcing to scroll, in order to make a good choice.
Please take some perspective at the problem :)
> This is not a bug, but by design. See bug 129463 and its many duplicates.
This is a bug. If it is by design then the design is wrong - the half empty list looks horrible.
The fact there are many duplicates of the bug report should tell you something.
(In reply to comment #15)
> > This is not a bug, but by design. See bug 129463 and its many duplicates.
> This is a bug. If it is by design then the design is wrong - the half empty
> list looks horrible.
> The fact there are many duplicates of the bug report should tell you something.
I agree. The design is horrible. Why does people want to draw a blank space on his screen which contains nothing?
Is there any problem with the patch suggested or why hasn't this been committed?
*** This bug has been marked as a duplicate of 129463 ***