Call for ideas: requirements for Krita tool actions system

[Boudewijn Rempt]

On Sunday 05 June 2011 Jun, Dmitry Kazakov wrote:
> Hi, All!
> 
> I've started collecting the requirements for the Tool Actions System. The
> main purpose of this system is to serialize access of the tools to the
> image. But, taking into account, that during encapsulation of the actions
> the tools will be severely rewritten, this project will also include some
> general algorithms for common tools stuff, like Gestures, Keyboard
> Modifiers, Strategies.
> 
> So I've tried to write all the requirements for it. If you think I've
> forgotten to mention something in the list, don't hesitate to tell about it!
> Or if you have some questions about it, ask!
> After the list is settled, I'll start designing the classes for it (I hope
> I'll be able to reuse some code from KO for it).

Do you intend to rewrite the tools to no longer be KoToolBase tools working on KoCanvasBase-based canvases? There's some job facilities in calligra/libs/main/KoAction, but it's not very pretty code.

On that note: how about the other flake tools? I guess those don't need to be queued that much, but flake layers still cause canvas updates.

> 
> The list itself:
> 
> Requirements to Scheduler system:
> 
> 1) The scheduler should serialize stroke and merge actions. The order of
> actions accessing the same pixels should be total.

I didn't really understand this sentence.

> 2) The stroke action should be incrementally modifiable, that is
> KisToolFreehand should be able to add jobs (dabs) to the stroke during the
> painting. Such strokes should guarantee a total order of execution of
> internal jobs.
> 3) There should be a special type of stroke that executes internal jobs in
> parallel. This can be used by KisToolFill, KisToolGradiant for processing
> different parts of the image in parallel.
> 4) The stroke and all its jobs should be cancellable. On cancel event the
> entire transaction of the stroke should be reverted.
> 5) [future] Internal jobs of the stroke may accept the current zoom-level of
> the image to allow implementation of the mipmapping in the future.
> 6) [future] The scheduler may prioritize the actions according to the ROI.

Ack.

> 
> Tool types:
> 
> 7) "Single Click". Action starts after a click is done. E.g. Color Picker
> Tool, Fill Tool
> 8) "Single Drag". Action starts after a drag is done. E.g. Gradient Tool,
> Ruler Tool
> 9) "Incremental Drag". Action starts when the mouse button is pressed and
> the drag is started, the internal jobs are added incrementally. E.g.
> Freehand Tool, Move Tool
> 10) "Other types" I didn't managed to formalize them.
> 

There are also tools that only affect the canvas display, like panning.

> Tools Framework:
> 
> 11) All the tools should support common gestures those change their
> parameters. E.g. Shift+Drag. We can add different types of drags, like
> Shift+Vertical Drag and Shift+Horizontal Drag, the type of drag may be
> recognized automatically.

I think we need to find a better name for this than gestures, because people are bound to be confused by the Qt gesture framework.

> 12) On some modifiers, like Ctrl and Space, the current tool shoud be
> switched to another one temporarily, like to Color Picker Tool and Pan Tool.

We did that before, but the users didn't like it because the option widget changed. I think that we should have two kinds of tools: normal, and temporary, where the temporary tool only changes the cursor but not the option widget. 

When should we move back to the first tool? On release of shortcut, or on pressing another key? We had the p->pan, b->back to freehand shortcuts, but users didn't like those.

> 13) Canvas rotation should be accessible from all the tools.
> 14) The tool's stroke and decorations should be cancelled on pressing Esc.
> 15) Mouse Wheel should do Pan/Zoom in all the tools.

Maybe we can implement that in the canvas, instead of in the tools?

> Non-tool actions:
> 
> 16) All non-tool actions, like Resize Image, Resize Canvas, Filters, should
> go through the same queue as the actions of the tools.

Yes, right.

> 17) Every global action, like resizing of the image, changing its colorspace
> consists of the following stages:
>            i)   locking
>            ii)  processing
>            iii) unlocking
>            iv)  updating the layer stack in a proper way
> All the stages except 'processing' should be encapsulated inside the base
> non-tool-action-object, so that visitors will not bother about locking and
> updating the stack. That is needed because currently some visitors call
> setDirty() for every node they visit. This causes too many superflous
> updates done when the number of layers is more than one.
> 
> 
> Action recorder system:
> 
> 18) All the types of tool actions should fit into action recorder system.

Very thorough.

-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org