Krita/KisSelection Issues

From KDE Community Wiki
Revision as of 00:31, 19 January 2011 by Nalvarez (talk | contribs) (Fix formatting)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Reasoning

Our selections classes have a couple of issues at the moment. You know, there are two types of selection objects: KisPixelSelection and KisShapeSelection. The first one is raster and inherits KisPaintDevice so you can paint on it. KisShapeSelection comes from flake and is vector. They both are rendered onto projection in KisSelection. And at this very moment KisSelection inherits KisPaintDevice too. That is the issue, i think.

So why it is not good:

  • KisSelection's projection from an outer world looks like a usual pixel selection. It has the same selectedRect()/selectedExactRect() methods and so on. Outer interface of it resembles KisPixelSelection much. There is nothing bad in it in general, but all this resembling is based on simple code duplication. That is why i suggest to make KisSelection inherit KisPixelSelection.
  • KisSelection's paint device and (its child) m_d->pixelSelection both share the same data manager, that is not good, because it breaks encapsulation of KisPaintDevice (and breaks encapsulated caching in particular).

Proposal

So what do i want?

  • KisSelection will inherit KisPixelSelection with all its properties. Say, "the projection of KisSelection will be represented by KisPixelSelection". KisSelection will have two states: needProjection() and !needProjection(). In the first state, both child selections will be projected onto it. But in the second state, KisSelection will look like a usual pixel selection, and getOrCreatePixelSelection() will return this.

Questions

  • I don't know fully how to deal with getOrCreatePixelSelection, because it should return KisPixelSelectionSP, it means that (this) will be delete'd when the shared pointer dies. That is not good. So how should i deal with it?