KisSelection vs. KisPixelSelection

[Boudewijn Rempt]

On Monday 21 June 2010, Sven Langkamp wrote:
> On Mon, Jun 21, 2010 at 9:27 PM, Boudewijn Rempt <boud at 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.

The problem right now is, if I have understood it correctly, is that it's too 
convenient to treat the KisSelection as a writable paint device, instead of 
something read-only.

-- 
Boudewijn Rempt | http://www.valdyas.org