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