Cell size: I think that's usually called "Grid spacing"

Questions that need to be answered: -- 1,2,3 I agree. For 4, if there's time to add snapping, it's selections, move tool, transform tool that need to snap, not painting.

"Perspective Grid": the assistant is already there, it's the clone brush that needs to learn to work with the assistant, not the grid, for perspective healing.

In T1401#16118, @rempt wrote:

Questions that need to be answered: -- 1,2,3 I agree. For 4, if there's time to add snapping, it's selections, move tool, transform tool that need to snap, not painting.

About 4: yes, I don't speak about painting. The question is different. There should be a shortcut/some other UIX to disable snapping to anything right in the middle of the transform/selection stroke. The problem is that all the modifiers are already occupied for these tools, so we cannot use them directly for "disable snapping" behavior.

"Everything snaps to the guides when snapping is active" Not painting: the freehand brush must absolutely not snap to guides (or grids). That would be a real workflow impediment.

Guides need to have a handle like the mirror line to manipulate them

Guides need to be saved and loaded with the image

We need to be able to save and load guides as presets. There is no need to make resources out of these presets, simply loading and saving to files will be enough.

The orientation for the guide is dependent on which ruler it was dragged out from: you do not create a guide with a command or a menu option, guides come from rulers.

If there's time, diagonal guides will be very useful, especially for more advanced types of comics.

You don't need to enable/disable snapping for individual guides: if guide snapping is enabled, move, select, transform, vector objects snap to all guides. A single action in the view menu witha shortcut that enables snapping and another that enables visibility is enough.

In T1401#16124, @rempt wrote:

"Everything snaps to the guides when snapping is active" Not painting: the freehand brush must absolutely not snap to guides (or grids). That would be a real workflow impediment.

Sure, yes. I meant the object-oriented tools

Guides need to have a handle like the mirror line to manipulate them

Not sure about that. The handle interferes the workflow really much. Even for the mirror line we had multiple reports telling there is no way to hide it. I can agree with a handle only if there is an obvious and non-disturbing way to hide them when the editing is finished.

Guides need to be saved and loaded with the image

yes

We need to be able to save and load guides as presets. There is no need to make resources out of these presets, simply loading and saving to files will be enough.

That might be a stretch goal. In the discussion on the forum people agreed this is not too useful, given that they do templates using .kra files:

Excerpt from the forum:

kamathraghavendra wrote:
Preset system for guide setup

Why not, but having a collection of template kra docs also works in that case. It's not something I've ever missed in PS, despite my work requiring to do precise layouts - the pb is that you rarely need the same guides and setup (unless you're a webdesigner maybe?).

For the rest of comments, yes

About the questions:

1-yes and yes
2-no need for it
3- yes please, this can be useful to place the grid with an offset that is different from the spacing.
4-yes for the global option, not sure what to do about modifiers.

Also about snapping, we need a visible option to define the maximum snapping distance.

The existing grids docker works slightly different than the requirements. You can control the main grid lines style (eg. dotted) and color. You can slo control the subdivision lines style and color. Do we want to still keep this functionality?

Questions that need to be answered

1. Should the user be able to control horizontal and vertical spacing separately? If yes, should the "linked" toggle be active by default? [I think: yes, yes]
2. Should the user be able to control the color of subdivision lines separately, or the color should be generated automatically from the main color? [I think: no, it should be automatic]
3. Should the user be able to control the offset of the grid? [I think: no, what is the usecase?]
4. Should there be an option to toggle "Snap to grid/guides"? What should we do with the tools that have Ctrl and Shift modifiers already occupied, so we cannot use them to disable snapping temporarily within the stroke? [I think: yes, option is needed; probably, some context menu to toggle snapping options, which can be fired up from within a context of a stroke?]

1. yes and yes
2. no it should be automatic as you suggest
3. yes controlling offset is beneficial ( this is what I understand how it works, joining point in the ruler - "the origin" is dragable, you can drag and set the new origin , when double clicked it should reset it self)
4. Yes shortcut for snapping if required snapping while drawing is not required only for shape drawing and selection tool and move tool. activating snap can be different shortcut , I didn't understand the need for modifiers.

I would like to add a request for adding an additional type of grid other than only rectangle , it is called axonometric grid , this will be helpful for game design and other isometric artworks.
to know better i request you to go to inkscape's grid properties , it has the axonometric grid setting.

@kamathraghavendra can you make a new feature request from your last comment. This request won't make it in 3.0. This ticket has quite a bit of other work in it that is done, so it might make it more complicated to talk about here. We can probably close this issue.

@scottpetrovic I wouldn't close this task, there's still too many things listed that we wanted to tackle later.(Like, guide-presets)

I just noticed that the grid subdivision parameter doesn't subdivide grid cells: it actually groups cells together and changes the look of intermediate lines. I.e. if you create a 64*64 grid and set the subdivision to 3, the main grid lines will be 192 pixels away from one another. I'd expect it to work the other way around. That's how it is in Photoshop, which just places the subdivision lines at regular intervals (even if some end up on sub-pixel positions, in the example 21.3px away from one another).

The main use I've found for subdivisions is to find the center of my grid cells (for tilemaps/character sprites for games). I can't imagine a use for the current way it works. But if you decide to keep it, I think it would need a more representative name, like "group cells".

@gdquest It works the same way as in Inkscape, which is imho good, though I agree Subdivision is not the right word here, maybe we can reuse their terminology and call it "Major Grid line".