- Pharo-users - lists.pharo.org

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

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

by Esteban Lorenzano

> 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 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796532.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Dec. 20, 2014

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

by Sean P. DeNigris

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) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796532.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 20, 2014

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

by Nicolai Hess

The spec part of your question: 2014-12-20 5:49 GMT+01:00 Daniel Lyons <fusion(a)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) > > 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 .... > > 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 for your time and patience! > > â > Daniel Lyons > > > > >

Dec. 20, 2014

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

by Nicolai Hess

2014-12-20 5:49 GMT+01:00 Daniel Lyons <fusion(a)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. > > I make a Polymorph dialog for editing one of these things like so: > > PolymorphEditActivity>>edit: anActivity > | builder content dialog | > activity := anActivity. > builder := Smalltalk ui theme builder. > > content := builder newLabelGroup: { > 'Title' -> (builder newTextEntryFor: self activity > getText: #title setText: #title: help: 'The title of the activity'). > 'Cost' -> (builder newTextEntryFor: self activity getText: > #cost setText: #cost: help: 'The cost of the activity') > }. > dialog := builder newPluggableDialogWindow: 'Edit activity' for: > content. > ^ builder openModal: dialog. > > *First question*: how do I return a value from the dialog? > You don't need the return something, you don't even need to use a separate instvar in the PolymorphEditActivity. If "anActivity" is a Activity with the accessor #title / #title: #cost/#cost:, the PluggableDialogWindow will change this attributes only if the dialog is closed with "OK" | anActivity builder content dialog | anActivity := Activity new. anActivity title: 'what'. anActivity cost: '100'. builder := Smalltalk ui theme builder. content := builder newLabelGroup: {('Title' -> (builder newTextEntryFor: anActivity getText: #title setText: #title: help: 'The title of the activity')). ('Cost' -> (builder newTextEntryFor: anActivity getText: #cost setText: #cost: help: 'The cost of the activity'))}. dialog := builder newPluggableDialogWindow: 'Edit activity' for: content. builder openModal: dialog. anActivity inspect

Dec. 20, 2014

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

by kilon alios

"This is an explanation of how the whole is composed of the different parts and how different responsibilities of the UI are split up amongst different classes. In Morphic these are joined and thatâs a reason why many persons are unhappy with it." AFAIK the idea behind MVC is a GUI system that is divided into 3 elements each element represented by a class. Model, View , Controller. Model is where the data is resides and as a class it has methods to process the data. View is the graphical element itself that is displayed on the screen . Controller is responsible for the interaction of the View with mainly handling keyboard and mouse events. >From my observations I see that the pitfall of Morphic is that it mixes View with the Controller, since Morph handles also its own events. I fail to see however how Morphic forces you to also mix in your Model to the View. I fail to see how a Morph would force me to put my data inside it . I am really interested in understanding this as it will help me not only like Spec but also prepare myself for any problem I experience with Morphic because even if continue to use Spec I will stiil have to rely on Morphic since custom GUIs is really important for me. "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 1) Spec was forcing to define an array and then also initialise using classes for each spec element. This is where I was wrong. I am very happy I was wrong. 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. 3) I did not like the name "defaultSpec" again I was wrong, since as I was notified I can use whatever name I want as long as I use the pragma Braking down to smaller methods is something Pharo is doing everwhere. Its pretty rare to find methods 20 lines long like you were proposing if I united all these methods. Yes some example of Spec do that . The example with really long method is the dynamic spec example which in that case it makes sense for the method to be long as it acts this way to illustrate the dynamic nature of spec. On Sat, Dec 20, 2014 at 3:18 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > On Dec 19, 2014, at 21:54, kilon alios <kilon.alios(a)gmail.com> wrote: > > > > "UI Element = an interactive graphical element displayed as part of the > Graphical User Interface. > > UI Model = an object that contains the state and behavior of one or > several UI elements." > > > > "To define a user interface, it is sufficient to define the model of the > user interface. [â¦] since all UIs are constructed through composition of > other UI's, and it is sufficient to define the model to define the UI, the > root class of all UIs is named ComposableModel.So, to define a new user > interface, a subclass of ComposableModel needs to be created.â" > > > > I dont understand this for me a GUI is a UI with graphics I dont see it > as two separate entities. I dont see what the model is in my case and why I > should inform Spec about it. I just wanted to create some buttons I dont > see how those method returning the names of the buttons as instance > variables helps me in any way. Whats the benefit ? > > This is an explanation of how the whole is composed of the different parts > and how different responsibilities of the UI are split up amongst different > classes. In Morphic these are joined and thatâs a reason why many persons > are unhappy with it. > > > "Just wondering, did you see an example with the double instantiation of > models or with the needles splitting up in methods? If so tell us where it > is so we can fix it." > > > > Double initiation may have been just me not understanding documentation > or probably I saw an example that confused me. Splitting up methods is > probably the first thing I learned using Squeak and Pharo. Also The system > browser turns red if you make long methods . > > 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. > > ---> 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