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
> currently]
> * 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
> KisView2::slotLoadingFinished].
> 
> Pros:
> + tools and actions should not think about activation of anything
> + no inter-module dependencies
> + no multithreading problems
> + undo/redo work as expected
> Cons:
> -- we should consider all the usecases before declaring it (see questions
> below)


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.

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop