nah, it depends on the size of the method too :) I much prefer 5 methods of 5 lines each than one of 25.
Esteban On 01 Sep 2014, at 11:58, [email protected] wrote: > Doru, > > Some smart snippets welcome :-) > > Can use that for a demo! > > Phil > > > On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <[email protected]> wrote: > For a small prototype GUI, anything longer than one method is too long. > > Doru > > > On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <[email protected]> wrote: > > 2014-09-01 10:20 GMT+02:00 kilon alios <[email protected]>: > > Personally there are two thing I dont like about Spec > > a) There is quite a lot of setup just to start adding things together making > quite verbose for small GUIs. It may be just my lack of understanding but I > find Morphic much easier to use. > > Can you give me an example of this setup for a small GUI? The examples I > have seen so far only use some lines of code in #defaultSpec and some lines > of code > for wiring up the different models (like onSelectedDo, onChangedDo, ...) All > of that are things you would do anyway. > > nicolai > > > > b) I have a deep dislike about the use of pragmas. I know they are useful for > primitives that cant be pure smalltalk objects like for example Nativeboost > but I still feel they brake the uniformity of smalltalk syntax at least in my > eyes. > > On the other hand having something that can quickly produce guis is > essential. But personal I prefer lego-like approaches which is what Morphic > uses. As side note I think designing GUI via code is a bad idea, at least in > my eyes, we need a designer for that, afterall most of the powerful IDEs out > there have GUI designers. Nonetheless wishful thinking is not productive , > Spec is here, it is certainly helpful and I hope it continues to evolve and > improve. > > > On Mon, Sep 1, 2014 at 10:32 AM, [email protected] <[email protected]> > wrote: > When one looks at the implementers of "defaultSpec" (lots of Adapters, > tools), I find it more understandable to figure out how a tool is laid out. > > How to follow what messages are sent around, err... much less understandable > indeed (So, sharing Sean's pain). > > Of course, this is different from inspecting morphs. But it shouldn't be so. > If Morphs where isofunctional with the Adapters, it would be much more > regular. > > It is glaring that the Morphs all have their own little view of the world > with no unified set of protocols, which isn't helping. > > An example: MorphicRadioButtonAdapter > > defaultSpec > <spec> > ^ {#CheckboxMorph. > #on:selected:changeSelected:. #model. #state. #state:. > #label:. > { #model. #label }. > #labelClickable:. > { #model. #labelClickable}. > #beRadioButton. > #hResizing:. > #shrinkWrap. > #vResizing:. > #shrinkWrap. > #setBalloonText:. > #(model help). > #dragEnabled:. > #(model dragEnabled). > #dropEnabled:. > #(model dropEnabled). > #dragEnabled:. > #(model dragEnabled). > #dropEnabled:. > #(model dropEnabled). > "#borderWidth:. > #(model borderWidth). > #borderColor:. > #(model borderColor)"} > > A halo that would outline the SpecLayout bits and pieces would go a long way > in helping people figure out what's going on. A project in itself. > > Now, can we both have a declarative UI and an easy to debug UI? As the > declarative things has its own interpreter and engine? > > Phil > > > > > On Mon, Sep 1, 2014 at 9:22 AM, Tudor Girba <[email protected]> wrote: > +1 to both of you :) > > Doru > > > On Mon, Sep 1, 2014 at 9:18 AM, stepharo <[email protected]> wrote: > Hi sean > > > I've been mulling this over for a while, and since we've been having > conversations about Spec's place in our future... > :) > Good. This is important that everybody express itself. > > > DISCLAIMER: this is a visceral experience I've been having over a long > period of time, so it may not be factually "true" or current, but I present > it as a contribution, if only by someone saying "you're full of crap > because..." and we all learn something. > > The purpose of Spec as I understand it is to both come up with a nice > streamlined UI API, and to make multiple targets (e.g. Morphic, html) > possible with the same codebase. These are both important goals. And it > seems we've made some progress at least in the first case. I definitely > enjoy working with Spec's API far more that e.g. PolyMorph. > > Spec could be a very valuable application-level tool. If I want to write a > business application, I can write once via a nice API and deploy "anywhere". > Life is good. > > My discomfort is with making *all* our core tools Spec-based. > > I agree this is why I started to write some little tool to be able to browse > the system > when Spec is shaking. > > Now when you see the code of the old browser this is not nice either. > So we will see and learn. But I can tell you that nothing is curved in stone. > We will introduce GT but again you will get the same because GT is a > frameworks. > > > While it is great from an "eating our own dog food perspective", one of the > great > principles of Morphic is exploration and discoverability. Many times before > Spec I was able to poke around a tool, figure out how it worked, and apply > that lesson to my own UI. However, with Spec I find it extremely difficult > to figure out WTH is going on. Parsing of arrays of symbols seems to have > replaced Smalltalk code, and each field/model piece of a Spec UI seems to be > buried behind multiple ValueHolder/Adapter/whatever levels. Granted, now > that we have e.g. specialized inspectors, we might be able to alleviate > this. > > We should iterate on it. > May be another framework will be better in the future > > > My 2c. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/When-all-you-have-is-Spec-everything-looks-like-a-nail-tp4775537.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >
