Oh this is great, I am so glad I was wrong :) Looks like the design of Spec is much better than I first thought.
How do I change the color of the button I tried using the color: message from ButtonModel superclass AbstractWidgetModel but button remains grey. On Mon, Sep 1, 2014 at 4:15 PM, [email protected] <[email protected]> wrote: > 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" >>>>>> >>>>> >>>>> >>>> >>> >> >
