The same in Brick: GLMButtonBrick new
marginLeft: 10; text: 'Parse'; vAlign: #center; hSpaceFill; openInBrickWindow
Yes, I agree - using composition for margin/padding/aligning is much more simple, readable, fast and maintainable, than horrible scripting in brick, sorry for that. One more time for people who still don't hear us. Brick is internal for GT. We just put in package named "Brick" reusable widgets we built to use in our tools. They just normal subclasses of morph. Nothing fancy. We don't want you to use it and suggest to learn Spec for UI, please. Keep Calm :) Cheers, Alex On Tue, Mar 24, 2015 at 4:28 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-03-24 16:03 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 16:02:56 +0100 Subject: Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]
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>:
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
I donât get it sorry.
Padding by ten pixels to the left:
| leftMargin aParserButton | leftMargin := Morph new width: 10; hResizing: #shrinkWrap; vResizing: #spaceFill. aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. aParserButton hResizing: #spaceFill; vResizing: #shrinkWrap; label: 'Parse'. AlignmentMorph newRow vResizing: #shrinkWrap; hResizing: #spaceFill; layoutInset: 0; addMorph: aParserButton; addMorph: leftMargin; openInWorld
Aligning to the center, horizontally: add a right and left morph, but hResizing: #spaceFill this time.
Some type of constraints are hard to do with that system (*), but... LaTeX layout exclusively with that, so, maybe it works ;)
((*) And this is where someone knowing Rubricks could come with a few examples of those).
maybe one example would help
From the SmaCC GUI :)
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)
Ok. But do you know why? There is a reason for that choice.
Spec had a real issue with that ordering, so the pressure will be to get it 'corrected'.
Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic.
Thierry
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