Activation of the node after doing some actions with the image
boud at valdyas.org
Fri Jan 27 10:27:11 UTC 2012
On Thursday 26 January 2012 Jan, Dmitry Kazakov wrote:
> 2) [better one]
> We may do like Qt's QAbstractItemModel is supposed to work. We do not add
> any commands and declare that the tools should not not activate any nodes
> directly. All the work is done in the KisNodeManager (or KisNodeModel)
> automatically. It means that:
> * when a node is added it is automatically activated [we do not have it
> * when a node is removed some neighboring node is activated instead [we do
> already have it]
> * when a node is moved active node doesn't change
> * when a root layer is changed (sigLayersChanged), the topmost node is
> activated [we have something like this hardcoded in
> + tools and actions should not think about activation of anything
> + no inter-module dependencies
> + no multithreading problems
> + undo/redo work as expected
> -- we should consider all the usecases before declaring it (see questions
I think this plan has a good chance of working out.
> Conclusion and questions:
> So I think the second approach is really better and easier to implement. We
> need to fix KisNodeManager (or KisNodeModel) and remove all the direct
> calls from the actions. But the questions are:
> 1) Do all our tools/actions fit into this way of working? I mean, do all of
> them activate newly created layers only?
There's not just tools/actions, but also dialogs like separate image, which creates more than one layer -- but it's not necessary to actually activate any of those layers immediately.
> 2) Are there any usecases when a tool should activate some other layer, not
> a new one?
Apart from separate image, I'm not sure -- I would have to investigate.
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
More information about the kimageshop