Morphs as composition of traits?

Igor Stasenko siguctua at gmail.com
Sun Feb 10 11:38:53 UTC 2008


On 09/02/2008, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On Feb 9, 2008, at 22:18 , Igor Stasenko wrote:
>
> > On 09/02/2008, Bert Freudenberg <bert at freudenbergs.de> wrote:
> >> On Feb 9, 2008, at 6:52 , Igor Stasenko wrote:
> >>
> >>> it's really hard to tell what properties morphs can be kept as basic
> >>> (core) ones.
> >>> Dimenstions(shape)? No. There is morphs which never show-up on
> >>> screen
> >>> and therefore don't need any dimension/shape info.
> >>> Visual aspects? Again - no. Depending on morph, they can be very
> >>> different, including colors, borders or font style for text.
> >>>
> >>> So, maybe, i thought, better to think of morph as composition of
> >>> different traits, which in sum defining an original morph.
> >>
> >> Tweak does something similar, its graphical objects are composed of
> >> "aspects", for example "fill", "border", "geometry" etc.:
> >>
> >> http://tweakproject.org/TECHNOLOGY/Documentation/
> >>
> >> The current implementation uses delegation rather than Traits,
> >> though. There is a gazillion of delegation methods in the base
> >> object, possibly Traits would allow the structure to be more
> >> explicit ...
> >>
> >
> > Yes, it should help with making things more explicit and use direct
> > calls rather than delegation.
> > As for example, a Fill aspect
> > http://tweakproject.org/TECHNOLOGY/Documentation/PlayerAspects/#fill
> >
> > you really don't need to keep that much state, if your only intent is
> > to fill with solid color.
>
> In Tweak this is not state, just protocol (that's what I meant with
> "delegation methods").
>
> > So, we can easily divide different fill styles into different
> > categories:
> > SolidFill (color)
> > GradientFill (colorRamp, gradientType)
> > MySuperiorFill (...)
> >
> > each kind of fill can require own, unique set of state.
>
> That is exactly how it is implemented, there are different Fill
> classes with different state. They share a common protocol though.
> You could ask a NoneFill for its color and it would answer transparent.
>

Okay, then a next, logical question, why Tweak didn't replaced morphs?
It's really beats me every time: a lack of good and polished UI
framework in squeak, and decent UI builders/editors.
I'd like to start a 'secret' project, which heavily using graphics and
UI.. but i can't choose what system to pick to be used for it: current
Morphic, Tweak, write own, or wait for Morphic3?
I know, my questions is mostly rhetoric, but i'm just curious, if
you(anyone who reads this) would be on my place, what will you choose?

> - Bert -
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list