Hi, All!<br><br>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.<br>
<br>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!<br>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).<br>
<br>The list itself:<br><br>Requirements to Scheduler system:<br><br>1) The scheduler should serialize stroke and merge actions. The order of actions accessing the same pixels should be total.<br>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.<br>
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.<br>4) The stroke and all its jobs should be cancellable. On cancel event the entire transaction of the stroke should be reverted.<br>
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.<br>6) [future] The scheduler may prioritize the actions according to the ROI.<br>
<br><br>Tool types:<br><br>7) "Single Click". Action starts after a click is done. E.g. Color Picker Tool, Fill Tool<br>8) "Single Drag". Action starts after a drag is done. E.g. Gradient Tool, Ruler Tool<br>
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<br>10) "Other types" I didn't managed to formalize them.<br>
<br><br>Tools Framework:<br><br>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.<br>
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.<br>13) Canvas rotation should be accessible from all the tools.<br>14) The tool's stroke and decorations should be cancelled on pressing Esc.<br>
15) Mouse Wheel should do Pan/Zoom in all the tools.<br><br><br>Non-tool actions:<br><br>16) All non-tool actions, like Resize Image, Resize Canvas, Filters, should go through the same queue as the actions of the tools.<br>
17) Every global action, like resizing of the image, changing its colorspace consists of the following stages:<br> i) locking<br> ii) processing<br> iii) unlocking<br> iv) updating the layer stack in a proper way<br>
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.<br>
<br><br>Action recorder system:<br><br>18) All the types of tool actions should fit into action recorder system.<br><br><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>