Re: Gtk::FileChooserButton

I know this won't help much, but when writing new app, I wouldn't bother to use gtk2 anymore and I would use gtk3 instead.

Anyway, you could always just destroy the whole dialog and create it anew so that the file won't be selected.

On 04/29/2011 07:54 PM, John Emmas wrote:
I've been experimenting with this for a few hours now.  AFAICT there's a very significant difference in the 
way a Gtk::FileChooser dialog works in Windows, compared to its operation in Linux.  Here's what I found:-

1)  Launch a Gtk::FileChooser from a  Gtk::FileChooserButton.  Select a file and click "Open".  The chosen 
file becomes the currently selected filename.  In other words, Gtk::FileChooser::get_filename() returns the path to the 
chosen file.

2)  The above path name is persistent.  If I re-launch the same FileChooser dialog, the previously selected 
file is preselected when the dialog re-opens.

3)  After re-opening the dialog, select an empty folder and press 'Cancel'.  In the Linux version this has the effect 
of removing the previous selection.  In other words the original Gtk::FileChooserButton goes back to displaying 
"(None)" and Gtk::FileChooser::get_filename() returns an empty string.  However, this doesn't seem to be the 
same in gtk-win32.  After selecting an empty folder and pressing 'Cancel' the original Gtk::FileChooserButton still 
displays the previously chosen filename and Gtk::FileChooser::get_filename() continues to return its path.

I could delve into this a bit further during the next day or two but I'd be interested to know which is the 
intended behaviour.

In Windows I'm building with gtk version 2.20.0.  My Linux version is slightly older - around 2.18.  Is it 
possible that the behaviour got changed somewhere between them?

gtk-app-devel-list mailing list
gtk-app-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]