<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>
Is it read only? It has public inheritance, so, i guess, it isn't? At least move() is not hidden.<br></div></div></blockquote></div><div><br>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. <br>
</div></div></blockquote><div><br>Ok.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
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.</div>
<div class="im"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
</div></blockquote></div><div><br>It does prevent that KisSelection::setPixelSelection only accepts pixel selection. With KisSelection inheriting KisPixelSelection it would be possible to pass a KisSelection to it. </div>
</div></blockquote><div><br>You mean that we will be able to paint on the projection of a nested KisSelection, don' t you?<br><br>Is it really so bad? And can we forbid it somehow by changing hierarchy? How can we condense common methods? <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
</blockquote></div><br>Well. The problem is: we can't share one data manager between two paint devices. When we access to a data manager directly (from another paint device) we leave the cache of the first paint device not updated. But KisPaintDevice encapsulates cache for such an important methods like exactBounds and region. So the thing we should do: ensure there is only one user of data manager at the moment. Currently, there are two users exist at the same moment: KisSelection itself and it's child m_d->pixelSelection.<br>
<br>I proposed the solution, that solves the issue. The data manager will be cloned (not shared) when the child pixel selection becomes separate (shape selection appeared). And at the same time, it doesn't break back compatibility with usage of getOrCreatePixelSelection().<br>
<br>I don't know how to solve this in other way. Do you have an idea?<br><br>PS:<br>There is one more solution, i think. We can make KisSelection not to inherit KisPaintDevice at all, but make users to use KisSelection::projection() instead. But, this is too big change and quite ugly, btw.<br>
<br>PPS:<br>You wonder, how it was working before? There was a "workaround". The storage (not calculation) of the cache used to be at the lower level - in KisDataManager, though its calculation was done at the higher level in KisPaintDevice. I have moved all the cache stuff into the paint device, to eliminate these interlevel calls, so now the cache is completely KisPaintDevice's responsibility.<br clear="all">
<br>-- <br>Dmitry Kazakov<br>