On Tue, 5 Aug 2003 11:51:05 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> wrote: > On Tue, Aug 05, 2003 at 09:45:46AM +0200, Raphaël Quinet <[EMAIL PROTECTED]> 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 _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
