Skip to content

Don't forget 'align with layer' in gradient layer style

Agata Cacko requested to merge tymond/krita:tiar/fix_bug456194_gradient_overlay_forgets_align_with_layer into master

Commit 1:

Before this commit, checking "Align with layer" in the gradient
overlay layer style would result only in temporary alignment
with the layer, and the checkbox would be unchecked next time
the user opens the dialog. The same was happening with the
gradient in the Stroke layer style.
This commit ensures the value of the checkbox will be remembered.

There is still potentially a problem with Stroke layer style
having only one boolean value for the "Align with layer" values in both
Gradient and Pattern, but it shouldn't be much trouble for the user
because this commit ensures that the value in the active stroke type
will be remembered correctly.

BUG:456194

Commit 2:

Fix Pattern Overlay layer style "Link with layer" when moving
    
Before this commit, if you tried to move a layer with Pattern Overlay
with "Link with layer" checked, there would be an interesting effect of
pattern moving the exact opposite way of the layer.
This commit ensures it will move *with* the layer.
    
Note: it might potentially break existing files?

WARNING

WARNING: It might break old files!!! (the second commit). Though it really worked incorrectly before...

Test Plan

  1. Open a new document.
  2. Paint a blob on a new, empty layer (not the background layer)
  3. Add a Gradient (Overlay) layer style and check "Align to layer" property.
  4. Use transform tool or move tool to move it around to notice the behaviour.
  5. Open the Layer Styles dialog, see that the checkbox is still on.
  6. Again move the blob around to see the behaviour.
  7. Repeat with the checkbox off.
  8. Repeat with Layer Styles -> Stroke -> Type -> Pattern, and Layer Style -> Stroke -> Type -> Gradient.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports