On 24 December 2012 09:43, H. Hirzel <hannes.hirzel@gmail.com> wrote:
Hello Igor
Thank you for this interesting mail. An issue over 11 years old, see below.
On 12/24/12, Igor Stasenko <siguctua@gmail.com> wrote:
Hi,
just wanna share some ideas about how we can cleanup morph a bit.
A bit? It will be a lot of effort.
We can do it in small steps.
Squeak 4.4-12234 (current)
Morph selectors size 1183
Pharo 2.0 (Beta)
Morph selectors size 865
Cuis 4.1 (18th Dec 2012)
Morph selectors size 343
This was an issue in 2001
http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
see
I am not first day here, of course i am aware of this :)
Layout.. bizarre.
Yes, see humorous contribution from June 2001 http://lists.squeakfoundation.org/pipermail/squeak-dev/2001-June.txt
search for
the Morph class has 924 methods
in that mails
There was an effort Morphic Cleanup Project
http://wiki.squeak.org/squeak/3005
lead by
Diego Gomez Deck
It produced some results. But they did not reach far enough.
yes yes.. i know.
However Juan Vuletic was successful in coming up with a simpler Morphic in Cuis.
search this mailing list for Small Morphic. It was an attempt to use Juan's work, which didn't fly.
There are so many methods dedicated to laying out morphs that it easy to get lost.
Cuis has a new layout system.
Worth to check out.
Sure.
For me the main mystery and source of confusion is that there actually two different groups:
- methods to control morph's own layout (in respect to its parent) - methods to control morph's children layout (something called layoutPolicy)
the problem is that both APIs are found in single class,
which one?
Morph
and most of
them contain 'layout' word in it, so it is really hard to determine which one to use and when..
Over a years, i seen that people learned how to use existing functionality, without delving deep into implementation detail.
Yes.
But if you try to extend/change behavior (in your subclass), you will quite soon find out that it is really hard to tell with 100% certainty that the methods you override is the right place for your customization.
Yes, this actually has made development very difficult. In such a way that most people have abandoned it. Very few GUIs are actually built with it.
Also, an important detail is extremely polluted protocol(s), making Morph a GOD class, with so many functions that it is unbearable.
So, what i want to propose is same as i proposed to introduce for "SmalltalkImage" is to use "scoping" accessors , or "delegate" accessor to get access to part of functionality with clear context.
Surely a good intermediary step.
Remember: Smalltalk vm version Smalltalk tools browser
so, lets see how code might look like if we apply same approach to morph protocols:
Example. Original:
column := AlignmentMorph newColumn vResizing: #shrinkWrap; hResizing: #shrinkWrap; layoutInset: 1; borderColor: Color black; borderWidth: 0; wrapCentering: #center; cellPositioning: #center; color: Color white; yourself.
Change:
column := AlignmentMorph newColumn.
column color: Color white. column layout shrinkWrap. "v and h both"
column border width: 0; color: Color black.
column childLayout inset: 1; wrapCentering: #center; cellPositioning: #center.
Cons: - a code is a bit more elaborate. That because, of course, we cannot merge everything into single cascade.
Pros: - from code it is clear, which properties belong to which parts of functionality. You cannot confuse, for instance, whether 'wrapCentering' property controls morph's own layout or a layout of its children - most important, we can considerably shrink Morph's protocol by removing all direct accessors and instead put them into delegated behaviors.
More than that, a delegates don't need to be a dummy state holders (like most of properties are now), but actually an object(s) which conform to certain protocol..
For instance, if we have a 'border' as a delegate, and morph wants to draw it, it could just tell:
MyMorph>>drawOn: aCanvas self border drawOn: aCanvas
btw, then it is actually makes sense having a BorderedMorph subclass, which a) introduces 'border' delegate b) cares to draw its border in contrast to Morph who shouldn't.
As well as in case of layouts, you can tell:
morph layout changed.
or
morph childLayout layOutChildren.
etc.
I can't comment more at the approach at the moment. Could you elaborate it a bit more?
mm.. can you tell, what is not clear to you?
As the leading example of Juan Vuletich shows it is possible to reduce the complexity of Morphic. It would be good to check out what he has written about his work.
I am sure that things i proposing not found in Cuis.
Best regards Hannes Hirzel
-- Best regards, Igor Stasenko.