After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 550939 - GtkFileChooser listbox does not refresh selection
GtkFileChooser listbox does not refresh selection
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Quartz
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-quartz maintainers
gtk-bugs
: 559460 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-05 04:10 UTC by Jason Oster
Modified: 2009-09-21 18:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
File Chooser listbox not updating (196.65 KB, image/png)
2008-09-07 15:48 UTC, Jason Oster
  Details
screencast exmplifying bug (166.79 KB, video/quicktime)
2009-09-17 01:50 UTC, Christian Hergert
  Details
call displayIfNeeded so the process_all_updates are flushed immediately (1003 bytes, patch)
2009-09-17 23:06 UTC, Christian Hergert
none Details | Review
patch (5.86 KB, patch)
2009-09-20 13:33 UTC, Kristian Rietveld
none Details | Review

Description Jason Oster 2008-09-05 04:10:30 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:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Matthias Clasen 2008-09-07 00:00:57 UTC
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 ?
Comment 2 Jason Oster 2008-09-07 15:48:31 UTC
Created attachment 118231 [details]
File Chooser listbox not updating
Comment 3 Jason Oster 2008-09-07 15:49:06 UTC
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
Path: .
URL: http://svn.gnome.org/svn/gtk+/trunk
Repository Root: http://svn.gnome.org/svn/gtk+
Repository UUID: 7eb1c76a-c725-0410-a3b5-a37faf6256f8
Revision: 21303
Node Kind: directory
Schedule: normal
Last Changed Author: sbacher
Last Changed Rev: 21303
Last Changed Date: 2008-09-05 13:52:40 -0700 (Fri, 05 Sep 2008)
Comment 4 Richard Hult 2008-10-09 11:44:25 UTC
I see this too, only in filechoosers lists. I'll try to take a look.

Comment 5 Richard Hult 2008-11-05 18:07:06 UTC
*** Bug 559460 has been marked as a duplicate of this bug. ***
Comment 6 Christian Hergert 2009-09-15 06:09:08 UTC
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.
Comment 7 Christian Hergert 2009-09-15 08:25:55 UTC
I've used my gdkrecord[1] 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.

[1] http://git.dronelabs.com/gdkrecord
Comment 8 Christian Hergert 2009-09-16 07:52:30 UTC
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.

#include <gtk/gtk.h>

gint
main (gint argc, gchar *argv[])
{
	GtkWidget *dialog;

	gtk_init (&argc, &argv);

	dialog = gtk_file_chooser_dialog_new ("Open", NULL,
			GTK_FILE_CHOOSER_ACTION_OPEN, GTK_STOCK_CANCEL,
			GTK_RESPONSE_CANCEL, GTK_STOCK_OPEN,
			GTK_RESPONSE_ACCEPT, 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_widget_show (dialog);
	gtk_dialog_run (GTK_DIALOG (dialog));

	return 0;
}
Comment 9 Christian Hergert 2009-09-16 07:53:35 UTC
Excuse me, that is they are *not* being cleared, and should be.
Comment 10 Christian Hergert 2009-09-17 01:50:42 UTC
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.
Comment 11 Christian Hergert 2009-09-17 23:06:28 UTC
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];
Comment 12 Paul Davis 2009-09-18 01:23:18 UTC
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.
Comment 13 Christian Hergert 2009-09-18 01:40:49 UTC
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.
Comment 14 Kristian Rietveld 2009-09-18 13:28:04 UTC
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.
Comment 15 Kristian Rietveld 2009-09-18 14:19:52 UTC
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.
Comment 16 Kristian Rietveld 2009-09-20 13:33:20 UTC
Created attachment 143526 [details] [review]
patch

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.
Comment 17 Kristian Rietveld 2009-09-21 18:45:09 UTC
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.