Skip to content

Grids & Guides improvements

Grum 999 requested to merge grum/krita:grum999/improve_grids_and_guides into master


This MR concern some improvement for grids management.

It only impact grids rendering: snap tool is not impacted (and then, snap option is still disabled for isometric grids)

1. All Grids & Guides properties in document

All grids & guides properties (especially lines style: line type + line color) are now saved in Krita document.
Opening an old document will use default values for new properties (keep use of loadStaticData() & saveStaticData() methods).

It seems it was a design choice to not save these properties in Krita document, but it makes sense to save it as grids & guides colors are often defined taking in account colors of documents.

Last used type & color settings are still saved in Krita's settings and reused by default for next new document.

2. Grids offset

The checkbox "Grid offset" is not intuitive.

Example of current behavior can be found here:

The MR review how this checkbox is used: to be simple, Grid offset status is now defined by user and saved in document.

  • If user check the option, it stay checked
  • If user uncheck the option (even if offsets values are set) the it stay unchecked.

Switching between documents will apply option as defined by user.

3. Isometric grids

Isometric grid are improved this way:

  • Use "cell size" instead of "cell spacing": all sizes of cell always match given value

    Example for left angle=30°, right angle=15°, cell size/space=50px


  • Subdivision: allow to render subdivisions in isometric grid like it's done for rectangular grids

  • Vertical line: a vertical line can be displayed when main divisions intersect

    • Displayed only if left&right angles values are the same
    • Can be hidden id needed (set line style = None)
  • This Isometric grid is available even if Canvas Graphics Acceleration is not active

Concerning compatibility with current isometric grids, to be sure to not break anything on documents saved from a previous version of Krita, I choose to:

  • Rename current "Isometric" to "Isometric (Legacy)" and keep legacy code.
    • Also I didn't changed the rules concerning the restriction of "Isometric (Legacy)" available only when Canvas Graphics Acceleration is active
  • Implement isometric grid differently

One difference between "isometric legacy" and "isometric" is alignment of grid


4. Miscellaneous

  • Added the possibility to activate/deactivate grids lines through additional checkbox
    • It's not possible to deactivate both grids lines at the same time (if one is deactivated, the checkbox for the other one is disabled)

    • Example


  • Added button to lock aspect ratio of left & right angles
  • Put grid offset X & Y settings in one row, to reduce a little bit size
  • Small improvements on UI the things aligned

5. Technical impact

I had to update KisAspectRatioLocker to let the possibility to link angle components (KisAngleSelector and KisAngleGauge) For this I'm not sure about the approach.

I had to add method connectAngleBoxes() because angle selectors don't expose value() and setValue() and then I didn't found how to manage this properly in connectSpinBoxes() method.

Test Plan

Create a new document, open docker "Grid and Guides"

  • For all grids

    • grid is rendered properly, according to grid options
    • save & close 2 documents with differents line style settings
    • reopen both documents: line style settings for each document are applied
  • Rectangular grid

    • can open a document created from a previous version of Krita, ensure that rectangular grid settings are the same and render the same way
  • Select isometric (legacy) grid

    • can open a document created from a previous version of Krita, ensure that isometric legacy grid settings are the same and render the same way

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,

Edited by Grum 999

Merge request reports