Bug 467729 - Opening Layer Styles editor resets gradient overlay colors if 0. Foreground to Background is selected and document hasn't been saved/closed/reopened.
Summary: Opening Layer Styles editor resets gradient overlay colors if 0. Foreground t...
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: layer styles (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-23 20:19 UTC by varkatope
Modified: 2024-08-22 16:38 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description varkatope 2023-03-23 20:19:01 UTC
5.2.0-prealpha (git a39b4d5). This also happens in 5.1.5.

SUMMARY

If a gradient overlay layer style is applied to a layer using the 0. Foreground to Background gradient, later changing the current foreground or background color and then reopening the layer styles editor on the same layer will automatically update the applied gradient to whatever the current foreground and background colors are set to. This is undesired behaviour as making any change to the layer style later (after having worked on other parts of the image and having changed the selected colors since) will force you to exit the layer style editor, set the current colors properly, open the style editor, and then re-edit the applied gradient overlay once again before making additional changes (like adding another layer style or just modifying the current one).

Now, it seems that when the file is saved and Krita is closed and then reopened, one notices that a static copy of the 0. Foreground to Background gradient has been created and applied, thereby avoiding this problem, which is great! However, I feel like this same behavior should be performed when the file is still in memory and being worked on (ideally when the gradient is first selected or at least when the layer style editor is closed) as right now if you keep working on the file without closing and reopening it first, the above undesired behavior is encountered.

The question becomes why not create another gradient selection and edit the stops manually? But having a gradient option that automatically picks the current colors is powerful workflow-wise (and is kind of necessary for some functionality I'm building), it's just that it shouldn't change arbitrarily while one is performing other reasonable actions elsewhere. The desired behaviour does exist already, but only when the file is saved, closed, and then reopened.

On a different note, several workflow-breaking bugs were fixed in layer styles recently (align with layer, not remembering other settings, etc.) so thanks to those who worked to fix these issues!

STEPS TO REPRODUCE
1. Draw something and apply gradient overlay layer style to layer using the 0. Foreground to Background gradient. Make sure it's visible on the canvas. Close the layer style editor. Make sure nothing is actually selected on the canvas.
2. Change the current foreground and background colors to something drastic and visible.
3. Reopen the layer styles editor on the same layer.

OBSERVED RESULT
The gradient overlay on the image is automatically updated with the newly selected fore/back colors. You don't actually have to be on the gradient overlay page in the layer style editor for that to happen.

EXPECTED RESULT
The desired behavior of automatically creating a static copy of the gradient and applying that one until the user chooses otherwise only happens when the file is saved, closed, and reopened, but should be applied to the live working document as well (if possible), ideally right away when the 0.Foreground to Background gradient is selected, or at least when the layer style editor is closed.

SOFTWARE/OS VERSIONS
Manjaro Linux, all up to date. Using a nightly AppImage build.
Comment 1 Tiar 2023-04-17 19:06:56 UTC
Relevant: bug 445135 and commit 46e8344d6fa2deebb9d5e6da59f9b6d9bc7f6f2c
Comment 2 Dmitry Kazakov 2024-08-22 16:38:50 UTC
Remove triaged keyword from CONFIRMED bugs