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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
