Skip to content

Ensure that there's no new palette being set when we changed our mind.

Wolthera van Hövell requested to merge wolthera/palette_fixes into krita/5.0

Without this, a new palette was returned anyway when canceling out of the rename-resource flow, which was a little scary.

Test Plan

  1. Make a new palette
  2. when making it, give it the same name as an existing palette.
  3. Now, in the 'this palette already exists dialog', cancel.

Before this patch, the palette view would receive the new palette anyway, despite canceling. Now, this doesn't happen anymore.

Of the issues in the doc, this is the only one I could fix, because one other wasn't a bug, another was handled by dmitry's branch.

NB: d58bbf3a doesn't seem to work as expected, and you'll have to temporarily revert it, or write in a quick workaround if you want to test it.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • [N/A] 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.

Merge request reports