Krita/KisSelection Issues: Difference between revisions
Appearance
< Krita
Created page with '== Reasoning == Our selections classes have a couple of issues at the moment. You know, there are two types of selection objects: <code>KisPixelSelection</code> and <code>KisSha...' |
m Fix formatting |
||
Line 1: | Line 1: | ||
== Reasoning == | == Reasoning == | ||
Our selections classes have a couple of issues at the moment. You know, there are two types of selection objects: < | Our selections classes have a couple of issues at the moment. You know, there are two types of selection objects: <tt>KisPixelSelection</tt> and <tt>KisShapeSelection</tt>. The first one is raster and inherits <tt>KisPaintDevice</tt> so you can paint on it. <tt>KisShapeSelection</tt> comes from flake and is vector. They both are rendered onto projection in <tt>KisSelection</tt>. And at this very moment <tt>KisSelection</tt> inherits <tt>KisPaintDevice</tt> too. That is the issue, i think. | ||
So why it is not good: | So why it is not good: | ||
Line 13: | Line 13: | ||
So what do i want? | 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 < | * 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 <tt>this</tt>. | ||
== Questions == | == Questions == | ||
* I don't know fully how to deal with getOrCreatePixelSelection, because it should return KisPixelSelectionSP, it means that < | * I don't know fully how to deal with getOrCreatePixelSelection, because it should return KisPixelSelectionSP, it means that <tt>(this)</tt> will be delete'd when the shared pointer dies. That is not good. So how should i deal with it? |
Latest revision as of 00:31, 19 January 2011
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?