December 2014 - Pharo-users

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by stepharo

I will add that to the metacello chapter! Le 19/12/14 19:00, Dale Henrichs a Ã©crit : > With classic Metacello (using the `(ConfigurationOfxxx project > version: 'xxx') load` pattern) you can only downgrade via an explicit > load of a particular version of the project. When loading projects > indirectly via a project reference from another project Metacello is > biased towards upgrade. > > With the Metacello Scripting API[1], you may include an > #onDowngradeUseIncoming: clause to selectively permit downgrades: > > Metacello new > configuration: 'DummyParser'; > version: '1.0'; > repository: '???'; > onDowngradeUseIncoming: #('PetitParser'); > load. > > For additional downgrade options see[2]. > > Since you are interested in using a specific version of a project you > may also be interested in locking the project[3][4]. With a `lock` > Metacello will not upgrade or downgrade the project but always `honor` > the lock unless an #onLock: clause is used ... > > Note that for `locking` to work, you must use the Metacello Scripting > API to do all of your project loads ... > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [3] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [4] > https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR…

Dec. 21, 2014

Glamour detecting changes?

by Daniel Lyons

I have a pretty simple class and I'm using a GLMFinder to browse its contents. If I make changes to the instance I'm browsing, it doesn't look like Glamour detects the changes and refreshes. I'm using self changed: #property in the setter. If I navigate backwards and unselect, and re-browse into it, it sees the changes. What should I do? Thanks again! â Daniel Lyons

Dec. 21, 2014

Re: [Pharo-users] Spec: "pluggable" widgets / label-input layout?

by stepharo

> > Don't add a method to do the layout or don't name it #layout? dont name it layout. > The tutorial doesn't say what to name the method, just that it can be > named anything using the pragma. > >> >> I have two questions about the Spec side of the house: >> >> 1. The title/costWidget whenTextChanged: stuff. With Polymorph, I >> can just say, here's an object, here's the getter/setter, deal >> with it. Does Spec have anything like this, or do you have to do >> this manual data shuffling? Is there an example I can learn from? >> >> >> If you just want to show an edit dialog, I would separate the >> Acitivty-Model (two textfields) from your domain model "Activity". >> Then you don't need this "whenTextChanged". This is only needed if >> other elements from the model >> depend on the textfield content. >> >> Now you can use spec to only show a dialog and after closing this >> dialog you can retrieve the values with >> >> activitiy title: theDialogModel titleWidget text >> activity cost: theDialogModel costWidget text >> .... > > OK, but two questions: > > 1. How do I know when the dialog is finished? > 2. That's going to be a lot of manual copying compared to the > Polymorph version. Is that just life or are there "pluggable" widgets > that will talk to my model directly? > >> >> 2. This layout is a bit on the ugly side. I looked at the >> examples and saw usage of the expert layout with asking how tall >> a line is. Is that the best that can be done, or is there >> something more like Polymorph's label layout that can be used >> instead? >> >> >> you can define the hight of the rows based on the inputfield default >> height (based on the current theme) (ComposableModel class >> >>#defaultInputHeight >> >> Take a look at Komitters CredentialEditor > > Thanks! > >> >> >> Thanks for your time and patience! >> >> â >> Daniel Lyons >> > > â > Daniel Lyons > > >

Dec. 20, 2014

Re: [Pharo-users] Spec: "pluggable" widgets / label-input layout?

by Daniel Lyons

> On Dec 20, 2014, at 4:06 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > The spec part of your question: > > 2014-12-20 5:49 GMT+01:00 Daniel Lyons <fusion(a)storytotell.org <mailto:fusion@storytotell.org>>: > Supposing I have a domain model, Activity, which looks like this: > > Object subclass: #Activity > instanceVariableNames: 'title cost' > classVariableNames: '' > category: 'PERT' > > Then I have the expected accessors for title and cost. > > Now the Spec version of this I have looks like this: > > SpecEditActivity>>initializePresenter > super initializePresenter. > titleWidget whenTextChanged: [ :newText | activity title: newText ]. > costWidget whenTextChanged: [ :newCost | activity cost: newCost ] > > Then on the class side of things, I have this layout: > > SpecEditActivity class>>layout > <spec> > ^ SpecLayout composed > newColumn: [ :column | > column > newRow: [ :row | > row > add: #titleLabel; > add: #titleWidget ]; > newRow: [ :row | > row > add: #costLabel; > add: #costWidget ] ]; > yourself > > I make all the expected "getter" methods. > > I can see how to get the model value out: I do something like this: > > activityDialog := SpecEditActivity new openDialogWithSpec; yourself. > activityDialog model activity > > First, please don't add a method #layout on the class side, this conflicts with the notion of "Slots" (bug reported, but it is not fixed yet) Don't add a method to do the layout or don't name it #layout? The tutorial doesn't say what to name the method, just that it can be named anything using the pragma. > > > I have two questions about the Spec side of the house: > > 1. The title/costWidget whenTextChanged: stuff. With Polymorph, I can just say, here's an object, here's the getter/setter, deal with it. Does Spec have anything like this, or do you have to do this manual data shuffling? Is there an example I can learn from? > > If you just want to show an edit dialog, I would separate the Acitivty-Model (two textfields) from your domain model "Activity". Then you don't need this "whenTextChanged". This is only needed if other elements from the model > depend on the textfield content. > > Now you can use spec to only show a dialog and after closing this dialog you can retrieve the values with > > activitiy title: theDialogModel titleWidget text > activity cost: theDialogModel costWidget text > .... OK, but two questions: 1. How do I know when the dialog is finished? 2. That's going to be a lot of manual copying compared to the Polymorph version. Is that just life or are there "pluggable" widgets that will talk to my model directly? > > > 2. This layout is a bit on the ugly side. I looked at the examples and saw usage of the expert layout with asking how tall a line is. Is that the best that can be done, or is there something more like Polymorph's label layout that can be used instead? > > you can define the hight of the rows based on the inputfield default height (based on the current theme) (ComposableModel class >>#defaultInputHeight > > Take a look at Komitters CredentialEditor Thanks! > > > Thanks for your time and patience! > > â > Daniel Lyons â Daniel Lyons

Dec. 20, 2014

Re: [Pharo-users] How to open the Settings style dialog?

by Nicolai Hess

2014-12-15 17:15 GMT+01:00 Rafael Luque <rafael.luque.leiva(a)gmail.com>: > Hi all, > > I was reading about the Settings framework (Deep Into Pharo, chapter 5) > and I don't find the way to popup the style dialog shown in Figure 5.11 in > page 71 ( > https://books.google.es/books?id=Qki8BQAAQBAJ&lpg=PA68&dq=pharo%20the%20sty… > ). > > I'm using a Pharo 4 image. > > Thank you > The last occurence of the "Style" menu in the settings browser, I found, is Pharo 1.3.

Dec. 20, 2014

Re: [Pharo-users] Question about Morphic in Pharo 4

by Trygve Reenskaug

I can't resist adding my pennyworth to this discussion. The ST vision was to empower "children of all ages" to master their own programs. This gives me an imperative discriminator for all my work: Am I making the programs more readable? If not, don't do it. I have been programming Smalltalk since 1978 starting with ST76, ST78, ST80, and VisualWorks. VW evolved steadily into greater complexity, thus moving away from the goal. Squeak emerged as a new beginning, but I am much afraid that I again see a steady movement away from the goal towards increasing complexity. I regret it, because I believe the original goal is well worth pursuing. (I'll soon be transferring to Pharo, hoping I'll find what I'm looking for there). Example: The first thing I have always done when moving to a new ST dialect is to modify SystemWindow. The system default has been to open a new window with default size and more or less random position. My personal preference is to retain control and open it in /Rectangle fromUser/. This has always been very easy to achieve with a small modification of a SystemWindow class method. I am now in the process of moving from Squeak 3.10 to 4.5. I have spent several unsuccessful hours trying to add my fix. I find a new layer of runtime Spec code between me and the SystemWindow. I fail to see how this can make the code easier to master. I think I have read somewhere that this automatically generated code is not even intended for human consumption. This seems to me to be a great pity and an opportunity lost. Much of the Morphic complexity may be essential because it is caused by its great power and flexibility, but user/programmers need to be protected from this complexity. Not by hiding Morphic, but by helping the user/programmer create code for it. Wouldn't it be great if something like Spec were an IDE that generated exemplary Morphic code? Leverage implies rigidity, so there would be different Specs for different purposes. One for property sheets, one for tables, etc. I currently need to create a property sheet but am not looking forward to the Morphic chore. I know that the resulting code should be simple, but I also know that it will take me a very long time to find it. Wouldn't it be nice if I could create my property sheet through a simple Spect tool. Afterwards, I could read the generated Morphic code and say: Aha! So that's how I should have done it. Just a dream. --Trygve On 20.12.2014 14:08, Esteban Lorenzano wrote: >> On 20 Dec 2014, at 13:44, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> kilon.alios wrote >>> even if continue to use Spec I will stiil have to rely on Morphic >>> since custom GUIs is really important for me. >> Yes, that's why they can not be compared: >> Morphic = make and understand any UI >> Spec = make common business UIs easily (on top of a general framework like >> Morphic) > but thatâs not completely true because in that case Morphic should be just the âgraphic atomsâ while spec should provide a set of widgets (made with those atoms), when what actually happens is that Morphic is everything: the atoms, the widgets, layers ever those widgets and even theming, etc. Soâ¦ is not correctly designed. Or better said: it has evolved in a way that now needs a massive reengineering to make it right. > And Spec, instead being a set of widgets with a declarative way to compose them, is yet another layer on top of other layers. > > cheers, > Esteban

Dec. 20, 2014

Re: [Pharo-users] Question about Morphic in Pharo 4

by kilon alios

no I am sorry but I cannot understand it, looks like I am too stupid for Spec . Its ok though thats my fault , thank you all for trying to help me understand. Unfortunately the whole design of Spec looks extremely hard to me. On Sat, Dec 20, 2014 at 3:48 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > This is how I would do it. (see attachement) > What do you say? Is it clearer now what I meant with > compose and reusable models? > > I am curios how would a pure morphic based solution look like. > > As it is just a simple dialog, I think the pure morphic version would be > similar (in code size) > and of course, it can be build by small reusable parts as well. > > > > 2014-12-20 0:18 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > >> yes you can find my code here >> >> https://github.com/kilon/Nireas >> >> >> >> On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> >> wrote: >> >>> 36 methods for your UI is way too much. I suppose you are doing >>> something wrong somewhere. You should not need all of these steps. It >>> should be: >>> >>> First you add the instance var (e.g. button) and accessors (BTW: >>> Generate the accessors. Itâs 3 keystrokes and a click), otherwise the UI >>> object cannot reference its widgets. >>> >>> For 1) see my previous mail. The idea is to have 1 clear responsibility >>> per method, itâs good software engineering principles to do that. >>> >>> You donât need to do 2) >>> >>> 3) if you donât put a specific object inside the variable there is no >>> way for the system to know what kind of widget you want. >>> >>> 4) yes this makes sense :-) >>> >>> I do not understand what you mean with 5), sorry. I donât do anything >>> like that. >>> >>> 6) you have to state where this button has to go, there is no way around >>> that. Class side is not so intuitive, OK. But at least all the layout is in >>> one place so we have 1 clear responsibility for each method. >>> >>> To summarize, there are 4 steps and none of them can really be omitted. >>> >>> I would like to have a look at your UI class so I can figure out whatâs >>> going on. Can you tell me where to find it? >>> >>> > On Dec 19, 2014, at 16:54, kilon alios <kilon.alios(a)gmail.com> wrote: >>> > >>> > "Can you help me understand?" >>> > >>> > sure take this simple example I want to add a button for choosing >>> background color, I am giving you the list of my problems >>> > >>> > 1) If I want to initialise it I cant use the initialise method of my >>> class (why ? ) I have to use initializeWidgets >>> > >>> > 2) Inside initializeWidget I create an array that describes the name >>> of each button but no that is not enough >>> > >>> > 3) I have also have to initialise seperately the button with self >>> newButton but wait that is not enough >>> > >>> > 4) I have to define the action of the button the only step here that >>> makes sense to me but even that is not enough >>> > >>> > 5) I have to create a method that returns the name of the button and >>> to makes things even more verbose >>> > >>> > 6) I have to define a method at the class side for positioning the >>> button . No idea why this goes to the class side >>> > >>> > And all that so I can say to Spec take this button which has this >>> label and will trigger this method and put it in that place. Java Swing is >>> not that verbose. >>> > >>> > Generally I dont like this approach that I need to generate so many >>> method and so many steps to define something so simple. >>> > >>> > So what happens right now is that I have a very simple GUI with 7 >>> buttons and 6 moprh that i use to display colors , guess how many methods >>> my class has . >>> > >>> > 36 !!! >>> > >>> > By the way in case you wonder 90% of the code is just Spec. For me >>> thats plain unacceptable. >>> > >>> > So what happens if I have a GUI with over 100 buttons do I need 300 >>> methods just for Spec ? Really ?? >>> >>> >>> >>> ---> Save our in-boxes! http://emailcharter.org <--- >>> >>> Johan Fabry - http://pleiad.cl/~jfabry >>> PLEIAD lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >> >

Dec. 20, 2014

Re: [Pharo-users] Question about Morphic in Pharo 4

by kilon alios

ok thank you for taking it the time explaining things. I will figure this out myself. On Sat, Dec 20, 2014 at 3:46 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > This is my last mail to the thread as we are going around in circles. > > > "I focused on you splitting up into methods because that was a complaint > of yours and you said you were following Spec examples when doing that." > > > > But I think I have been crystal clear about this my main issues were 2 > > And you also said that you had a class with 36 methods and you were > clearly upset about it. There were three exclamation marks. > > > 2) I have to return each spec element which makes sense to me but what > annoys me is that I have to do it verbosely by returning each variable > separately in its own method. Instead inside a single method and pass it as > an array which would reduce the amount of methods used dramatically. > > These methods are called accessors. Please use the conventional > terminology so that we can better understand each other. You were talking > about the names of the spec elements before and that was very confusing > (and you never cleared it up). > > As I said in a previous mail, you donât write accessors by hand, you > generate them. Try in Nautilus: click on a class name, right click for the > menu, Refactoring->Class Refactoring->Generate accesors. Or cmd-h-a. It > will propose a list of accessors to generate for you. > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > >

Dec. 20, 2014

Re: [Pharo-users] Question about Morphic in Pharo 4

by Nicolai Hess

This is how I would do it. (see attachement) What do you say? Is it clearer now what I meant with compose and reusable models? I am curios how would a pure morphic based solution look like. As it is just a simple dialog, I think the pure morphic version would be similar (in code size) and of course, it can be build by small reusable parts as well. 2014-12-20 0:18 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > yes you can find my code here > > https://github.com/kilon/Nireas > > > > On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> > wrote: > >> 36 methods for your UI is way too much. I suppose you are doing something >> wrong somewhere. You should not need all of these steps. It should be: >> >> First you add the instance var (e.g. button) and accessors (BTW: Generate >> the accessors. Itâs 3 keystrokes and a click), otherwise the UI object >> cannot reference its widgets. >> >> For 1) see my previous mail. The idea is to have 1 clear responsibility >> per method, itâs good software engineering principles to do that. >> >> You donât need to do 2) >> >> 3) if you donât put a specific object inside the variable there is no way >> for the system to know what kind of widget you want. >> >> 4) yes this makes sense :-) >> >> I do not understand what you mean with 5), sorry. I donât do anything >> like that. >> >> 6) you have to state where this button has to go, there is no way around >> that. Class side is not so intuitive, OK. But at least all the layout is in >> one place so we have 1 clear responsibility for each method. >> >> To summarize, there are 4 steps and none of them can really be omitted. >> >> I would like to have a look at your UI class so I can figure out whatâs >> going on. Can you tell me where to find it? >> >> > On Dec 19, 2014, at 16:54, kilon alios <kilon.alios(a)gmail.com> wrote: >> > >> > "Can you help me understand?" >> > >> > sure take this simple example I want to add a button for choosing >> background color, I am giving you the list of my problems >> > >> > 1) If I want to initialise it I cant use the initialise method of my >> class (why ? ) I have to use initializeWidgets >> > >> > 2) Inside initializeWidget I create an array that describes the name >> of each button but no that is not enough >> > >> > 3) I have also have to initialise seperately the button with self >> newButton but wait that is not enough >> > >> > 4) I have to define the action of the button the only step here that >> makes sense to me but even that is not enough >> > >> > 5) I have to create a method that returns the name of the button and to >> makes things even more verbose >> > >> > 6) I have to define a method at the class side for positioning the >> button . No idea why this goes to the class side >> > >> > And all that so I can say to Spec take this button which has this label >> and will trigger this method and put it in that place. Java Swing is not >> that verbose. >> > >> > Generally I dont like this approach that I need to generate so many >> method and so many steps to define something so simple. >> > >> > So what happens right now is that I have a very simple GUI with 7 >> buttons and 6 moprh that i use to display colors , guess how many methods >> my class has . >> > >> > 36 !!! >> > >> > By the way in case you wonder 90% of the code is just Spec. For me >> thats plain unacceptable. >> > >> > So what happens if I have a GUI with over 100 buttons do I need 300 >> methods just for Spec ? Really ?? >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD lab - Computer Science Department (DCC) - University of Chile >> >> >> >

Dec. 20, 2014

Re: [Pharo-users] Question about Morphic in Pharo 4

by Johan Fabry

This is my last mail to the thread as we are going around in circles. > "I focused on you splitting up into methods because that was a complaint of yours and you said you were following Spec examples when doing that." > > But I think I have been crystal clear about this my main issues were 2 And you also said that you had a class with 36 methods and you were clearly upset about it. There were three exclamation marks. > 2) I have to return each spec element which makes sense to me but what annoys me is that I have to do it verbosely by returning each variable separately in its own method. Instead inside a single method and pass it as an array which would reduce the amount of methods used dramatically. These methods are called accessors. Please use the conventional terminology so that we can better understand each other. You were talking about the names of the spec elements before and that was very confusing (and you never cleared it up). As I said in a previous mail, you donât write accessors by hand, you generate them. Try in Nautilus: click on a class name, right click for the menu, Refactoring->Class Refactoring->Generate accesors. Or cmd-h-a. It will propose a list of accessors to generate for you. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Dec. 20, 2014