freak at codepimps.org
Mon Mar 8 13:07:47 CET 2004
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
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.
More information about the kimageshop