Design idea

[Patrick Julien]

On February 10, 2004 06:08 am, Boudewijn Rempt wrote:
> 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.

I think you are using the wrong design pattern.  Please, allow me this humble 
suggestion: the mediator design pattern.

So, you have a director (the mediator) that sits between the colleagues 
(whatever class spawned the dialog and the concrete dialog).

If I reuse the example given, the director has access to the internals of 
core, it can build a map of strings to composite ops.  It then passes the 
strings to the dialog.  When a selection occurs, the dialog emits the 
selection using the original string.  The mediator matches the string to the 
composite operation using it's map.  The mediator then passes the composite 
operation to whoever wanted it.  Or simply, on return of the dialog, etc.  

The point isn't really about how the value is returned from director in this 
case, it's about guiding you to the right design pattern.

The concrete mediator can implement a mediator interface.  This interface can 
be reused over multiple dialogs, especially if we are only simple values to 
widgets.

To re-use the widget in another application, you simply implement the mediator 
interface to get a concrete director.