On Mon, 2007-06-25 at 20:15 +0100, Bartosz Kostrzewa wrote: > A couple of days ago i reported that the filechooserwidget behaves > rather unpredictably when in a GNOME session. Here's a little testcase > that reproduces the behaviour as in gimmage. > > compile and launch "./testfilechooser *" in a directory with a couple of > files > > -click apply a couple of times to trigger set_filename(), note the > output and what happens in the window, note that get_filename() does NOT > return anything!
Someone mentioned similar behaviour to me today when using the C API. Apparently some change to the async behaviour in 2.8 causes get_filename() to not immediately provide what you specifed to set_filename(). But I can't find any open bug: http://bugzilla.gnome.org/browse.cgi?product=gtk%2B You might ask on gtk-list about this. If you file a GTK+ bug then the test case should probably be in C and it needs to be much simpler. > -click remove to hide the filechooser widget from the window > -click remove again to make it reappear > -click apply a couple of times and note that the what happens in the > window does not match what is sent to set_filename(), get_filename() > still does not return anything > > again, the weird behaviour happens only in a gnome session, but > get_filename() returns an empty string even in a non-gnome session > > I use: gentoo ~x86 > GTK 2.10.13, GLib 2.12.12, gtkmm 2.10.9, libgnome 2.18.0 -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
