Skip to content

Consistently use "Color Sampler (Tool)" terminology in interface and code

Simon Repp requested to merge simonrepp/krita:simonrepp/color-sampler-rename into master

As decided in the first IRC meeting of 2021 there should only be the "Color Sampler" terminology for what was previously called either "Color Picker" or "Color Selector". This is a comprehensive MR to effect this change not only at a few superficial places that are user-facing, but widely in the codebase.

I'm proposing such a thorough (and therefore of course also issue-prone) change with the rationale that otherwise the partially inconsistent naming in code ("Picker") will remain in the codebase until forever, confusing developers for years to come, and at some point outweighing the cost of just doing the full rename and dealing with the unpleasant reviewing process and possible merge conflicts etc. right away and now in one go.

(Nonetheless I would understand if this is just too much, let me know in that case. :))

Review Notes:

  • Large parts are obvious and unambiguous renaming (and thus easy to confirm)
  • Some parts touch things that are not per se the Color Sampler tool itself, but conceptually identical mechanisms (i.e. temporarily sampling a color for a filter through its dialog or such), which is why I changed these too
  • I'm pretty sure that I've overdone it in some places too, as partially it was very hard to understand some of the abstraction, i.e. code that uses some "Pick(...)Foo" terminology, is completely abstract, is somehow related to tool modifier actions, spans multiple areas, etc. ... please do point these out so I can revert them (or alternatively feel free to just change those things back and commit on top of the MR of course)

Test Plan

  • Check if all visible strings in the interface say "Color Sampler" where it is expected
  • In general, test the Color sampler tool (both explicit and in the "modifier variant" within the Brush Tool) whether it still works
  • Other than that, as there are many many files involved, a good plan would be to merge this way ahead of an upcoming release and catch possible collateral damage through all other testing that occurs over multiple weeks/months up to the release

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.

Merge request reports