Hi!<br><br>I was thinking about this problem in the background... and I guess I have a solution for this.<br><br>Last time I suggested adding a method to the KisPaintDevice class, which would return a colorspace for the painting, something like that:<br>
<br>const KoColorSpace* KisPaintDevice::colorSpace() const;<br>const KoColorSpace* KisPaintDevice::paintingColorSpace() const;<br><br>The former one would return a colorspace for a data stored in the device and the latter one would return a colorspace, which should be used by the tools.<br>
<br>Boud objected to this solution, and, actually, I can understand that, because it is not obvious, which colorspace one should use in which circumstances.<br><br>While working on the dab caching solution (KisDabCache class), I got an idea how to overcome this trouble. What if we change the requirements for the tools a bit? What if we declare that the painting tools do not work with the device, but work with the dab only; and that the management of dabs should be done not by the tools, but by the paint device instead?<br>
<br>This would lead to the following design:<br><br>1) Generally, the tools would not create the dabs themselves.<br><br>2) The paint device would have two new methods:<br><br>KisPaintDeviceSP KisPaintDevice::createDab() const;<br>
KisFixedPaintDeviceSP KisPaintDevice::createFixedDab() const;<br><br>These methods would be used by the brush-based tools to craete a dab for themselves. After creation of a dab, they would not use the device's colorSpace() method, but would use the dab's colorSpace() method instead. For most of the brush-based tools there will be only few changes needed, because the management of the dabs s now performed by a single KisDabCache class for them. The rest of the brushes do not use dab cache, because they work with not-fixed paint devices. They create the dabs themselves. Obviously, the change of the way of dabs creation will not be too difficult ;)<br>
<br>3) The tools that do not work with dabs, like Filter Brush, will work directly with the paint device in its native colorspace. But they do not need anything more.<br><br>This approach kills two birds with one stone: it allows the tools to paint in the colorspace that is different form the native device's colorspace and at the same time it does not create a mess by introducing the second colorspace property for the paint device.<br>
<br>What do you think about such approach?<br><br><br>-- <br>Dmitry Kazakov