After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732320 - Presets accept no changes
Presets accept no changes
Status: RESOLVED DUPLICATE of bug 731279
Product: GIMP
Classification: Other
Component: User Interface
2.8.14
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2014-06-27 10:16 UTC by Jo
Modified: 2016-11-07 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jo 2014-06-27 10:16:20 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.
Comment 1 André Klapper 2014-06-27 20:42:31 UTC
What exactly is "later" here?
Comment 2 Max Mustermann 2014-06-28 08:38:48 UTC
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?
Comment 3 Jo 2014-06-29 12:53:18 UTC
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.
Comment 4 Michael Natterer 2014-08-17 23:11:32 UTC
Seems to work fine here, on Linux with 2.8 and master.
Comment 5 Jo 2014-08-18 11:43:20 UTC
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.
Comment 6 Michael Schumacher 2014-08-19 15:50:40 UTC
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?
Comment 7 Jo 2014-08-27 10:58:01 UTC
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.
Comment 8 Michael Schumacher 2015-06-06 09:51:50 UTC
Does this still happen with 2.8.14?
Comment 9 Jo 2015-06-07 10:33:15 UTC
(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.
Comment 10 Michael Natterer 2015-06-07 22:46:40 UTC
We need nightly builds for Mac users to test, I'm pretty sure I fixed this
some time ago...
Comment 11 Jo 2015-06-08 10:32:12 UTC
(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.
Comment 12 Michael Natterer 2015-06-08 16:51:28 UTC
Yep. 2.8.16 will be out really soon now...
Comment 13 Joao S. O. Bueno 2015-06-08 17:40:19 UTC
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.
Comment 14 Michael Natterer 2015-06-08 23:33:44 UTC
Thanks, that's good instructions to reproduce.
Comment 15 Michael Natterer 2016-11-07 12:58:52 UTC
This should be fixed by the changes for bug 731279, please check.

*** This bug has been marked as a duplicate of bug 731279 ***