Hi,
Snipping most of this because there's not enough time :)
Raphaël Quinet wrote:
> 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).
The behaviour should be...
Save As -> Open file dialog with same setting that were used the
last time the Save As dialog was used (same as "Reshow last" for
filters).
Save -> Use the per-image parasites which were attached.
This means that if you save 2 images as jpeg through the Save As
menu item, if you changed the quality to 95 for the first, the
slider will be at 95 for the second. However, if we then reduce
the quality for the second to 70, then do a File->Save of the
first image, the quality will be at 95 for the original image,
since the parasite attached to the image trumps the last used
settings for the dialog.
Currently, if you File->Open a jpeg which was saved with 98%
quality, then File->Save, the image is unusable for printing,
since it's saved with 70% quality with no user intervention. In
this case, when saving a jpeg with no jpeg_save_vals parasite
attached, we should pop up the Save As dialog. That, or we read
the quality setting from the file at load time, rather than
attaching the default crummy quality as we do now.
One way to get the expected save as behaviour would be for a
plug-in to register the last values used with the core when it's
finishing up, and those values be sent as parameters for the next
interactive run.
> 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.
Sure, but people expect not to have to change the settings every
time - if they change the settings in the Save As dialog for a
file type, those settings are expected to stay as the defaults
for the next time they use the dialog.
> 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.
It seems to me that your idea of per-plug-in metadata tabbed
dialog thingy is a complicated interface. There is no need for
most of that stuff to be exposed, and there are potentially
dozens of tabs which would register options for it. It seems to
me far simpler to stick with the "normal" behaviour that when a
dialog pops up, the values in the dialog are the same as they
were the last time it popped up. This has the added benefit of
being easier to implement too :)
To make it persistent across sessions, we could just dump
everything into a readable gimprc file which the user could modify
afterwards if he wanted. But he wouldn't have to. And we probably
wouldn't want him to :) There would be no need, imho, to
re-complicate our newly cleaned up preferences dialog with a
50-tab "file prefereces" window.
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
