Bug 454828 - An edit to a gradient does not take immediate effect in a Gradient Map brush preset
Summary: An edit to a gradient does not take immediate effect in a Gradient Map brush ...
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: Brush engines (other bugs)
Version First Reported In: nightly build (please specify the git hash!)
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-04 11:06 UTC by Ahab Greybeard
Modified: 2022-09-20 14:44 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2022-06-04 11:06:25 UTC
SUMMARY
This is observed in the 5.0.6 and the 5.1.0-prealpha (git d335b6f7a5) appimages on Debain 10.

If a Gradient Map brush preset is used and a gradient has been selected, it works as expected.
If the gradient is edited then the edited gradient is not updated in the brush preset unless the FG/BG colours are changed, either by editing one of them or by simply swapping them over.

The Gradient Tool does not have this problem.

STEPS TO REPRODUCE
1. Use a Gradient Map brush preset then select a gradient and paint with it.
2. Edit the used gradient in an obvious way, such as by significant colour changes.
3. Paint with the brush preset.
4. Either a) Make an edit to the FG or BG colour from the Toolbar.
   Or b) Swap the FG/BG colours over from the Toolbar.
5. Paint with the brush preset.

OBSERVED RESULT
1. Any selected gradient works as expected.
3. The previous 'not-edited' state of the gradient is used.
5. The brush preset now paints with the edited gradient.

EXPECTED RESULT
An edited change to the selected gradient should take effect in the brush preset immediately.

SOFTWARE/OS VERSIONS
Krita

 Version: 5.1.0-prealpha (git d335b6f)
 Hidpi: false

Qt

  Version (compiled): 5.12.12
  Version (loaded): 5.12.12

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.19.0-20-amd64
  Pretty Productname: Debian GNU/Linux 10 (buster)
  Product Type: debian
  Product Version: 10
  Desktop: MATE
Comment 1 Halla Rempt 2022-06-24 09:32:45 UTC
Hm, I actually think this is kinda intentional: we save the gradient inside the preset because people didn't want it to be changed when the gradient itself is modified. We had a huge discussion about this in 2020.
Comment 2 Ahab Greybeard 2022-06-24 10:17:29 UTC
I can understand why the chosen gradient would be saved/incorporated inside the preset, at the time it was created, to prevent changes to it if the gradient was edited - given a desire for it to remain 'fixed'.

In that case, is it a bug because can be changed, as noted?
Editing/swapping the FG-BG colours seems to be a very obscure way of incorporating a gradient edit, if that was intended to be a possibility.
Also, if someone does 'accidentally' edit that gradient for an unrelated reason and then performs other painting actions, the gradient map brush will then use the edited gradient which goes against the intended desire for it to remain fixed.

The gradient may be saved/incorporated in the preset but it must also have a reference to the external gradient file to allow what has been observed to happen.

Either way, I'd be happy to carry on as things are given that I know how to edit a gradient and 'force' the change back into the preset. It is very obscure and confusing though, until you get used to it.
Comment 3 Halla Rempt 2022-09-20 14:44:44 UTC
Yes, something is pretty wrong here...