"Christopher Curtis" <[EMAIL PROTECTED]> writes:

>> It would be nice if the proposal could keep in mind that the file
>> plug-ins are out-of-process. Thus it will be very difficult to
>> implement anything that tries to combine user interface elements of
>> the core (the file-chooser) and the plug-in.
> Actually, I did forget to mention that.  I was thinking that the GIMP
> could query the plugin for interface elements, say, in an XML format
> supported by glade.  I'm not a GTK programmer, but is there some sort
> of generic container that can be placed in the window, dynamically
> resized, and populated, eg, via libglade?

Almost everything can be done, but as long as such a framework doesn't
exist and noone volunteered for implementing it, it would be extremely
useful to come up with a proposal that respects this limitation.

> Basically, GIMP calls "plugin --get-widgets=file-save --depth=8
> --colorspace=rgba --layers=1", which returns some glade-compatible
> XML to populate the empty container on the save dialog.  ... or
> something like that.

That would work to populate the dialog, but none of the widgets would
be functional. With glade you can only describe the widgets and how to
pack them. You cannot define how they should react to user input.

> Making "Save" only handle .xcf is interesting.  Does Photoshop
> behave this way (I've never used it)?

Why should we care much if Photoshop behaves this way? The question is
whether it is a reasonable behaviour and whether it corresponds to the
user model.

I think the current behaviour is unacceptable. Currently, if you save
a multi-layered image with masks, guides, ... in the JPEG file format,
the image is marked as being saved. You can close the image and your
work is basically gone since all you end up with it that lousy JPEG
file. The user doesn't expect this behaviour.

Gimp-developer mailing list

Reply via email to