yes ignore me I am an idiot I missed the fact I need to pass a block as argument to action method now it works as expected, again thank you :)
On Mon, Sep 1, 2014 at 3:23 PM, kilon alios <[email protected]> wrote: > ok looks like I don't understand the Spec documentation well enough. So I > tried this code in workspace based on your code > > dcm := DynamicComposableModel new. > dcm instantiateModels: #(button ButtonModel ). > dcm button label: 'Button'; action: Transcript open. > dcm openWithSpecLayout: (SpecLayout composed > newColumn: [:c | c add: #button]) > > but I have an issue, that action method there I assumed its the action > triggered when I click the button. But instead Transcript opens when I do > the code and if I close the Transcript window and click the button again, > it does not open Transcript. Am I doing something wrong ? I am using latest > Pharo 3 on Ubuntu. > > By the way thank you very much about your reply it looks like Spec is much > closer to what I like that I initially thought , will study the > documentation carefully and try some experiments to gain a better > understanding. > > > On Mon, Sep 1, 2014 at 2:56 PM, Hernán Morales Durand < > [email protected]> wrote: > >> | dcm | >> (dcm := DynamicComposableModel new) >> instantiateModels: #(button ButtonModel). >> dcm button >> label: 'Button'; >> action: [ self halt ]. >> dcm openWithSpecLayout: (SpecLayout composed >> newColumn: [: c | c add: #button ]; >> yourself). >> >> >> >> 2014-09-01 8:49 GMT-03:00 kilon alios <[email protected]>: >> >> 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" >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
