Skip to content

Mixed crop tool improvements (1x refactoring + 2x user facing)

  • Crop tool code partially uses forceWidth/Height/Ratio identifiers to identify the state which is in the interface (and manual) labelled as Lock Width/Height/Ratio, these identifiers are fixed to unify the terminology to lock[...] in all places in the code:
void forceWidthChanged(bool newForce);
void forceHeightChanged(bool newForce);
//etc.

// is now

void lockWidthChanged(bool newLock);
void lockHeightChanged(bool newLock);
// etc.
  • The Center and Grow options appear in different vertical order in the tools options docker vs. in the context menu, this is harmonized:

reorder_center_grow

  • The tab order of the crop tool options docker appears to have been defined at some earlier point in time, but not updated for the status quo of the interface. This MR updates the tab order, proposing an "allround" type of tab order (one that as a trade-off is somewhat generically logical, not geared towards maximum efficieny for very specific usecases - I could think of some but I wouldn't really know which ones to favor here)

tab_order_change

  • Oh and lastly there were also two TODO notes in the code, one regarding initializing a crop from a selection (which I found to be already implemented), one about something "during move to Qt4" (I guess this is history ;)), which I both removed

Test Plan

  • Focus an element (possibly starting at the X input top-left) in the crop tool options docker and tab through the whole docker to see if the tab order behaves as illustrated above and makes sense to you that way
  • Toggle the Center and Grow options in both the context menu and tool options docker and check if they are synced/applied correctly vice versa

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.
Edited by Simon Repp

Merge request reports