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.goub...@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.plan...@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.goub...@gmail.com> a >> écrit : >> >> >> >> 2015-03-24 15:39 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: >> >>> >>> 2015-03-24 17:36 GMT+03:00 Thierry Goubier <thierry.goub...@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 >> >> >> >> >
