KisSelection vs. KisPixelSelection

[Sven Langkamp]

On Sun, Jun 20, 2010 at 1:29 PM, Dmitry Kazakov <dimula73 at gmail.com> wrote:

>
>
> On Sun, Jun 20, 2010 at 3:18 PM, Sven Langkamp <sven.langkamp at gmail.com>wrote:
>
>> On Sun, Jun 20, 2010 at 12:58 PM, Dmitry Kazakov <dimula73 at gmail.com>wrote:
>>
>>>
>>> I've wrote about this issue:
>>> http://wiki.koffice.org/index.php?title=Krita/KisSelection_Issues
>>>
>>> Sven, could you comment on it?
>>>
>>
>> I don't agree. Currently KisSelection is designed to be basically
>> read-only for tools and filters. Inheriting from KisPixelSelection would
>> break that.
>>
>
> 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.


> Suddenly it would be possible to edit the KisSelection even though it is
>> just the projection. Additionally selection could be nested, because you
>> could put a KisSelection into a KisSelection. It's the same the relation as
>> for group layer and normal layers.
>>
>
> 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. For a projection it makes no
difference to store it in a KisPaintDevice or a KisPixelSelection, as the
pixel selection only adds methods that you can't use in the projection
anyway.


>
>
>> If you want to reduce the code duplication it's probably better to use a
>> common base class for them.
>>
>
> How? Could you describe it a bit? I don't fully understand.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100620/27282794/attachment.htm