New idea about Grayscale Selections problem

[Dmitry Kazakov]

Hi!

I was thinking about this problem in the background... and I guess I have a
solution for this.

Last time I suggested adding a method to the KisPaintDevice class, which
would return a colorspace for the painting, something like that:

const KoColorSpace* KisPaintDevice::colorSpace() const;
const KoColorSpace* KisPaintDevice::paintingColorSpace() const;

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.

Boud objected to this solution, and, actually, I can understand that,
because it is not obvious, which colorspace one should use in which
circumstances.

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?

This would lead to the following design:

1) Generally, the tools would not create the dabs themselves.

2) The paint device would have two new methods:

KisPaintDeviceSP KisPaintDevice::createDab() const;
KisFixedPaintDeviceSP KisPaintDevice::createFixedDab() const;

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
;)

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.

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.

What do you think about such approach?


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20130209/40c74a4d/attachment.html>