Krita/NonTool Actions Implementation: Difference between revisions
(Created page with '==Non-tool actions== ===Requirements=== # All non-tool actions, like Resize Image, Resize Canvas, Filters, should go through the same queue as the actions of the tools. # Every g...') |
|||
| Line 18: | Line 18: | ||
First, we declare KisNodeVisitor's visitAll() method as deprecated. The visitor should only do what it is intended to do: be able to visit a node of any type and describe this action. All the other tasks are left for special classes. | First, we declare KisNodeVisitor's visitAll() method as deprecated. The visitor should only do what it is intended to do: be able to visit a node of any type and describe this action. All the other tasks are left for special classes. | ||
So now the visitor can be defined as "exclusive" and "sequential". These properties totally correspond to the properties of the [[Krita/Strokes_Framework|stroke]] running this visitor. If the visitor is defined "exclusive" then all the updater threads will be stopped until the visitor has processed all the requested nodes. If the visitor is defined as "sequential", then all the nodes will be processed one-by-one instead of concurrently. | So now the visitor can be defined as "exclusive" and "sequential". These properties totally correspond to the properties of the [[Krita/Strokes_Framework#Strokes|stroke]] running this visitor. If the visitor is defined "exclusive" then all the updater threads will be stopped until the visitor has processed all the requested nodes. If the visitor is defined as "sequential", then all the nodes will be processed one-by-one instead of concurrently. | ||
KisNodeProcessingStrategy and NodeProcessingData are just wrappers for the visitor. This is the way how strokes framework works. | KisNodeProcessingStrategy and NodeProcessingData are just wrappers for the visitor. This is the way how strokes framework works. | ||
KisNodeProcessingStrokeStrategy (what an ugly name!). This class is supposed to do two things. First, it stores the informations about the visitor (sequential, exclusive). And second, it performs an update of the image after the processing is done. Both these tasks are done in a way to support undo(). | KisNodeProcessingStrokeStrategy (what an ugly name!). This class is supposed to do two things. First, it stores the informations about the visitor (sequential, exclusive). And second, it performs an update of the image after the processing is done. Both these tasks are done in a way to support undo(). | ||
Revision as of 10:14, 16 June 2011
Non-tool actions
Requirements
- All non-tool actions, like Resize Image, Resize Canvas, Filters, should go through the same queue as the actions of the tools.
- Every global action, like resizing of the image, changing its colorspace consists of the following stages:
- locking
- processing
- unlocking
- 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.
- (!) The jobs from the stroke should be able to block updates only. So they should allow the stroke to be 'exclusive', not a single action.
- Check that KisFullRefreshVisitor calls setDirty() of the root node after the job is done.
- It should fit into undo system perfectly.
Description
The system is based on strokes framework. First, we declare KisNodeVisitor's visitAll() method as deprecated. The visitor should only do what it is intended to do: be able to visit a node of any type and describe this action. All the other tasks are left for special classes.
So now the visitor can be defined as "exclusive" and "sequential". These properties totally correspond to the properties of the stroke running this visitor. If the visitor is defined "exclusive" then all the updater threads will be stopped until the visitor has processed all the requested nodes. If the visitor is defined as "sequential", then all the nodes will be processed one-by-one instead of concurrently.
KisNodeProcessingStrategy and NodeProcessingData are just wrappers for the visitor. This is the way how strokes framework works.
KisNodeProcessingStrokeStrategy (what an ugly name!). This class is supposed to do two things. First, it stores the informations about the visitor (sequential, exclusive). And second, it performs an update of the image after the processing is done. Both these tasks are done in a way to support undo().