- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by kilon alios

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. 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, phil(a)highoctane.be <phil(a)highoctane.be> 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 <tudor(a)tudorgirba.com> wrote: > >> +1 to both of you :) >> >> Doru >> >> >> On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> 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" >> > >

Sept. 1, 2014

Re: [Pharo-dev] background color text attribute?

by Tudor Girba

Sorry. I was not explicit enough. We now have a way to set the TextColor of a text. I am looking for a way to do something like this: aText addAttribute: TextBackgroundColor yellow Is there something like this implemented for Text? Cheers, Doru On Sat, Aug 30, 2014 at 5:00 PM, stepharo <stepharo(a)free.fr> wrote: > hi doru > > do you mean like when we select the code? > > Stef > > > On 28/8/14 07:00, Tudor Girba wrote: > > Hi, > > Does any of you know if there is a way to add a background color to a > piece of text? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by phil＠highoctane.be

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 <tudor(a)tudorgirba.com> wrote: > +1 to both of you :) > > Doru > > > On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> 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" >

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by Tudor Girba

+1 to both of you :) Doru On Mon, Sep 1, 2014 at 9:18 AM, stepharo <stepharo(a)free.fr> 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"

Sept. 1, 2014

Re: [Pharo-dev] When all you have is Spec, everything looks like a nail?

by stepharo

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-nai… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 1, 2014

Re: [Pharo-dev] SqNumberParser and PGConnection in Pharo 3

by Sven Van Caekenberghe

On 01 Sep 2014, at 00:21, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Yes... it was intentional. OK, but what about the second part, about it being non-intrusive ? > Because there is no "official" maintainer of the GLORP package, I > didn't want to add stuff to the main codebase. Same story as with the > PostgresV2 package. > > Regards! > > Esteban A. Maringolo > > > 2014-08-31 19:16 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> On 31 Aug 2014, at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>>> ps: There is also other versions of GLORP I didn't bless as #stable. >>> >>> That seems a bit more complicated: the Glorp ancestry is mixed up, we should merge this carefully: >>> >>> you made versions 86 & 87 while those already existed, the latest 88 skips your version. >>> >>> in any case, 88 now works for me, but I fear it skips your code >> >> Ah, I see, this was an intentional branch, right ? >> >> Anyway, your addition seems non-intrusive, since it only adds a type, which does not get used unless one specifically asks for it, correct ? >> >> If so, I can merge this, commit a new version and update the config. >> >> Sven >

Sept. 1, 2014

Re: [Pharo-dev] Latch for Pharo (Opinion needed)

by Max Leske

On 31.08.2014, at 23:32, GermÃ¡n Arduino <garduino(a)gmail.com> wrote: > Hi Guys: > > I'm working in a project to write a SDK for use Latch with Pharo. Latch [1] is a product/service to add a degree of security to web applications and is developed and marketed by 11Paths [2] , a company from TelefÃ³nica. > > It provides very interesting security services [3] but they do not have a Smalltalk SDK (Only Ruby, PHP, Java, .NET, Python, C and PowerShell) then I think that I could write a Pharo SDK and a reference (example) implementation in Seaside, to bring to the Pharo community an interesting tool to add more protection to the Pharo web applications. > > Do you think that this SDK could be of interest for the community? Sounds like a great idea. As Sean said, having a reference implementation would also help a lot when similar services come along. So yes, go for it! > Are you using other tools different of Latch to add security to your web applications? > > Your opinion will be of great help. > > Thanks. > > [1] https://latch.elevenpaths.com/www/index.html > [2] https://www.elevenpaths.com/index.html > [3] https://latch.elevenpaths.com/www/why.html > > -- > Saludos / Regards, > GermÃ¡n Arduino > www.arduinosoftware.com

Sept. 1, 2014

WhatsUp from: 2014-09-01 until: 2014-09-14

by seaside＠rmod.lille.inria.fr

Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! ### Here's what I've been up to since the last WhatsUp: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-09-14 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

Sept. 1, 2014

Re: [Pharo-dev] NeoJSON Mapping name-changing field

by Sean P. DeNigris

Sean P. DeNigris wrote > I ended up with FlickApiResponse class>>neoJsonMapping: mapper... It turns out the Flickr API returns slightly weird JSON responses - the status is on the same level as possible multiple data attributes, so I ended up with (even uglier): neoJsonMapping: mapper mapper for: self customDo: [ :mapping | mapping decoder: [ :dict | | dataDict | dataDict := Dictionary new. (dict keys reject: [ :k | k = 'stat']) do: [ :k | dataDict at: k put: (dict at: k) ]. self new status: (dict at: 'stat'); data: dataDict; yourself ] ] ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545p4775552… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014

Re: [Pharo-dev] NeoJSON Mapping name-changing field

by Sean P. DeNigris

Sean P. DeNigris wrote > How do I handle mapping this second field with NeoJSONReader? Thanks I ended up with FlickApiResponse class>>neoJsonMapping: mapper mapper for: self customDo: [ :mapping | mapping decoder: [ :dict | self new status: (dict at: 'stat'); data: (dict at: dict keys first); yourself ] ] but maybe there's a more elegant way? ----- Cheers, Sean -- View this message in context: http://forum.world.st/NeoJSON-Mapping-name-changing-field-tp4775545p4775547… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 1, 2014