Grids & Guides improvements

Develop
1

Hi

I’m currently looking into Krita’s code, trying to improve smalls things.

Looking about grids & guides, here some stuff I want to implement but I’m not sure if it will be accepted (by developer or community)

So, before losing my time to implement useless stuff, here what I want to do.

[1] All Grids & Guides properties in document

Currently, some grids & guides properties are not saved in document:

  • Lines types
  • Lines color

Example case

  • Create document A, set grids/guides lines to “dashed” with blue color #0000FF
  • Create document B, set grids/guides lines to “dotted” with red color #FF0000

Switch from document A to document B
While documents are opened, you keep grids/guides styles

Save document A, save document B
Close both documents
Open both documents

Both documents now have the same grids/guides styles (will be the last active style)

This is not a bug, this current explicit design.

=> What I want to implement here is the ability to store the grids/guides in Krita document

  • Yes, it make sense to implement this design
  • No, I prefer actual design
  • I want something else
0 voters

[2] Grids offset

Grid offset UI is not intuitive to me, especially the checkbox “Grid offset”.

Example case 1
(Open Krita, create a new document, option “Grid offset” should be unchecked by default)

  1. Check the option “Grid offset”, X & Y grid offset properties are now visible
  2. Update X & Y offset to something else than 0
  3. Uncheck the option: nothing happens (offset is still applied)

Example case 2
(keep previous document from example case 1 open, with option checked)

  1. Create a new document, “Grid offset” option should be checked
  2. Uncheck the option “Grid offset”
  3. Switch to other document, option is checked
  4. Switch back to new document, option is now checked

The way this option is managed is not intuitive.

=> What I want to implement here is, if the option “Grid offset” is check/uncheck:

  • The offset is applied/not applied according to option status check/uncheck
  • The option status set by user is kept when switch from a document to another one, and kept in saved Krita document
  • Yes, it make sense to implement this design
  • No, I prefer actual design
  • I want something else
0 voters

[3] Isometric grids

Just want to try to improve isometric grid.

=> What I want to implement here is to add:

  • Subdivision (+Subdivision line type) like for rectangular grids
  • Vertical line (+Vertical line type)

Example
An isometric grid with additional options

image
image1836×1335 287 KB

  • Yes, it’s interesting to implement it like this
  • Yes, it’s interesting to implement it but differently
  • No, no need for this
0 voters

[4] All grids

Current line style are:

  • “Solid”
  • “Dashed”
  • “Dotted”

=> What I want to implement here is to add “None” style, it will allow to have:

  • “vertical” grid only
  • “horizontal” grid only
  • Yes, it’s interesting to implement it like this
  • Yes, it’s interesting to implement it but differently
  • No, no need for this
0 voters

:warning: implementing this means that trying to open document with “None” line style on an older Krita version may fails.

Grum999

6 Likes
2

Would be great if we could also check the “Snap to grid” option on an isometric grid. Is it hard to implement because of the angle or is it because of something else? :thinking:

1 Like
3

Concerning the snap option for isometric grid, I only found this comment in UI settings code

// disable snapping for isometric grid type for now

It’s not helpful :sweat_smile:

I can’t tell how difficult it is to implement it, I didn’t took a look yet in snap code.

I currently want to focus on basics settings, I didn’t really coded C++ from decades now and I prefer to stay on basics things for now

Also C++ language + Krita source code = :exploding_head:
I spent hours yesterday in code, digging why-how-where… it’s more complex than usual things I’m working on :face_with_peeking_eye:

Grum999

5 Likes
4

“disable snapping […] for now” I guess the option was a bit buggy and they just decided to hide it under the rug.

Do focus on your things, I just asked because it’s something I have been thinking about for some time now. I don’t want to put you through more difficulties than you already are :wink:

3 Likes
5

I’ve started to code, and I’m a little bit distrubed :sweat_smile:

Let’s take a look on isometric grid, how it currently works

Here a simple grid:

  • cell spacing = 100px
  • angle = 45°
    image
    image1797×1144 149 KB

    => Doing measurement of cell width, we have 100px as expected

Now:

  • cell spacing = 100px (unchanged)
  • angle = 20°
    image
    image1797×1144 146 KB

    => Doing measurement of cell width, we have ~155px…

Another case:

  • cell spacing = 100px (unchanged)
  • angle = 0°
    image
    image1797×1144 140 KB

    => Doing measurement of cell width, we have ~292px…

Looking at the documentation, the “cell spacing” is defined as Determines how much both sets of lines are spaced.
I’m not sure what it means…

I’m thinking about adding a new grid system to have “Isometric (legacy)” and “Isometric” where:

  • “Isometric (legacy)” will be unchanged, to keep compatibility for older documents
  • “Isometric” will be:
    – Cell size instead of cell spacing
    – Allow subdivision

Any ideas, pro/con, about this?

Grum999

1 Like
6

For the sell size, it’s easy to measure for the last one. The 100 px size is measurable for the left angle lines. Maybe it works like that:

image
image448×389 814 Bytes

Both lines are 4 pixels long but the angle makes the second one longer

7

They’re 4pixels height
But length (from a trigonometric point of view) is not the same.

I saw that in last case, the distance between 2 horizontal lines is 100px
But start to play with miscellaneous combination of angles (left & right) and try to do measures to find 100px somewhere: you’ll have case where you’ll find it, and many where the 100px is I don’t know where :face_with_peeking_eye:

Grum999

1 Like
8

Having both variations is particularly good as you can easily choose between a defined width and a defined distance. This will presumably please those users in particular whose imagination or technical mathematical understanding would otherwise regularly run into problems.

Michelist

1 Like
9

Ah… height, sorry, wrong choice of words.

If you zoom in enough to see the white-lined pixels, isometric grid left and/or right at 0°, you can see it using those pixels. So it’s probably using those as size/height for the lines.

If I measure my 4 pixels, the straight line is 4, and the other is 5,6.

10

I feel you, hacking in Krita is definitely challenging.

The biggest challenge is finding where the functionality you are trying to modify is located, then realizing it’s actually spread over multiple places, and then trying to make sense of all of that :smile:

Also something that looks simple from the UI might actually be a nightmare from the implementation side.

But as always, figuring things out in the end is rewarding.

3 Likes
11

Ok, I think I have something :slight_smile:

:white_check_mark: [1] All Grids & Guides properties in document

All grids properties are now saved in document
Opening an old document will use default values for new properties

:white_check_mark: [2] Grids offset

Grid offset status is now defined by user and saved in document.
Also switching between documents will apply option properly, as defined by user for each document.

:white_check_mark: [3] Isometric grids

I didn’t wanted to change current implementation of isometric grid, to be sure to not break anything on documents saved from a previous version of Krita
So I choose the option for renaming “Isometric” to “Isometric (Legacy)”
Also I didn’t changed the rules concerning the restriction of “Isometric (Legacy)” available only when Canvas Graphics Acceleration is active

So I added a new “Isometric” grid:

  • Use “cell size” instead of “cell spacing”: all sizes of cell always match given value
  • Subdivision: allow to render subdivisions like for rectangular grid
  • 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

:ballot_box_with_check: [4] All grids

For this one, I didn’t implemented it as initially though with line style.
Instead, I have added checkbox (checked by default) to enabled/disable grids lines.

Note, 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)

:green_circle: Additional changes

  • Added button to link 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

Example:

Commit + Push are made on my repository

I’ll proceed MR tomorrow, too tired now to create a proper description for the MR.

Grum999

8 Likes
12

There is also another MR related to this area by @Reinold here - Add ability to save and load guides (!2089) · Merge requests · Graphics / Krita · GitLab. Just wanted to let you two know so that there is no duplicate work or clash in implementation

3 Likes
13

I haven’t looked at the code yet but just briefly reading the description I don’t think there’s duplicate/clashing work. Although I think there’s a good chance we touched the same files so there may be a merge conflict to watch out for. I’ll try and look more closely sometime tomorrow.

1 Like
14

Yes I saw the MR, but didn’t took a look on code.
For sure, we’ve impacted at least the same UI component and underlying code.

But from a functional point of view, if it’s save/load guides as indicated, then we’re not on the same functionality perimeter.
From a technical point of view there will be a conflict to manage but I think we need to wait a first MR is accepted before starting to manage conflict

Grum999

2 Likes
15

Merge request done :slight_smile:

Linux Appimage can be downloaded here: Artifacts · linux-build (#1624856) · Jobs · Grum 999 / Krita · GitLab

Windows version not available, build is in failure due to “The script exceeded the maximum execution time set for the job” :sweat_smile:
Windows version can be downloaded here: Artifacts · windows-build (#1625079) · Jobs · Grum 999 / Krita · GitLab

Grum999

5 Likes
16

@Grum999 I tried the latest krita next build and for rectangle grids I am getting some rendering issues wherever my brush cursor moves. Should I report this? Can anyone else reproduce this? Here is a video of the issue

You can see wherever my mouse moves there is a white flickering square beneath it. This does not happen with the new isometric grids

1 Like
17

Hi @raghukamath

Thanks for feedback.

Doing tests on my side, I can reproduce it with Krita 5.2.2
So the problem already exists.
To be more precise, it works properly in Krita 5.1.3 and bug start from Krita 5.1.5

Occurs only if canvas acceleration is ON
And only impact subdivision lines style is set to “Lines” (“Dashed”, “Dot” works)

Can you confirm?

I think a bug have to be opened.
I’ll try to understand what happened between 5.1.3 and 5.1.5 here

Edit

Bug was introduced in November 2022 with commit 764719791a4ce6887aedc9d92777f3c4a03198c6

Grum999

1 Like
18

I’ve fixed the problem.
Can you create the bug?
I’ll commit + push + MR when I’ll have the reference

Grum999

1 Like
19

I think if you have already fixed it. I would request you to just go ahead and create the MR :slight_smile: . Sorry for being lazy. But you can add a link to my comment if you want.

20

I’ve created a bug
https://bugs.kde.org/show_bug.cgi?id=484889

I’ll try to commit/push/MR tonight

Edit: MR done

Grum999

5 Likes