Call for ideas: requirements for Krita tool actions system

[Dmitry Kazakov]

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).

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.
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.


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.


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.
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.
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.


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.
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.




-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110605/7d631d19/attachment.htm