In another bug report (which I am having difficulty finding) a users complians of being asked too many questions during Save.

To solve this i suggested that there should be a section in Preferences allowing you to set save options on the basis that you dont need to set these options every time you save, usually you will want to use the same ones most of them.
There would also need to be an [Options] button in the save dialog to access it quickly and change a save option when needed.

I would be very much in favour of having a Prefernces section Export (and possibly Import). Hopefully I can help recommend how this might be added. I would be inclined to push the feature request to Future.

Sincerely

Alan Horkan http://advogato.org/person/AlanHorkan/

Original message included below: [and list digest options finally changed to MIME so i can reply to stuff properly in future]

From: David Neary To: Gimp Developer List
Subject: [Gimp-developer]
[FEATURE] Some plug-in settings should be persistent accross sessions Message-ID:
Content-Type: text/plain; charset=iso-8859-15 MIME-Version: 1.0
Precedence: list
Message: 11

Hi all,

http://bugzilla.gnome.org/show_bug.cgi?id=63610

Notably the Gif and Jpeg plug-ins have defaults which people change fairly frequently.

It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal preferences dialog (this might be handy enough although Sven might have something to say about it).

Basically some discussion is needed. Currently, the jpeg defaults suck. I would suggest following the advice in this bug and changing the default quality to 85%. Currently this is hard-coded in the plug-in.

If someone were to spend a bit of time figuring out how we could do this better (and reporting here, and claiming the bug) that would be great.

Cheers,
Dave.

On Fri, 25 Jul 2003 22:23:23 +0200, David Neary wrote:

http://bugzilla.gnome.org/show_bug.cgi?id=63610

[...]

It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal preferences dialog (this might be handy enough although Sven might have something to say about it).

I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface. That's why I added a dependency on bug #101604, which tracks the changes to the PDB and plug-in API.

Basically some discussion is needed. Currently, the jpeg defaults suck. I would suggest following the advice in this bug and changing the default quality to 85%. Currently this is hard-coded in the plug-in.

This is something that can be done easily. In fact, I have just done it. I have increased the default quality to 85%, which seems to be a better default for most (?) users. I have just committed this tiny change to CVS. This should take care of the most annoying part of this problem, while the bigger issues can be taken care of later.

-Raphaël

On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphaël Quinet wrote:

It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal

I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface.

Maybe I misunderstand the problem, but all perl-plug-ins can do that (and do that by default) without any extra interfaces, using parasites, for ages.

They do that by default, though, and there is no UI to decide when to save - every invocation will overwrite the per-image and global defaults for the next invocation.

For the plug-in writer this is fully transparent (if she uses Gimp::Fu).

On Tue, 5 Aug 2003 11:51:05 +0200, wrote:

On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphaël Quinet wrote:

It would be nice if preferences for plug-ins survived session changes. The way to do this might be in saving them to an rc file without providing an interface to changing them in the normal

I doubt that we can do this in the Right Way before the next release. Saving these preferences should be done by the core through a well- defined interface.

Maybe I misunderstand the problem, but all perl-plug-ins can do that (and do that by default) without any extra interfaces, using parasites, for ages.

Yes, parasites are one part of the solution.

They do that by default, though, and there is no UI to decide when to save - every invocation will overwrite the per-image and global defaults for the next invocation.

Look at the comment that I recently added in: http://bugzilla.gnome.org/show_bug.cgi?id=119032 IMHO, global parasites and immediate changes to the settings could make sense for the plug-ins that are used as filters, but not for the file plug-ins. For the file plug-ins, the settings should be a per-image property that is not affected by the changes made to the other images. Otherwise, it would not be possible to work on two images at the same time and to save them with their own settings without being afraid of having the settings of one image affecting the other one(s).

It is unfortunate that the file plug-ins and the other filters are all called "plug-ins", because they behave differently. What may make sense for the filters (global settings) may be counter-productive for the file plug-ins. For the filters, the settings can be considered to be a property of the filter itself: it is reasonable to expect that applying the same filter to a different image will use the same settings as last time. However, this is different for the file plug-ins: the quality settings, image comments and other meta-information is a property of the image itself, not a property of the filter. I expect these values to remain unchanged while I work on an image, even if I open and save other images in the meantime.

This confusion between what is the "right" behavior for a filter and for a file plug-in has caused some problems before. See for example: http://bugzilla.gnome.org/show_bug.cgi?id=75398 Although I fixed that bug last year, I think that the origin of the confusion was related to the concept of "current settings" for the JPEG plug-in. If it was clear that the current settings for the file plug-ins are per-image and not a global, then these problems would be solved.

Some settings such as the image comment and other meta-data should be available from a File->Properties dialog, not when the file is saved (http://bugzilla.gnome.org/show_bug.cgi?id=61499). This would make it more obvious that they are per-image.

In fact, the other settings related to the file format could also be dynamically registered as additional tabs in the meta-data editor. This is a bigger change that should probably be discussed this week at GimpCon, but the save plug-ins would not need their own dialogs and the Export feature could also be simplified. This would reduce or even get rid of the dialogs displayed when a file is saved (there are several bugs related to that). In addition, each tab could contain the buttons "Reset to defaults" and "Save as new defaults". The user would then understand easily when the changes are saved for later and when they are not. These buttons would only apply to the settings for the current tab, not to the whole properties. This would provide an easy way to replace the image comment of an existing file by whatever you have set as the default: you would go to the tab containing the image comment and click on "Reset to defaults" (currently, you have to copy and paste from the Preferences). If you want to set the JPEG quality to 95% for your image, you would go to the JPEG options tab, change the value and click on "Save as new defaults". The metadata dialog could pop up automatically (showing the JPEG tab) when a JPEG file is saved. Or not, if the user does not want to be bothered by this extra dialog. But it would be nice if the same dialog used for File->Properties would be re-used when saving the file. Note that I am thinking aloud here and there are plenty of details that should be ironed out (e.g., what is done by the core, what is done by the save plug-ins, how to add tabs dynamically to the meta-data editor), but this could IMHO improve the way the file plug-ins work.

For the plug-in writer this is fully transparent (if she uses Gimp::Fu).

Yes, this is nice. However, I am not sure that modifying the defaults every time (without user confirmation) is a really good idea. I would prefer this to be a conscious decision from the user. This affects the gimp-perl plug-ins only, but currently two users following the same tutorial (on the web, or printed in a book or magazine) might get different results because of what they did previously. This would be fine if they knew why (e.g., they had explicitely saved a default set of options) but this is not so obvious now.

-Raphaël

On Tue, Aug 05, 2003 at 02:03:09PM +0200, Raphaël Quinet wrote:

Look at the comment that I recently added in: http://bugzilla.gnome.org/show_bug.cgi?id=119032 IMHO, global parasites and immediate changes to the settings could make sense for the plug-ins that are used as filters, but not for the file plug-ins. For the file plug-ins, the settings should be a per-image property that is not affected by the changes made to the other images.

As I said (or wanted to say, but didn't :): the perl plug-ins do exactly that, as tehy attach themselves as global and per-image parasite.

It is unfortunate that the file plug-ins and the other filters are all called "plug-ins", because they behave differently. What may make

the problem in pelr is the UI. When I added buttons for the various options to recall defaults it became a bit complicated for the user to understand.

Your proposal to have two difefrent default strategies (not reflected in the UI of the plug-in), i.e. file == per-image and global, filters == global only (the latter is not gimp-perl's behaviour, though) might make a lot of sense without cluttering the UI.

be a property of the filter itself: it is reasonable to expect that applying the same filter to a different image will use the same settings as last time.

Personally, I think it's equally reasonable to have the same settings as used on the same image earlier, though. Both are equally useful to me.

For file-plug-ins, a fallback to the global default is also useful, although not as useful as with filters.

This confusion between what is the "right" behavior for a filter and for a file plug-in has caused some problems before. See for example:

What would be good would be a clever way to enable the user to chose, and have sensible defaults so the user need not to in most cases.

For the plug-in writer this is fully transparent (if she uses Gimp::Fu).

Yes, this is nice. However, I am not sure that modifying the defaults every time (without user confirmation) is a really good idea.

It as, at best, a good guess of what should be done. gimp-perl was mostly modelled after what other plug-ins do in the case of LAST_RUN_VALS.

different results because of what they did previously. This would be fine if they knew why (e.g., they had explicitely saved a default set of options) but this is not so obvious now.

There is always the button to reset to defaults (and another button to use the previous values). Adding more buttons was not possible (clutter), while a menu with various choices is not quick to use.

Date: Tue, 5 Aug 2003 14:03:09 +0200 From: =?ISO-8859-1?Q?Rapha=EBl?= Quinet

It is unfortunate that the file plug-ins and the other filters are all called "plug-ins", because they behave differently. What may make sense for the filters (global settings) may be counter-productive for the file plug-ins. For the filters, the settings can be considered to be a property of the filter itself: it is reasonable to expect that applying the same filter to a different image will use the same settings as last time. However, this is different for the file plug-ins: the quality settings, image comments and other meta-information is a property of the image itself, not a property of the filter. I expect these values to remain unchanged while I work on an image, even if I open and save other images in the meantime.

The Print plugin has yet another behavior; the settings are per-printer, not per-file. Conceivably they could wind up being shared with other applications that use Gimp-Print.