- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roadmap on tools?

by Tim Mackinnon

Guys - this reply has interesting content with potentially useful insight, but I really encourage everyone to think about how to best frame these kinds of comments without âsappingâ the energy out of those writing frameworks like Spec. We all need to make sure that we can have healthy debate and iterate on new ideas but without causing others to feel despondent. We need to energise everyone in our conversations! This was a strong message from ESUG this year (and we didnât always get it right, but we tried to help each other do this). If there are better ideas out there - you really want someone already working on something (which they may have spent lots of energy on already), to not give up in despair, but to seize the opportunity of new insight and apply their knowledge and creative to get a better outcome OR to iterate on their current solution and apply observations from others to create something better. At ESUG, this was a topic of conversation for one of the âShow us your projectsâ slots (disclaimer - I presented that topic on the Zapp framework because I found a few of us in the pub going down a more negative path than we had intended). I presented Zapp - http://www.amazon.co.uk/Zapp-Lightning-Empowerment-William-Byham/dp/0712680… and urged everyone to consider how we can ALL help each send sparks of excitement (aka Zapp) to encourage better things. This seemed to strike a chord in the audience. I wanted to share this - because I certainly appreciate peoples thoughts on all of these topics, but I really donât want to see us have more casualties in our amazing community. So please - try and think âZappâ not âSappâ - and try and use your experience/advice/observations as a way to empower others to make useful change - or consider the direction they may be taking such that they want to do more. Tim p.s. This is easy to say/write - and quite hard to do well. I know we will all make mistakes doing this well - but practicing it is important, and having words like âZappâ and a way to tell each other this is just as important as the code we write. On 28 Aug 2014, at 19:15, kmo <voxkmp(a)gmail.com> wrote: > philippeback wrote >> Building a UI with Morphic alone is what one would use to do something >> very >> custom (like a game for example). >> >> Now, creating a larger UI that way is definitely going to be super pain in >> the assets. >> >> That's where Spec does fit. > > Is there any evidence of this? As far as I know no one has built anything > more complex than a class browser. I would say Spec was incapable of > building a complex interface of any kind. It's clumsy, developer-hostile, > and counter-intuitive. > > The whole Spec process of writing code in three different places is the very > definition of a /super pain in the asset/s. it is far less intuitive to my > mind than creating composite morphs. > > Progress on Spec is glacially slow - but that's not the problem. Spec is > profoundly misconceived and fundamentally flawed and offers nothing over raw > Morphic. The Spec model is simply not how anyone would want to build an > interface in 2014. I certainly would never use it. > > > > > > > > -- > View this message in context: http://forum.world.st/Roadmap-on-tools-tp4774285p4775282.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 1, 2014

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

by Esteban Lorenzano

nah, it depends on the size of the method too :) I much prefer 5 methods of 5 lines each than one of 25. Esteban On 01 Sep 2014, at 11:58, phil(a)highoctane.be wrote: > Doru, > > Some smart snippets welcome :-) > > Can use that for a demo! > > Phil > > > On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > For a small prototype GUI, anything longer than one method is too long. > > Doru > > > On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > 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, 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-nai… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > 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

Doru, Some smart snippets welcome :-) Can use that for a demo! Phil On Mon, Sep 1, 2014 at 11:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > For a small prototype GUI, anything longer than one method is too long. > > Doru > > > On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> 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, 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" >>>>> >>>> >>>> >>> >> > > > -- > 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

For a small prototype GUI, anything longer than one method is too long. Doru On Mon, Sep 1, 2014 at 11:26 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > 2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > 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, 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" >>>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 1, 2014

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

by Tudor Girba

Thanks! Doru On Mon, Sep 1, 2014 at 11:20 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello Doru, > > This feature does not exist on Text. TextAttributes I am aware of > includes: underlined, italic, bold, narrow, struck out, indents, text > color, fonts (fonts work poorly in some circumstances) and alignment > properties. Additional things such as links and URL are there but I have > never achieved to make them work. > > However, highlighting is available directly in PluggableTextMorph. > > If you inspect a NautilusWindow (open Nautilus, use Morph halo to inspect > it), you can have in the iv model the packageTreeNautilusUI, then in the iv > sourceCodeArea a PluggableTextMorphWithLimits. Then in the inspector you > can do: > highlights add: > ((TextHighlight on: self) > color: Color lightBlue; > lineRange: (10 to: 30)) > > After moving once the window, you'll notice this result: > > [image: Images intÃ©grÃ©es 1] > > So to have highlighting for your text I guess you'll have to dig in that > direction ... This is directly implemented on the Morph and not on the Text > so it may be a bit difficult to use. > > Regards. > > ClÃ©ment > > > > > > 2014-09-01 9:41 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > 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" >> > > -- 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 Nicolai Hess

2014-09-01 10:20 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > 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, 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 ClÃ©ment Bera

Hello Doru, This feature does not exist on Text. TextAttributes I am aware of includes: underlined, italic, bold, narrow, struck out, indents, text color, fonts (fonts work poorly in some circumstances) and alignment properties. Additional things such as links and URL are there but I have never achieved to make them work. However, highlighting is available directly in PluggableTextMorph. If you inspect a NautilusWindow (open Nautilus, use Morph halo to inspect it), you can have in the iv model the packageTreeNautilusUI, then in the iv sourceCodeArea a PluggableTextMorphWithLimits. Then in the inspector you can do: highlights add: ((TextHighlight on: self) color: Color lightBlue; lineRange: (10 to: 30)) After moving once the window, you'll notice this result: [image: Images intÃ©grÃ©es 1] So to have highlighting for your text I guess you'll have to dig in that direction ... This is directly implemented on the Morph and not on the Text so it may be a bit difficult to use. Regards. ClÃ©ment 2014-09-01 9:41 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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] PharoLauncher on Windows not the latest version

by kilon alios

I am not back to my work pc, so if you have any ideas how to proceed I am open to suggestions. On Thu, Aug 28, 2014 at 5:17 PM, Tim Mackinnon <tim(a)testit.works> wrote: > Kilon - it would be good if we could percevear to try and get a fix and > detailed instructions for other less confident usersâ¦ At least test Benâs > updated installer so we can clear this. > > I appreciate the aggravation you are putting up with. > > Tim > > On 28 Aug 2014, at 10:35, kilon alios <kilon.alios(a)gmail.com> wrote: > > My work pc is dual boot to ubuntu and win 7 . I am not a fan of linux > either, loads of problems there but nowhere near as bad as windoom. > > I need windoom because of a Greek OCR I use at work to scan legal > documents. I have no choice other than to continue using it. > > I dont care what the corporate world does or the fact that almost 100% of > my fellow lawyers use windoom and some still DOS. Thats their problem :D > > It would be nice to support what 95% of people use out there, but alas I > cant take it anymore. Coding should be fun, Windoom kills my inner child. > Sorry for those that have to tolerate this crap, but I am lucky enough not > to . > > /ranting off > > > On Thu, Aug 28, 2014 at 11:50 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> kilon alios wrote: >> >>> ok thing get worse and worse >>> >>> I try to run pharo as administrator and pharo opens and exits >>> immediately , it creates a stderr which contains the following >>> >>> http://pastebin.com/v9Hpx9pK >>> >>> I found the folder you mentioned and I deleted it , now pharo does not >>> open at all even when run without "run as administrator" >>> Boy I hate Windoom. I also tried Tim link , nothing, pharo opens but >>> does nothing, no gui, nothing. I know it opens because i can see its >>> process in the task manager which i have to terminate manually. >>> I do all my coding and art on macos, I only have windows at work so i >>> can test my code on windoom too, but this was the last straw, I had enough >>> with this uber crappy OS for 17 years now. I am dropping support for it and >>> sticking to MacOS only. >>> Thanks guys for your help but it does not worth it. I hope no other >>> windows user experience my problem. >>> >>> >> I empathize. I've been a Linux advocate for years, but never made the >> full desktop switch since I needed a Windows system for corporate >> compatibility. Then I got a mac-mini to experiment with iPad Mobile Device >> Management, and found it easier to get Latex working on it than on Windows >> (for processing Pillar output), and now I find myself using it for Pharo >> more every day, and my Windows box is starting to be neglected (except I >> still need to migrate my old Thunderbird email archive). >> >> However success in the corporate world still hinges a lot on Windows >> compatibility. I will still have a go at updating PharoLauncher Installer >> to avoid this problem. >> cheers, Ben >> >> P.S. @Tim, Your alternate-VM feature sound interesting. I'll check it >> out. >> >> > >

Sept. 1, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40195 Home: https://github.com/pharo-project/pharo-core

Sept. 1, 2014

[pharo-project/pharo-core] f4de9b: 40195

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f4de9b539c7f2623791a12881f56d70800de285b https://github.com/pharo-project/pharo-core/commit/f4de9b539c7f2623791a1288… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-09-01 (Mon, 01 Sep 2014) Changed paths: A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/README.md A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/definition.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/README.md A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/resetCurrent.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/class initialization/initialize.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/definition.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/addFromFileContents_baseName_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/cacheEmbeddedFileInfo_index_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/embedFilesInDirectory_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/installAllFontsIn_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/provider_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/accessing/validEmbeddedCachedInfoFor_index_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/adding/addFirstFileInfo_index_.st A EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/instance/initialization/initialize.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/README.md A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/definition.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/baseName.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/baseName_.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileContents.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileContents_.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileSize.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/locationType.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/printing/printOn_.st A EmbeddedFreeType.package/FreeTypeEmbeddedFileInfo.class/instance/testing/isEmbedded.st A EmbeddedFreeType.package/OpenSansRegular.class/README.md A EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/OpenSansRegular.class/definition.st A EmbeddedFreeType.package/SourceCodeFonts.class/README.md A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/codeFontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/fontButton_size_.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/fontName.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFonts_.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/sizeHuge.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/sizeLarge.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/sizeMedium.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/sizeSmall.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/sizeVeryLarge.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/useSourceCode.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/useSourceCode_.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/settings/fontSourceCodeRow.st A EmbeddedFreeType.package/SourceCodeFonts.class/class/settings/settingsOn_.st A EmbeddedFreeType.package/SourceCodeFonts.class/definition.st A EmbeddedFreeType.package/SourceCodeFonts.class/instance/notes/seeClassSide.st A EmbeddedFreeType.package/SourceCodeProRegular.class/README.md A EmbeddedFreeType.package/SourceCodeProRegular.class/class/accessing/fontContents.st A EmbeddedFreeType.package/SourceCodeProRegular.class/class/accessing/originalFileName.st A EmbeddedFreeType.package/SourceCodeProRegular.class/class/class initialization/initialize.st A EmbeddedFreeType.package/SourceCodeProRegular.class/definition.st A EmbeddedFreeTypeTests.package/EmbeddedFreeTypeFontInstallerTest.class/README.md A EmbeddedFreeTypeTests.package/EmbeddedFreeTypeFontInstallerTest.class/definition.st A EmbeddedFreeTypeTests.package/EmbeddedFreeTypeFontInstallerTest.class/instance/tests/testIsRegistred.st A EmbeddedFreeTypeTests.package/EmbeddedFreeTypeFontInstallerTest.class/instance/tests/testinstallAllFontsIn.st A EmbeddedFreeTypeTests.package/extension/FreeTypeFontProvider/instance/includesInstaller_.st R FreeType.package/EmbeddedFreetypeFont.class/README.md R FreeType.package/EmbeddedFreetypeFont.class/class/accessing/fontContents.st R FreeType.package/EmbeddedFreetypeFont.class/class/accessing/installAllFontsIn_.st R FreeType.package/EmbeddedFreetypeFont.class/class/accessing/installFontsIn_.st R FreeType.package/EmbeddedFreetypeFont.class/class/accessing/originalFileName.st R FreeType.package/EmbeddedFreetypeFont.class/definition.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/README.md R FreeType.package/FreeTypeEmbeddedFileInfo.class/definition.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/baseName.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/baseName_.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileContents.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileContents_.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/fileSize.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/accessing/locationType.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/printing/printOn_.st R FreeType.package/FreeTypeEmbeddedFileInfo.class/instance/testing/isEmbedded.st M FreeType.package/FreeTypeFontProvider.class/class/class initialization/initialize.st M FreeType.package/FreeTypeFontProvider.class/definition.st A FreeType.package/FreeTypeFontProvider.class/instance/accessing/addFileInfo_.st A FreeType.package/FreeTypeFontProvider.class/instance/accessing/addFontInstaller_.st R FreeType.package/FreeTypeFontProvider.class/instance/accessing/addFromFileContents_baseName_.st R FreeType.package/FreeTypeFontProvider.class/instance/accessing/cacheEmbeddedFileInfo_index_.st M FreeType.package/FreeTypeFontProvider.class/instance/initialization/initialize.st R FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/embedFilesInDirectory_.st A FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFontsFromSystem.st R FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/validEmbeddedCachedInfoFor_index_.st A FreeType.package/FreeTypeFontProvider.class/instance/removing/removeFontInstaller_.st R FreeType.package/OpenSansRegular.class/README.md R FreeType.package/OpenSansRegular.class/class/accessing/fontContents.st R FreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st R FreeType.package/OpenSansRegular.class/class/class initialization/initialize.st R FreeType.package/OpenSansRegular.class/definition.st R FreeType.package/SourceCodeFonts.class/README.md R FreeType.package/SourceCodeFonts.class/class/accessing/codeFontName.st R FreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st R FreeType.package/SourceCodeFonts.class/class/accessing/fontButton_size_.st R FreeType.package/SourceCodeFonts.class/class/accessing/fontName.st R FreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFonts_.st R FreeType.package/SourceCodeFonts.class/class/accessing/sizeHuge.st R FreeType.package/SourceCodeFonts.class/class/accessing/sizeLarge.st R FreeType.package/SourceCodeFonts.class/class/accessing/sizeMedium.st R FreeType.package/SourceCodeFonts.class/class/accessing/sizeSmall.st R FreeType.package/SourceCodeFonts.class/class/accessing/sizeVeryLarge.st R FreeType.package/SourceCodeFonts.class/class/accessing/useSourceCode.st R FreeType.package/SourceCodeFonts.class/class/accessing/useSourceCode_.st R FreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st R FreeType.package/SourceCodeFonts.class/class/settings/fontSourceCodeRow.st R FreeType.package/SourceCodeFonts.class/class/settings/settingsOn_.st R FreeType.package/SourceCodeFonts.class/definition.st R FreeType.package/SourceCodeFonts.class/instance/notes/seeClassSide.st R FreeType.package/SourceCodeProRegular.class/README.md R FreeType.package/SourceCodeProRegular.class/class/accessing/fontContents.st R FreeType.package/SourceCodeProRegular.class/class/accessing/originalFileName.st R FreeType.package/SourceCodeProRegular.class/class/class initialization/initialize.st R FreeType.package/SourceCodeProRegular.class/definition.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script195.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40195.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40195 13185 Move embedded fonts from Freetype package into separate package https://pharo.fogbugz.com/f/cases/13185 http://files.pharo.org/image/40/40195.zip

Sept. 1, 2014