KisSelection vs. KisPixelSelection

[Dmitry Kazakov]

>
> Is it read only? It has public inheritance, so, i guess, it isn't? At least
>> move() is not hidden.
>>
>
> Move is useless at the moment, because once the projection is updated the
> move is erase. The function should delegate the move to the included pixel
> and vector selection.
>

Ok.


>   Inheriting KisSelection from KisPixelSelection does not prevent it. Just
> think like the projection of KisSelection will be stored as a
> KisPixelSelection object instead of pure KisPaintDevice. Then adding a child
> KisSelection will fit naturally in it.
>
>>
> It does prevent that KisSelection::setPixelSelection only accepts pixel
> selection. With KisSelection inheriting KisPixelSelection it would be
> possible to pass a KisSelection to it.
>

You mean that we will be able to paint on the projection of a nested
KisSelection, don' t you?

Is it really so bad? And can we forbid it somehow by changing hierarchy? How
can we condense common methods?


> Both classes share only a few methods that are common to both. At the same
> time they have lots of stuff that is specific to one of them like updating
> the projection in KisSelection or manipulation methods in pixel selection.
> It would make more sense to put the methods that are the same in both
> classes into a shared base class.
>

Well. The problem is: we can't share one data manager between two paint
devices. When we access to a data manager directly (from another paint
device) we leave the cache of the first paint device not updated. But
KisPaintDevice encapsulates cache for such an important methods like
exactBounds and region. So the thing we should do: ensure there is only one
user of data manager at the moment. Currently, there are two users exist at
the same moment: KisSelection itself and it's child m_d->pixelSelection.

I proposed the solution, that solves the issue. The data manager will be
cloned (not shared) when the child pixel selection becomes separate (shape
selection appeared). And at the same time, it doesn't break back
compatibility with usage of getOrCreatePixelSelection().

I don't know how to solve this in other way. Do you have an idea?

PS:
There is one more solution, i think. We can make KisSelection not to inherit
KisPaintDevice at all, but make users to use KisSelection::projection()
instead. But, this is too big change and quite ugly, btw.

PPS:
You wonder, how it was working before? There was a "workaround". The storage
(not calculation) of the cache used to be at the lower level - in
KisDataManager, though its calculation was done at the higher level in
KisPaintDevice. I have moved all the cache stuff into the paint device, to
eliminate these interlevel calls, so now the cache is completely
KisPaintDevice's responsibility.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100620/089355fe/attachment-0001.htm