[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gzz] Abstract Colorable Vob
From: |
Asko Soukka |
Subject: |
Re: [gzz] Abstract Colorable Vob |
Date: |
Thu, 13 Mar 2003 12:13:17 +0200 (EET) |
Wed, 12 Mar 2003, Benja Fallenstein wrote:
> >> I'd prefer OTOH to have colorability as an optional extra, so that
> >> no interface would expect a colorable object but check "can we color
> >> this? If yes, do".
> Ok, but what's the return type of cloneColored() then? With interface
> ColoredVob extends Vob, it would be 'right' for all cases.
Colorable.cloneColored() can of course return only Colorable and it needs
always casting back to ColorableVob. :/
> Also the case is more general: Vob should be an interface to allow
> multiple inheritance on different sub-interfaces...
Maybe you should PEG this, as you know the arguments?
Hmm... if Vob is an interface, we need also AbstractVob. ColorableVob
interface would be extended from Vob interface (to allow correct return
type for cloneColored()) and would be implemented by
AbstractColorableVob. But what is now the relation between AbstractVob and
AbstractColorableVob? AFAIK they won't have a relation :/
So, I don't see how this would change the situation. Still Colorable
should be a new interface. Abstract ColorableVob would extend AbstractVob
(that implents Vob) and implement Colorable. Again
Colorable.cloneColored() could return only Colorable types and casting
would be needed.
Or is it possible in Java that:
- AbstractVob implements Vob interface
- ClorableVob extends Vob interface
- AbstractColorableVob extends AbstractVob, implements ColorableVob
interface?
> >>>>>>>> methods
> >>>>>>>> +Colorable cloneColored(List colors)
> >>>>>>>> +List getColors()
> >>>>>>>Now that it's immutable, I'm actually leaning slightly towards Color[]
> >>>>>>>colors...
> >>>If you want to use a list when building it up, you can and call
> >>>list.toArray
> But toArray() is an ugly construct and the user is not able to avoid
> *that*. You could have both cloneColored(Color[]) and cloneColored(List)
> (and potentially also, cloneColored(Color) which would seem like the
> most practical interface of the three).
Hmm, good. cloneColored(List) could well be implemented as a shorthand for
cloneColored(Color[]). But the last one has problems:
> Is cloneColored supposed to remove the colors which are already there?!?
> I find that counter-intuitive.
Currently, yes. Without this, it wouldn't be possilbe to drop off colors
from vob primitive. Again, cloneColored(Color) could be a shorthand for
getColors()+addcolor+cloneColored().
Should we have List getColorsList() in addition of Color[] getColors()?
Well, what is the relation of bgColor and solid colors? Currently
RDFNodeView could have a following code. The problem is that I have to
defined bgColor twice. At first as a background color, and then as solid
color. Well, I don't know is this what we want. Tuukka said that bgColor
and selection color should be shown at the same time.
//Creating primitives with certain bgColor
protected static ColorableVob resourceBg = new OvalBgVob(new Color(102,
255, 102), false);
protected static ColorableVob defaultBg = new RectBgVob(new Color(255,
204, 51), false);
ArrayList vobColors = new ArrayList(5);
// Adding color "selected"
if(spec.equals(cursor.getRotationNodespec(dir))) // if selected
vobColors.add(colors.getCursorColor());
if (vobColors.size() > 0) { // Adding bgColors
if(node instanceof Resource) vobColors.add(new Color(102, 255, 102));
else vobColors.add(new Color(255, 204, 51));
}
Color[] colors = (Color[]) vobColors.toArray(new Color[0]);
// Finally, selecting the correct vob
if(node instanceof Resource) bg = (ColorableVob)resourceBg.cloneColored(colors);
else bg = (ColorableVob)defaultBg.cloneColored(colors);
--
Asko Soukka <address@hidden>
<http://www.iki.fi/asko.soukka/>
- [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Asko Soukka, 2003/03/10
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Tuomas Lukka, 2003/03/10
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Asko Soukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Tuomas Lukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Asko Soukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Tuomas Lukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Asko Soukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Tuomas Lukka, 2003/03/11
- Re: [Gzz] PEG ``vob_colorable--humppake``: Abstract Colorable Vob, Benja Fallenstein, 2003/03/12
- Re: [gzz] Abstract Colorable Vob,
Asko Soukka <=
- Re: [gzz] Abstract Colorable Vob, Tuomas Lukka, 2003/03/13
- Re: [gzz] Abstract Colorable Vob, Asko Soukka, 2003/03/14
- Re: [gzz] Abstract Colorable Vob, Tuomas Lukka, 2003/03/14
- Re: [gzz] Abstract Colorable Vob, Asko Soukka, 2003/03/14
- Re: [gzz] Abstract Colorable Vob, Tuomas Lukka, 2003/03/14
- Re: [gzz] Abstract Colorable Vob, Asko Soukka, 2003/03/14
- Re: [gzz] Abstract Colorable Vob, Tuomas Lukka, 2003/03/17
- Re: [gzz] Abstract Colorable Vob, Benja Fallenstein, 2003/03/15
- Re: [gzz] Abstract Colorable Vob, Tuomas Lukka, 2003/03/16
- Re: [gzz] Abstract Colorable Vob, Benja Fallenstein, 2003/03/16