Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
2015-03-24 15:27 GMT+01:00 Alain Plantec via Pharo-dev < pharo-dev@lists.pharo.org>:
---------- Message transféré ---------- From: Alain Plantec <alain.plantec@yahoo.com> To: Pharo Development List <pharo-dev@lists.pharo.org> Cc: Date: Tue, 24 Mar 2015 15:27:18 +0100 Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?] Hello Thierry,
Le 24 mars 2015 à 15:24, Thierry Goubier <thierry.goubier@gmail.com> a écrit :
One of the problem is that the Morphic replacement will probably be less than Morphic was (or was intended to be) :(
why do you think so ?
Because we're doing a rewrite, with no uses of the specifics of what Morphic uses. So whatever usage of a pattern of code, or of layout or display that was special to Morphic, will disappear: nobody will keep dead code which only exercise a corner case of Morphic alone. IMHO, Rubrics, just from it's layout approach, is already a step backward. Who knows why a Morph does z-ordering of its submorphs in the reverse order of all other gui toolkits? Has Bloc kept that? Why should it keep it? It's messing up Spec gui building. It will be disappear. Thierry
Cheers Alain
You'll probably tell me that for the kind of work we're doing in UI with
Pharo, we don't need the power of Morphic and I'd agree with you.
Still, I will miss the demise of Morphic.
Thierry
2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier@gmail.com>:
IMHO, Rubrics, just from it's layout approach, is already a step backward.
What you mean by this? What's wrong with Rubric layouting?
2015-03-24 15:39 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier@gmail.com>:
IMHO, Rubrics, just from it's layout approach, is already a step backward.
What you mean by this? What's wrong with Rubric layouting?
Padding -> resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget Aligning -> resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget ZOrdering -> nothing says that submorphs in Morphic can't overlay each other. One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout. Thierry
Le 24 mars 2015 à 15:56, Thierry Goubier <thierry.goubier@gmail.com> a écrit :
2015-03-24 15:39 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>>:
2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>: IMHO, Rubrics, just from it's layout approach, is already a step backward.
What you mean by this? What's wrong with Rubric layouting?
Padding -> resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget
Aligning -> resolved in Morphic by Morph composition: no need to add that to the Layout engine of each widget
I donât get it sorry. maybe one example would help
ZOrdering -> nothing says that submorphs in Morphic can't overlay each other.
Bloc uses z-ordering exactly as Morphic (the code for adding/removing a submorph are nearly the same) Cheers Alain
One of the issue with Morphic as it stands today is that the API is fairly complex if you want to carefully control placement and morph behavior under container resizing / move. Oh, and it's very buggy too. Rubricks shows an API which is even more complex, which isn't surprising if the inspiration is CSS layout.
Thierry
participants (3)
-
Alain Plantec -
Denis Kudriashov -
Thierry Goubier