Wireshark-dev: Re: [Wireshark-dev] Issues with most usage of GtkFileChooserDialog ?
From: Stephen Fisher <steve@xxxxxxxxxxxxxxxxxx>
Date: Wed, 20 May 2009 16:44:33 -0600
On Wed, May 20, 2009 at 12:46:29PM -0400, Bill Meier wrote:

> A simple example:

> You'll now have what I'll call a dead File Chooser dialog window. That 
> is: clicking on the Cancel or the Open buttons in the Window does 
> nothing.

> (The window is not completely dead: Clicking on the upper right does 
> delete/destroy the window).

Ah, I see that too now.  I can still select filenames and double 
clicking on them "pushes" the open button, but like you say nothing 
happens unless I close the window with the red x (X11 on MacOS X in my 
case).

> The issue exists for many of the cases where GtkFileChooser is used 
> and the callback throws up an alert box or similar.

> The issue:
> 
> The original code (in various dialogs) using GtkFileSelection treated 
> the file selection window as a "regular" window (what's the correct 
> terminology ?) and attached callbacks to the OK button and etc. The 
> event handling was then done via the main loop.

Ok..

> Later code using GtkFileChooserDialog instead of GtkFileSelection uses 
> gtk_dialog_run and so on to do the event handling. This doesn't work 
> well if the callback wants to pop up an alert box but leave the file 
> chooser window up for further action.

So it works fine if we're using the main loop in this scenario?

> ((
> Digging a bit deeper: I see that file_selection_new() used by
> File ! Open was changed years ago to use GtkFileChooserDialog and 
> gtk_dialog_run instead of  GtkFileSelection & etc.

I see that GtkFileSelection is deprecated.

> Has this issue been present in File ! Open all that time ??

Probably.. it's amazing how some bugs aren't noticed for a long time.

> My thought:
> 
> Change usage of GtkFileChooserDialog to use a GtkFileChoserWidget in a 
> window with OK and Cancel buttons;

I'm not that familiar with the differences between the two other than 
what the GTK docs say:

GtkFileChooserDialog - A file chooser dialog, suitable for "File/Open" 
or "File/Save" commands

GtkFileChooserWidget - File chooser widget that can be embedded in other 
widgets

So would you be creating a dialog and packing with a 
GtkFileChooserWidget and widgets for the other options on the window?  
Is that different then from extending the GtkFileChooserDialog (which is 
what I assume we do now).

> Change the users of the file chooser to go back to the original way 
> for attaching and handling the callbacks. (That is: don't use 
> gtk_dialog_run & etc).
> 
> Doing this change for all the current usage of GtkFileChooserDialog 
> (10-15 instances ?) would be a bit of work, but I don't think it's too 
> bad.
> 
> Doing things this way means that all the code written with the 
> assumption that alert boxes can be popped up and etc would work again.

Great!

> What am I missing ?  Are there problems with the above approach ? Are 
> there other possible solutions ?

I haven't looked at that code much before, but I can't think of anything 
to be concerned about when doing it this way.

> 1. I would then try implementing the above for one of the dialogs.
>
> This should take less than a day.
> 
> 2. I would then commit the changes for others to look at.
> 
> 3. If Ok, the required changes for the rest of the 
> GtkFileChooserDialog could then be made.

Sounds good to me.


Steve