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" >>> >> >> >
