Morphs as composition of traits?

During walk with my dog, i just have different thoughts about morphs,
and about what schemes is best fit to adequately model the morphic
system.

Here, is my thoughts:
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.

Let me pick an example, to better illustrate what i have in mind

Rectangle morph.
It should include a 'shape' trait, because rectangle is just a kind of
shape (lets assume it's a ShapeTrait subclass - RectangularShape).
Now, with having shape we can speak of different visual aspects, like
border and fill.
Note, that once you defined shape, it's should not mean, by default
that it can have border or fill - it's another traits (but in this
turn, the traits of shape).
So, for instance i could have 3 kinds of rectangle morph: with fill
only, with border only and with border and fill both.
If you see, by using such approach, it's really looks like i'm
building morph from composition of different traits which are
organized in tree-like manner.

Okay , we just defined a set of traits which should define a rectange morph.
Now, is how to build a real instance of it (or class which producing them).
Instance of such class would require from us a state, which will
reflect a different trait-based properties of it.
How about using anonymous classes, and using special methods, in
traits class, which should describe what state should be included into
resulting class?
Then, we can create a morph class on the fly, using UI by picking
traits and compositing them, and in result we will have a class, ready
to work with.

As one of the variants it can be a #statevars method:

FillTrait class>>statevars
 ^ #(fillstyle)

Now suppose we have a class named MorphClassBuilder which simply
builds for us an anonymous morph class.

MorphClassBuilder>>numvars
| numvars size |
size := 0.
self allIncludedTraits do: [:trait | size := size + trait statevars size ].
^ size

By having a #numvars, it's easy to add a #new method for our future morph class:

resultingClass addClassMethod: 'new ^ self basicNew' , builder numvars asString.

.. and, it's really easy to add accessors to such class:

MorphClassBuilder>>addAccessors
| allvars |
allvars := OrderedCollection new.
allvars := self allIncludedTraits do:[:trait | allvars addAll: trait
statevars ].

allvars withIndexDo: [:i :selector |
   resultingClass compileMethod: selector , ' ^ self at:' , i asString
. "read accessor"
   resultingClass compileMethod: selector , ': value  ^ self at:' , i
asString , ' put: value' . "write accessor"

.. as you can see, nothing really hard, here: just implement a
MorphClassBuilder, and you'll have a powers to create virtually any
kind of morph by combining wide variety of traits.

Back to example, our rectangle morph with fill and border require 3 state vars:
- bounds
- fillstyle
- borderstyle

So, a MorphClassBuilder should produce a morph class with following methods:

new
  ^ self basicNew: 3

bounds
  ^ self at: 1
bounds: value
  ^ self at: 1 put: value

fillstyle
  ^ self at: 2
fillstyle: value
  ^ self at: 2 put: value

borderstyle
  ^ self at: 3
borderstyle: value
  ^ self at: 3 put: value


I don't know (it's not clear the future of Traits in squeak), but i
think it's easy to overcome a stateless limits of traits by
introducing schemes which i just illustrated.
Also, if you considered given example, being stateless not really an
issue - it can always can be added dynamically :)

--
Best regards,
Igor Stasenko AKA sig.

Yes
Our first example was taken from rectangleMorph and rectangle and all  
the current delegation

> Let me pick an example, to better illustrate what i have in mind
>
> Rectangle morph.
> It should include a 'shape' trait, because rectangle is just a kind of
> shape (lets assume it's a ShapeTrait subclass - RectangularShape).
> Now, with having shape we can speak of different visual aspects, like
> border and fill.

One idea was that rectangleMorph just plug rectangleShapeTrait to gain  
all the rectangle oriented behavior.
This is interesing. Now the problem is that you may have to recompile  
(and copy down) the methods
where you have instance variable offset conflicts.

Why anonymous? We could just have a normal class
because most of the time you will want to add new behavior to that  
class or resolve conflicts.

On 09/02/2008, stephane ducasse <[hidden email]> wrote: So, it was discussed earlier, can you give me any references where i
can read about it?

It's not a problem, because these methods are generated automatically,
so you can't have offset conflicts in principle.
You may have a name clashing (when two traits using variable with same
name). But this can be resolved easily: we can state that if two
different traits require state with same name, they should use the
same state slot.

Maybe that was a point, to prevent developer to be able to edit this
class directly, to make sure he is unable to change the generated
composition of methods.
How do you think, is it possible to design such architecture, that
there will be no sense to make any changes in final class?
A system which provide enough facilities, that any direct intrusion in
morph class is pointless.


--
Best regards,
Igor Stasenko AKA sig.

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

- Bert -

On 09/02/2008, Bert Freudenberg <[hidden email]> wrote:
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.

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.


> - Bert -
>

--
Best regards,
Igor Stasenko AKA sig.

On Feb 9, 2008, at 22:18 , Igor Stasenko wrote:

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.

- Bert -

On 09/02/2008, Bert Freudenberg <[hidden email]> wrote:
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.

Am Feb 10, 2008 um 12:38 schrieb "Igor Stasenko" <[hidden email]>:

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 -

>
> My personal guess is because it is not "just" another UI. Also there
> appears to be an astonishing lack of interest.
>
>  
An astonishing lack of interest only matched by an astonishing lack of
responsiveness on the tweak mailing list. If you want interest you have
to invest in the community and dare I say it, documentation. Surely the
Seaside story has shown this to be true.

When I first returned to squeak a couple of years ago, I mailed asking
what would be a good thing I could contribute to tweak in terms of
porting things across. I do not recall getting a reply, hence my lack of
interest since.

Keith

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

Hello Igor,

IS> I'd like to start a 'secret' project, which heavily using graphics and
IS> UI.. but i can't choose what system to pick to be used for it: current
IS> Morphic, Tweak, write own, or wait for Morphic3?
IS> I know, my questions is mostly rhetoric, but i'm just curious, if
IS> you(anyone who reads this) would be on my place, what will you choose?

I did the same (with a very low time budget) and choose Morpic.

In the very long run I'll end up with having something like AutoDesk's
DCL (Dialog control language) where you describe your UI as a
composition of rows and columns.

I didn't yet need a GridMorph but I always need some very non standard
widgets.

Feeling assured when Gary Chambers started his UI work on Morphic too.


Cheers

Herbert                            mailto:[hidden email]

Indeed.
Thanks for the pointer.
This is long time ago that I look at tweak.

Stef
On Feb 9, 2008, at 10:02 PM, Bert Freudenberg wrote:

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

Bert I can't let you saying that. ;)
There was an interest. I send emails to both mailing-list so that  
people talked at that time.
You cannot use this argument. :)

As for Sophie some people told me that the event system of Tweak made  
things nearly impossible to debug
so.

Then the different iv semantics (with Xml encodings) was not that nice  
(I would have prefer
(CField name: fill ) vs <xml.....>.   Linking XML parser with class  
internal was always a problem to me. Espcially when
you can use plain smalltalk as for declarative syntax.
Finally having a syntax (may be based on a meta object extension of  
class definition) would be better than you be able
to use the browser to define different kinds of instance variables.  
(At least relying on bold to represent different iv vs
text representation was inadequate. Imagine copy and pasting code....  
and losing semantics.

Igor I posted all that in the tweak mailing-list.

Bert BTW I heard that in fact the tweak of Plopp and sophie were not  
the same as croquet, so it is
true that there were forks inside tweak itself?

Stef

I confirm.
Plus see my other concerns in the other mails.
Note that my other remarks could be fixed really fast (at least the  
point that are not related
with the debugging of events).

Apparently there the problems is that
        Evnt A X B Y Z C got serialized as A B C X Y Z so making debugging  
difficult.
But this is just what I heard not really experienced myself.

Stef

On 11/02/2008, stephane ducasse <[hidden email]> wrote: Hehe, new day, new mail list to subscribe :)
Sure, i'll take a look.

> Bert BTW I heard that in fact the tweak of Plopp and sophie were not
> the same as croquet, so it is
> true that there were forks inside tweak itself?
>
> Stef
>
>


--
Best regards,
Igor Stasenko AKA sig.

Le dimanche 10 février 2008 à 13:04 +0100, Bert Freudenberg a écrit :

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

When I started thinking about DrGeoII, I have been questioning myself
about using Trait or Morph. After a few time, I went to Morph (but with
a suffisance abstraction level to easily switch to something else later)
because I did not fell confident about Trait to be integrated in Squeak
in a close future. I think I did the right choice, although I would have
been happy to be wrong.

The interesting question is "what can we conclude about that?"
Where was the lack of interest?

In free software, people will follow you if they fell confident about
the future of your project. Leadership is important, constant and
recurrent feedback concerning the evolution of the project is important
to attract and to seduce newcomers. Seaside has been doing that with a
lot of successes, so people fell confident about using it, then to
contribute.

Hilaire

do you mean Tweak and Morph?

On Feb 12, 2008, at 9:37 AM, Hilaire Fernandes wrote:

Tweak and Morph, indeed. Sorry for the confusion.

Hilaire


Le mardi 12 février 2008 à 10:37 +0100, stephane ducasse a écrit :
> do you mean Tweak and Morph?
>
> On Feb 12, 2008, at 9:37 AM, Hilaire Fernandes wrote:

On Feb 10, 2008, at 14:40 , Keith Hodges wrote:

>> My personal guess is because it is not "just" another UI. Also there
>> appears to be an astonishing lack of interest.
> An astonishing lack of interest only matched by an astonishing lack of
> responsiveness on the tweak mailing list. If you want interest you  
> have
> to invest in the community and dare I say it, documentation. Surely  
> the
> Seaside story has shown this to be true.

Indeed. The Tweak developers (which really was just Andreas himself  
at that time) did not advocate general usage of Tweak, because they  
could not do the required support on their own. There was a question  
like "will Tweak become the new UI for Squeak?" and the honest answer  
had to be "we don't know, if someone takes it and *makes* it the next  
UI then sure". But nobody did.

Tweak is well and alive as part of Croquet, and the Croquet  
developers in general are happy to experiment with new stuff, even if  
it does not follow traditional Smalltalk philosophy. For example,  
Tweak introduces asynchronous message sends, and that indeed causes  
issues with debuggability as mentioned elsewhere. It is used in  
production, so can't be all bad ;) Tweak questions are best posted to  
the Croquet list nowadays.

- Bert -

Bert Freudenberg wrote:
> Indeed. The Tweak developers (which really was just Andreas himself at
> that time) did not advocate general usage of Tweak, because they could
> not do the required support on their own. There was a question like
> "will Tweak become the new UI for Squeak?" and the honest answer had to
> be "we don't know, if someone takes it and *makes* it the next UI then
> sure". But nobody did.

No, I don't think it's fair to say that. There is a mixture of issues
involved: First, Tweak was never polished in any way and it should have
been before a "wide release" but I never found the time which made it
strictly harder than it necessarily had to be (to insert a pseudo
Ballmer-quote here, imagine him shouting "tutorials, tutorials,
tutorials, tutorials" ;-) Second, it was intended as a research project
so I tried a number of ideas that I had been discussing with Alan for
ages. And, as usual, some of them work, some of them don't (and the ones
that don't leave an unpleasant smell). Third, I  just generally don't
feel up to following through on the storm of emails that *any* proposal
for changing the UI framework again would create (personally, I don't
think anyone can really change such fundamental things in Squeak unless
it's either strictly incremental or comes as a fork - and if it's the
latter you're better off if you have a "movable" code base like Seaside
and solve a problem that isn't solved in other dialects either, again
like Seaside). And lastly, changing jobs and changing servers and now
working at a startup which requires 120% of my time isn't exactly
helpful either for finding time to spread the word ;-)

> Tweak is well and alive as part of Croquet, and the Croquet developers
> in general are happy to experiment with new stuff, even if it does not
> follow traditional Smalltalk philosophy. For example, Tweak introduces
> asynchronous message sends, and that indeed causes issues with
> debuggability as mentioned elsewhere. It is used in production, so can't
> be all bad ;) Tweak questions are best posted to the Croquet list nowadays.

Indeed this is probably the best. Tweak is being used in Qwaq's products
  btw, so if you go to www.qwaq.com and check out our new intro you'll
see some Tweak in action.

Cheers,
   - Andreas