Kismet

[Patrick Julien]

On March 8, 2004 06:56 am, Boudewijn Rempt wrote:
> On Monday 08 March 2004 12:29, Patrick Julien wrote:
> > I don't think your goal should be to remove the enumeration, but peaceful
> > coexistence.  For widgets, you probably want a mediator to fill in a
> > list/icon/whatever item the send it off.  The key for the result can be
> > this simple enumeration that you match back to the originating object.
>
> Well, I'm not completely done thinking, which is why none of this code is
> used yet... I primarily want to get rid of the enums because they:
>
> 1. lead to switch statements all over the place
> 2. are hard to translate to UI.
> 3. hard to extend without changing code in a lot of places

True, but this is not how I want to use them.  Here, I just wanted a small 
info structure to be defined and initialized once.  Then, you simply iterate 
over the array of structures to fill in the gaps.

>
> Having, say, an image type or a paint operation as a self contained class
> that exposes and uses a small subset of an API, means that it's easy to add
> image types and so on as plugins. Then the internal Krita classes can
> simply use the objects provided by the plugins to perform the action,
> instead of switching.
>
> > Also, now that I see more clearly what you are doing, you should make
> > your image types flyweights.  Now that I think about it even more, you
> > should probably add these members to the color space strategies.
>
> I must admit it's getting hard to see a real difference between an image
> type and a colour strategy. Except, of course, that a colour strategy
> should ideally work whatever the bit depth of the colour channels, and an
> image type determines the bit depth. So what I wanted to do was to make the
> list of supported image types a member of colour strategy.

I don't think it should no, the image type depth should be determined by the 
image.

I don't think the supported image types should be a member of the color 
strategy, no.  Or am I not understanding what you are saying here?


>
> > > The start of that is KisImageTypeRGBA -- I was hesitating beween having
> > > very specialized types (RGBA _and_ RGB), or slightly less specialized
> > > types.
> >
> > There is slight difference here, the common implementation also happens
> > to be the class you are returning from the mediator.  Here, this is no
> > longer true. The common implementation is now a hidden middle class.
>
> Mmm. I'm not sure I'm following you here -- possibly because my own thoughs
> aren't quite finished yet.

Having a middle class with the setters allows you to expose to getters without 
the setter methods... i.e. KisImageType would no longer any members or 
setters, only getters.