Err..., not really longer nor lots of methods. ButtonModel new label: 'Click me'; whenActionPerformedDo: [Transcript show: 'Clicked!' ]; openWithSpec.
Bear in mind that Spec is based on models, not actual "Morphs". The ComposableModel idea is key here. HTH Phil On Mon, Sep 1, 2014 at 1:49 PM, kilon alios <[email protected]> wrote: > Lets take a very simple example of creating a UI that contains one very > simple button in Morphic I would do: > > button := PluggableButtonMorph new. > button label: 'Button'. > button openInWindow . > > According to Spec to do the same I would need several methods just for > initialization and a separate class to host these methods. > > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/Spec/Spec.pier.html > > I would need initializeWidgets , defaultSpec , list and title . Unless I > am reading the documentation wrong. > > > On Mon, Sep 1, 2014 at 12:26 PM, 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" >>>>> >>>> >>>> >>> >> >
