GNOME Bugzilla – Bug 120829
Save presets in plug-ins.
Last modified: 2018-05-24 10:54:34 UTC
In Paint Shop Pro it's possible for each plug-in to save (and load) presets. GIMP only remembers the last configuration of a plug-in, which is lost as soon as the program exits. This could be a general solution for all plug-ins, which would also fix for example http://bugzilla.gnome.org/show_bug.cgi?id=51103. I would also suggest to combine this with a 'Reset to factory defaults' (http://bugzilla.gnome.org/show_bug.cgi?id=81015)
This would be very useful we should consider it for 2.2.
Plug-ins can already choose to store settings persistently using the parasite API. I admit however that this is not a nice way of doing it. Basically what we need to solve this is the PDB rewrite we are talking about for quite a while already. I am not sure if we want this in 2.2 though.
Isn't this bug report a partial duplicat of bug #63610, which asks for plug-in settings to be optionally persistent accross sessions? This one may go a step beyond because it asks for more than one set of parameters to be saved, so if it is not marked as a duplicate, it should at least have a dependency on bug #63610 (which has already many duplicates). What do you think?
Created attachment 20826 [details] Mockup of a possible GUI for presets
The attachment I just submitted is more or less a gtk implementation of the GUI that PSP uses. It has a combobox (used in Windows, we should probably use an option menu since you can't actually type in a new entry) and three icons (Save, Delete and Set Default). In theory every plug-in for which this makes sense (for example the Convolution Matrix plug-in) could have this preset widget at the top of the plug-in UI.
Created attachment 20827 [details] Sample settings file in XML for the checkerboard plug-in
Presets could be saved in a simple XML file (see attachment).
Please note that all this is completely implemented in the core. We just need that GObject based PDB API and then move GimpConfig into a library (and probably move gimppropwidgets.[ch] into libgimpwidgets). If we decide that we prefer XML over sexp, it would be trivial to change the underlying file format of GimpConfig.
Sven: cool! I just looked into the the GimpConfig and gimppropwidgets code and that seems exactly what is needed to implement this. One question: I assume you can have multiple configurations. Are all these configurations saved in one single file or in multiple files? I would prefer the former (like in the sample XML file I attached), but it's not a big deal. Raphaël: yes, this is more or less the same as bug #63610. Two differences: 1) it also mentions an GUI with buttons to delete a setting, save a setting and revert to the factory defaults. 2) I want to be able to save multiple settings. This is useful for plug-ins with lots of input, like the Convolution Matrix plug-in. I would like to have this in 2.2, mainly because this will offer a very visible improvement to the user. It will also close at least 5 more or less longstanding feature request. Of course I realize that there is a lot more we want in 2.2 ;) I also have a preference for using XML as a file format. Not as much as a technical issue, but mainly since `everyone' seems to be standardizing on XML and more and more tools to manipulate XML files are becoming available.
Maurits, perhaps you should take a look at your ~/.gimp-1.3/tool-options folder and the files you find there. As this change depends on an incompatible PDB change, it is probably not suitable for 2.2 since it would break all plug-ins. Well, perhaps there is a way to add a new PDB next to the existing one in order to allow old and new plug-ins to coexist. Anyway, if we want this in 2.2, someone should check how far libpdb has come and if suits our needs. The only chance to get this done for 2.2 is to do the PDB change immidiately after the 2.0 release. So at that point there should be at least a working prototype of the new PDB.
Adding dependency on bug #63610. That bug report focuses only on saving new defaults instead of multiple presets, so this one could be seen as an extension of bug #63610. The implementation would probably be very similar and it is likely that both bugs could be solved at once. There are several interesting comments in that bug report and its duplicates.
*** Bug 118849 has been marked as a duplicate of this bug. ***
*** Bug 51103 has been marked as a duplicate of this bug. ***
Some notes which I recall from GimpCon: If we create a GimpPlugIn object, from which all plug-ins inherit, which implements serializable, and we convert plug-ins to use GObject properties rather than internal structs for plug-in settings, we can then use the gimp serialisation work which Sven and Mitch have already done to write and read settings very easily. From there it would be a fairly small jump to have a generic presets widget in the GimpPlugIn object which allowed several settings to be saved in the same file. Dave.
The plug-ins would probably not implement the GimpConfig interface themselves but should have a pointer to a settings object. We should provide some convenience constructors for this since there's quite some boilerplate code involved. Perhaps some macros could do the trick. The advantage of having a settings object is that you can have several instances in the same plug-in. This allows to conveniently implement Reset, Cancel, Save, Save Named, ... in a completely generic fashion. This has proven to work quite well in the core but it will need some work before it can be moved to a library that can be used from the core and the plug-ins.
Bumping from 2.2 to the Future milestone. This depends on a redesigned PDB and that won't happen for 2.2.
Upgrading milestone from Future to 2.6.
*** Bug 431126 has been marked as a duplicate of this bug. ***
Four years without much action. Setting milestone to Future.
There has been a lot of action with the goal of implementing this eventually. It is just not all there yet, but we are a lot closer.
*** Bug 547356 has been marked as a duplicate of this bug. ***
We won't have time to do this for 2.8, moving to Future again.
Could at least bug 547356 "Screenshot delay not saved" which is marked as duplicate of this bug be fixed? Fixing that will improve productivity a lot when regularly using GIMP to create delayed screenshots.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/50.