GNOME Bugzilla – Bug 550939
GtkFileChooser listbox does not refresh selection
Last modified: 2009-09-21 18:45:09 UTC
Please describe the problem:
This is easily seen in gtk-demo: Start the Pickers app, and click on the File chooser. When the GtkFileChooser dialog appears, click in the file listbox. The listbox does not refresh to highlight the proper selected item.
A simple workaround is to navigate to a directory with enough file to cause the listbox vertical scrollbar to contract. With the first item selected, scroll down a bit, and press the down arrow key. They causes the listbox to scroll the selection into view, and allows the listbox to properly refresh until the dialog is closed.
No other listboxes seem to act like this. Even the listbox in the directory chooser variation of the GtkFileChooser works.
Steps to reproduce:
Does this happen every time?
I don't fully understand this bug report. Things appear to me to work fine.
Maybe you can provide a few screenshots of what you are seeing ?
Created attachment 118231 [details]
File Chooser listbox not updating
It took me a while to realize how to actually get a screenshot of this issue! Geany's file chooser helps a lot, though. It shows a few additional widgets, one being the full path to the selected item. In the attached screenshot, notice that gdkdrawable-quartz.c is shown in the path near the bottom of the dialog. This is the file that I clicked on in the file listbox. Now notice that the first item is "selected" ... it is a visual bug only, the list box display has not redrawn.
This is with a current GTK+ from SVN (and I've applied Owen Taylor's eventloop patch, which does not change the behavior of the listbox)
bash-3.2$ svn info
Repository Root: http://svn.gnome.org/svn/gtk+
Repository UUID: 7eb1c76a-c725-0410-a3b5-a37faf6256f8
Node Kind: directory
Last Changed Author: sbacher
Last Changed Rev: 21303
Last Changed Date: 2008-09-05 13:52:40 -0700 (Fri, 05 Sep 2008)
I see this too, only in filechoosers lists. I'll try to take a look.
*** Bug 559460 has been marked as a duplicate of this bug. ***
This still seems to be a bug with git master. After looking at the exposure areas it seems that the area is properly invalidated (and thus an exposure request) but the area doesn't seem to update. Perhaps that area is getting clipped somewhere down the line.
Also possibly the gtktreeview does its move operation (and exposure) to fit the new item (that is requiring the scroll) before moving the selected row and the rect invalidation is wrong on the second exposure. I can't quite tell yet from what gtkparasite shows me.
I've used my gdkrecord tool to analyze each exposure frame by frame and while not identical between x11 and quartz (font sizes, etc) they look very close. I'm going to look into seeing if the issue is related to clipping the drawing during expose next.
Checking gdkwindow moving next to see if there is an issue there. The following test exemplifies the problem, just use keyboard navigation to move through the file list. You should see portions of the selection row now being cleared as the row moves up/down.
main (gint argc, gchar *argv)
gtk_init (&argc, &argv);
dialog = gtk_file_chooser_dialog_new ("Open", NULL,
gtk_window_set_resizable (GTK_WINDOW (dialog), FALSE);
gtk_window_set_modal (GTK_WINDOW (dialog), FALSE);
gtk_widget_set_size_request (dialog, 640, 480);
gtk_dialog_run (GTK_DIALOG (dialog));
Excuse me, that is they are *not* being cleared, and should be.
Created attachment 143314 [details]
screencast exmplifying bug
sorry about the watermark in the screencast.
you can see that when the window area is moved, a portion never gets rendered after the invalidation.
Created attachment 143409 [details] [review]
call displayIfNeeded so the process_all_updates are flushed immediately
This fixes the problem. However, there may be a more appropriate place for the [impl->view displayIfNeeded];
Triggering beam sync is a sure sign that this is not the right solution. displayIfNeeded should already be invoked either within the call tree of process_all_updates or in the Quartz/Cocoa idle handler that runs after it is done.
My thought was that the window move was moving the data before the new rendered region was being flushed to the view. So instead it moves the previous contents before the render and the area that should have been flushed is covered by a future expose.
But I agree, there is probably something better that can be done.
This is visible in every tree view, not just the file selector. The expose events that tree view receives in this situation seem to be the same as in Linux -- which makes me to suspect there is some kind of ordering issue.
Okay, I think this is because _gdk_quartz_window_queue_translation() is a stub and has not been implemented. I will implement this method and see if that fixes the issue.
Created attachment 143526 [details] [review]
Okay, this took a while, I had to contemplate different approaches. This one really seems the cleanest to me. Also, it fixes the issue beautifully as far as I can see.
Anyone wants to give this some testing before I push it? Otherwise I will push it to the master branch tomorrow morning so it makes the 2.18 release.
Since this really improves stuff, I have pushed this to master so that it will be in the 2.18.0 release. If we find issues that are related later on, we can fix them then.