Activation of the node after doing some actions with the image

Boudewijn Rempt boud at
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
> 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,,

More information about the kimageshop mailing list