Hi, "Christopher Curtis" <ccurtis0@xxxxxxxxx> 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. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
