Design idea

[Boudewijn Rempt]

On Tue, 10 Feb 2004, Patrick Julien wrote:

> Actually there isn't much to say, but I'm hoping that new widgets added to
> Krita can be more readily reusable, i.e. not bound to internal Krita data
> structures.  My goal is that the ui directory no longer include anything from
> the "core" directory.  That being said, all patches and work you do are
> obviously welcomed, this is simply stating the ideal scenario.

Before Sven started working on the interface, I was looking into it, in a rather
desultory fashion, but one problem I ran into was the representation of Krita's
capabilities. For instance, we have a large number of composition ops. These are
primarily defined by in enumCompositeOp; some of these are implemented. If you
want to give the user a choice of composite op for layers or painting, you need to
present strings to the user in a combobox. The combobox needs to be synchronized
both with the implemented ops (to avoid showing non-working ops), with the colour
strategy (not all colour strategies can use all ops) and with the list of enums.
Selecting a certain string should result in the right enumCompositeOp to be passed
to the Krita core.

This is an area where I don't see how we can easily separate the core and ui, and
I would like to go even further, and tie enum, op implementation and descriptive
string together in an object. I would like to do the same with paint operations (paint,
airbrush, erase, etc.). That way, if I devise some sort of registry that can collect
the curently implemented capabilities of Krita, both the implementation of KisPainter
and of the colour strategies becomes easier, and the implementation of the user
interface.

Every capability would become a singleton (no need to have two instances of a composite
op) that is collected by a singleton registry. The clients, ui, painter, color strategy
can request references to the singletons they can use. This way, if every capability
encapsulates the code needed to perform that capability (composite a few bytes, a paint
algorithm), we can do without the endless case statements and just pass the desired capability
to the painter or the color strategy.

I've already made a start on interfaces and some abstract classes, but didn't
check in because the idea isn't fully formed yet, and because I got sidetracked by the
bug report about the slowness of painting. Still, I dislike the endless case statements
that enums cause, and I dislike spreading code all over the place that define a single
capability even more.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi