After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 528811 - should not keep file-chooser dialogs around
should not keep file-chooser dialogs around
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal minor
: 2.6
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-04-18 20:10 UTC by Sven Neumann
Modified: 2008-11-24 05:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
destroy file dialogs when they are closed (5.59 KB, patch)
2008-04-18 20:11 UTC, Sven Neumann
none Details | Review
patch that I ended up committing (7.73 KB, patch)
2008-05-08 11:30 UTC, Sven Neumann
committed Details | Review

Description Sven Neumann 2008-04-18 20:10:11 UTC
GIMP currently keep file-chooser dialogs around and only hides them when the user closes the dialog. The idea was that the dialog should reappear in the same state it was closed. Another reason was that opening the file-chooser dialog used to be slow.

It appears that this behavior of GIMP causes quite some problems. We have had several bug reports where GIMP crashed in file-chooser code while the dialog was hidden. Other users are reporting that the dialog is slow to open on second use (bug #527644). It seems that reuse of the dialog is an uncommon code-path which is likely to have bugs. It would probably be a good idea to change this.

I will attach a patch that changes the code to destroy the dialogs when the user closes them. There are probably some more changes needed to get reasonable behavior, such as remembering the folder the dialog was last used in.
Comment 1 Sven Neumann 2008-04-18 20:11:05 UTC
Created attachment 109505 [details] [review]
destroy file dialogs when they are closed
Comment 2 Sven Neumann 2008-04-18 20:12:23 UTC
It would help if we could get a clear definition of how the file dialogs should behave. Perhaps Peter can help with this?
Comment 3 Sven Neumann 2008-04-18 21:18:37 UTC
I am asking for advice here because we had tons of bug reports in the past from users demanding changes to the behavior of the file dialogs. See for example bug #481002. Note that this is not the only report. Other users asked for different behavior so this is probably difficult to get right for everyone.

But I have the impression that we received less such complaints in the past. So perhaps it would be best to stick with the behavior of GIMP 2.4...
Comment 4 Michael Natterer 2008-04-19 09:26:17 UTC
That patch doesn't quite work since we still need to attach
the save dialog to the image to make sure we don't open two
of them. Most of the code can probably stay as-is.
Comment 5 Sven Neumann 2008-05-08 11:30:35 UTC
Created attachment 110576 [details] [review]
patch that I ended up committing

I have done some changes to this. The save dialog is now kept attached to the image while it is alive. This makes sure that there is only one save dialog opened per image. I also added some infrastructure to keep a persistent state of some aspects of the file-chooser dialog. So far only the selected filter is being stored there, but we could easily add other stuff.
Comment 6 Sven Neumann 2008-05-08 11:31:16 UTC
2008-05-08  Sven Neumann  <sven@gimp.org>

	* app/widgets/gimpfiledialog.[ch]: added infrastructure to access
	and set some state information of the GtkFileChooser.

	* app/dialogs/file-open-dialog.c
	* app/dialogs/file-save-dialog.c: don't keep the file-chooser
	dialogs around. Instead keep the state attached to the Gimp object
	(one state for load, one for save dialogs). Closes bug #528811.
Comment 7 Ari Pollak 2008-11-24 02:23:41 UTC
Is this too much of a change to apply to the 2.4 branch?
Comment 8 Martin Nordholts 2008-11-24 05:59:23 UTC
The 2.4 branch is unmaintained and no more 2.4 releases will be made, so it doesn't make sense to apply it there. You could however of course look up what revision that above commit corresponds to and maintain a separate patch if you want to have this change in a 2.4 build.