KisLayer::image() pointer problem

[Boudewijn Rempt]

On Tuesday 17 May 2011 May, Dmitry Kazakov wrote:
> Hi, all!
> 
> Boud said recently that the KisLayer and other nodes must not store the link
> to the KisImage. I'm totally agree with this point. We have a special
> interface for this (KisNodeGraphListener), so there is no reason for it.
> 
> I think we can do this right now. KisLayer uses image for three reasons
> only:
> 1) Sending setDirty() notifications.
> 2) Accessing global selection
> 3) Fetching colorspace of the image
> 
> How can it be solved:
> 1) KisNodeGraphListener is created exactly for this. So we can just add an
> updateProjection() method there.

Yes, that should work.

> 2) If we make global selection as a selection mask, then global selection
> will be easily accessed by traversing parent() hierarchy. This method will
> be very easy and useful for a user.

I'm still not convinced that we won't be confusing global and local selections then, but perhaps we should get rid of this distinction in the code. The interaction design really needs to be carefully though -- something for the sprint perhaps!

> Because currently, there is no meaning
> in creating a selection mask inside a group layer. 

Well, there should be: the selection mask on the group layer should be the selection used when, for instance, doing a copy from the group layer's projection while the group layer is active.

> But if we use parent()
> calls, then a selection mask, created inside a group layer works like a
> global selection for child nodes. 

That sounds actually like it could work very well.

> I think this is very good and useful from
> both sides user and developer.

> 3) Completely the same as bullet 2). Just ask a parent. Colorspace of the
> root group layer coicide with the colorspace of the image.

Right, that coul dwork very well.

> So what do you think of it?

Yes, I think this could work very well.
-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org