AFAIKT there are issues with most usage in Wireshark of
GtkFileChooserDialog.
This is true for direct usage and indirect usage via file_selection_new().
A simple example:
On a *nix system:
1. Do File ! Open and choose a capture file.
2. Enter a bad filter in the filter entry box.
3. Click the Open button in the file chooser dialog window.
4. Dismiss the resulting "Bad Filter" alert box.
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).
------
The issue exists for many of the cases where GtkFileChooser is used and
the callback throws up an alert box or similar.
A good example: rtp_analysis.c: save_voice_as_ok_cb has many uses of
simple_dialog() which will result in a "dead dialog window".
The "dead dialog window" can also occur in many cases if a directory is
chosen before clicking OK in the file chooser.
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.
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.
((
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.
Has this issue been present in File ! Open all that time ??
I would guess that the issue is now more noticeable with the various
recent changes (in code other than file_selection_new()) to use
GtkFileChooserDialog rather than GtkFileSelection .
))
------
My thought:
Change usage of GtkFileChooserDialog to use a GtkFileChoserWidget in a
window with OK and Cancel buttons;
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.
-----
What am I missing ? Are there problems with the above approach ?
Are there other possible solutions ?
If the above seems a reasonable way to go,
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.
Bill
