<div class="gmail_quote">On Mon, Aug 24, 2009 at 2:09 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Mon, 24 Aug 2009, Cyrille Berger wrote:<br>
<br>
> Hi,<br>
><br>
> We discussed this on IRC. Here is the conclusion:<br>
> * paintdevice colorspaces belongs to the paintdevice, therefor they have a<br>
> short/unpredictable life expectency, you should only use them as long as you<br>
> are certain that the paintdevice won't be deleted<br>
> * if you need to keep a pointer of the color space (like in a KoColor), you<br>
> need to ask the KoColorSpaceRegistry for a permanent colorspace (see the<br>
> permanentColorspace function)<br>
><br>
> In this case, since it's a property of the layer. Storing the id/name in the<br>
> model would be the way to go.<br>
<br>
</div></div>I don't get this last bit -- can you unpack a bit?</blockquote><div><br>At the moment KisCompositeOpsModel stores the pointers to the composite ops which are deleted when the colorspace is deleted.<br>Instead of the pointer the id/name should be saved as Cyrille said.<br>
<p style="margin: 0px; text-indent: 0px;"></p> </div></div><br>