GNOME Bugzilla – Bug 732320
Presets accept no changes
Last modified: 2016-11-07 12:58:52 UTC
presets (for airbrush, brush, eraser, smudge, ect..) accept no changes. Registering presets is a one-way option, later tweaks are not saved, even using the save-button.
What exactly is "later" here?
Which presets do you mean? Those that are shipped with GIMP or presets you created on your own? What do you mean with 'registering presets'? Is this reproducible on other operating systems than OS X? Is this perhaps a duplicate of bug #731279?
Custom presets. I'm able to create custom presets as i like, but im not able to modify these, later, -after- i created them. For example, i cant tweak an existing custom preset with another properties like with other brush spacing, another dynamics I own only a Mac, so i cant test this bug on other platforms as well.
Seems to work fine here, on Linux with 2.8 and master.
I'm on a Mac and use the last official public release, Gimp 2.8.10. Often, i create presets but like to fine-tune settings. But this doesnt work on Mac, i have to create a new preset to achieve that fine-tuning.
When exactly do they become non-editable? Right after you switch away from them for the first time (this would remind me of bug 732322), or in the next GIMP session (i.e. when you exit GIMP and run it again?
no, i dont think thats related to bug 732322. After a fine-tuning the new settings seem not to overwrite the preset i created before.
Does this still happen with 2.8.14?
(In reply to Michael Schumacher from comment #8) > Does this still happen with 2.8.14? unfortunately, yes. If i change some settings and try to save them over the existing tool preset in the tool preset editor, no changes are saved.
We need nightly builds for Mac users to test, I'm pretty sure I fixed this some time ago...
(In reply to Michael Natterer from comment #10) > We need nightly builds for Mac users to test, I'm pretty sure I fixed this > some time ago... probably because i use the last stable public release (2.8.14) instead to build Gimp myself.
Yep. 2.8.16 will be out really soon now...
The preset workflow is utterly broken - they do work as "intended" in the code, but the "as intended" is far from user friendly or actually useful. The problem here is that tool presets are created in a "frozen" state at the moment one clicks on "New Tool Preset.." on the dorp-down of the save icon for tool options, or the "New Preset" on the tool presets dialog: tool options are snapshoted at that point, and no feedback is ever given to the user. One sees the "preset editor" dialog - but the recorded tool presets are not visible, and no kind of feedback is given to the user as for the values actually recorded on disk - And if the tool options are changed, one clicks on the "save" icon in the "preset editor", these changed values are not recorded - just the ones that existed at the point the preset was created. Likewise, when one loads a preset, changing the tool options after the preset is loaded has no effect on teh actual recorded values for the tool options (Although the preset _name_ can be changed) This is what this bug report is about. Stepś to reproduce: - Set the tool options to a state you want to be able to recover. - Create a new preset (eithr by the tool options dialog or Preset list. Name it "p1" and save - load any other preset - load preset "p1" - change a tool option parameter - change th preset name to "p2" - click on the save button to preset. Preset "p2" is saved with a new name, but with the same options as the orinal "p1" preset (This behavior is what made Americo bug me on a daily basis through about 6 months - it is obviously broken, and it obviously need a thoughtful spec before been reworked) . One thing that would make everything less broken would be to sghow the user the actual options saved with the preset - and maybe a button to copy current tool options parameters over those recorded on the presets.
Thanks, that's good instructions to reproduce.
This should be fixed by the changes for bug 731279, please check. *** This bug has been marked as a duplicate of bug 731279 ***