Am Feb 10, 2008 um 12:38 schrieb "Igor Stasenko" <siguctua at gmail.com>:

> 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?

My personal guess is because it is not "just" another UI. Also there  
appears to be an astonishing lack of interest.

> 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?
>>

The one UI-heavy project I helped shipping (Plopp) used Tweak. Another  
large UI project is Sophie, also using Tweak.

- Bert -