[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: KisSelection vs. KisPixelSelection
From:       Sven Langkamp <sven.langkamp () gmail ! com>
Date:       2010-06-21 19:50:53
Message-ID: AANLkTil5vZrWkOhE5klyHHqiv3WDVzhQci9M7H7b05Fk () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Mon, Jun 21, 2010 at 9:27 PM, Boudewijn Rempt <boud@valdyas.org> wrote:

> On Sunday 20 June 2010, Sven Langkamp wrote:
> > 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.
>
> Hm... I'm not completely following the issues Dmitry has with the current
> design, but reflecting on the current code, I think it's a bit ugly that
> KisSelection _is_ the projection. How about something like:
>
> Make a KisSelection class that is not a paint device. Make it own:
>
> * KisPixelSelection::KisPaintdevice
> * KisVectorSelection
> * and a KisPaintDevice for the projection.
>
> similar to KisImage?
>
>
The way it's now is quite convenient. In most cases you just use the
selection as mask without thinking about what's behind.
We need a projection anyway so where is the problem with KisSelection being
the projection?

Changing this would also mean lots of work without much gain.

[Attachment #5 (text/html)]

<div class="gmail_quote">On Mon, Jun 21, 2010 at 9:27 PM, Boudewijn Rempt <span \
dir="ltr">&lt;<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On \
Sunday 20 June 2010, Sven Langkamp wrote:<br> &gt; Both classes share only a few \
methods that are common to both. At the same<br> &gt; time they have lots of stuff \
that is specific to one of them like updating<br> &gt; the projection in KisSelection \
or manipulation methods in pixel selection.<br> &gt; It would make more sense to put \
the methods that are the same in both<br> &gt; classes into a shared base class.<br>
<br>
</div>Hm... I&#39;m not completely following the issues Dmitry has with the \
current<br> design, but reflecting on the current code, I think it&#39;s a bit ugly \
that<br> KisSelection _is_ the projection. How about something like:<br>
<br>
Make a KisSelection class that is not a paint device. Make it own:<br>
<br>
* KisPixelSelection::KisPaintdevice<br>
* KisVectorSelection<br>
* and a KisPaintDevice for the projection.<br>
<br>
similar to KisImage?<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>The way \
it&#39;s now is quite convenient. In most cases you just use the selection as mask \
without thinking about what&#39;s behind.<br>We need a projection anyway so where is \
the problem with KisSelection being the projection?<br> <br>Changing this would also \
mean lots of work without much gain. </div></div>



_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic