- Pharo-users - lists.pharo.org

Spec: "pluggable" widgets / label-input layout?

by Daniel Lyons

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? Now the Spec version of this I have looks like this: ComposableModel subclass: #SpecEditActivity instanceVariableNames: 'activity titleLabel costLabel titleWidget costWidget' classVariableNames: '' category: 'PERT' SpecEditActivity>>initializeWidgets "Set up the widgets for the dialog" titleWidget := self newTextInput. titleLabel := self newLabel. costWidget := self newTextInput. costLabel := self newLabel. titleLabel label: 'Title:'. costLabel label: 'Cost:'. self focusOrder add: titleWidget; add: costWidget 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 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? 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? Thanks for your time and patience! â Daniel Lyons

Dec. 20, 2014

Re: [Pharo-users] [ANN] RProjectConnector V1.0

by HernÃ¡n Morales Durand

2014-12-19 7:52 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com>: > > > > > *De :* Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] *De la > part de* HernÃ¡n Morales Durand > *EnvoyÃ© :* jeudi 18 dÃ©cembre 2014 05:31 > *Ã :* Any question about pharo is welcome > *Objet :* Re: [Pharo-users] [ANN] RProjectConnector V1.0 > > > > Hi Vincent, > > Hi, > > > > 2014-12-17 6:02 GMT-03:00 Blondeau Vincent <vincent.blondeau(a)worldline.com > >: > > Hernan, > > To detect the R installation path is complicated. > > > > Yes, I am currently working in a NBWin32Registry so we can do: > > (NBWin32Registry hKeyLocalMachine at: 'Software\R-core\R') values > > > > the reason I didn't committed a solution is I am having > ERROR_INVALID_FUNCTION with RegEnumValueA > > apiRegEnumValue: hKey with: dwIndex with: lpValueName with: lpcchValueName > with: lpReserved with: lpType with: lpData with: lpcbData > " > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724865%28v=vs.85%… > " > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( > long RegEnumValueA( > HKEY hKey, > DWORD dwIndex, > LPTSTR lpValueName, > LPDWORD lpcchValueName, > LPDWORD lpReserved, > LPDWORD lpType, > LPBYTE lpData, > LPDWORD lpcbData)) module: 'advapi32.dll' > > > > Where is the Windows registry access project? > > > I have just uploaded to http://smalltalkhub.com/#!/~OS/OS-Windows Package is OS-Windows-Registry, and main class renamed to WinRegistry. > > > I think that to set the libraries available to download on a server is > currently a better idea. Do you know where it can be hosted? > > > > > An option to upload library files could be http://files.pharo.org/ but I > don't have access to. > > Foy my configurations I am currently using DropBox although not charming > it serves well. > But AFAIK you cannot link multiple accounts to one DropBox. > > There are other reliable options? > > http://files.pharo.org/ seems to be a good solution. > > Vincent > > > > HernÃ¡n > > > > > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Dec. 20, 2014

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

by Johan Fabry

> 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

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

by Johan Fabry

> On Dec 19, 2014, at 21:14, kilon alios <kilon.alios(a)gmail.com> wrote: > > "Lines 4 to 11 are not necessary. Just remove them" > > thats great it removed one big thing that annoyed me. Why is this not necessary ? Itâs essentially the old way of doing what the following lines of code in your method do. > "Lines 20 to 26 introduce 7 methods that are not needed, you could include this in initializeWidgets itself. So we go from 36 to 29 methods at instance side." > > why would I want to do that ? it will increase the method by 20 lines of code and would look much meshier . I am not in a desperate need to decrease the amount of methods so I can make other methods bigger and messier. > > "Lines 7 through 12 introduce 6 methods that are not needed, you could include this in initialize itself. So we go from 29 to 23 methods at instance side." > > again I will pass, I rather brake down things down to small method than having one long method. > > "10 methods for a UI class is not so bad, is it?" > > I will say its worse because what we have now is a code that is as verbose with less method but now harder to read as well because of very big methods for Smalltalk standards. OK but then you should not complain about the fact that you have too many methods in your code. I gave you these suggestions because that seemed to be the main issue you were having. > One thing that interests me is , can avoid having to return the model by separate methods and instead pass them to a dictionary/list/array and return from only one method ? If yes that would be the turning point for me towards Spec. Iâm sorry but I do not understand your question. I would need a code example to better understand what you want. ---> 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

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

Dec. 20, 2014

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

by Johan Fabry

Answers inline again > On Dec 19, 2014, at 20:33, kilon alios <kilon.alios(a)gmail.com> wrote: > > "Spec is all about *composing* models. > If you want a GUI with many UI elements and try to build this with > a single model, spec won't be much help." > > whats a model ? > > whats a composing model ? To quote two parts of the Spec documentation: "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.â [â¦] > "spec is designed to provide *reusable* models." > > dont understand what that means since I dont understand model and documentation does explain it clearly. Please tell me what is not clear about the above text (ideally in the context of that part of the documentation). I have included a markdown file of the complete documentation just in case. It is crucial to me that it is understandable. > "Take a look at DynamicComposableModel (the examples in pharo or the examples posted on this list), for a simple GUI you only need some few lines of code." > > yes that is more to what I like but I was trying to do thing the "default" way of Spec. > > "That's not unusual. 90% spec means "not 90% morphic" > > no what I meant is that 90% is what Spec requires and 10% what is actually would make sense to me that Spec should require. >From the code I reviewed (quickly) I do not agree that you are doing things 100% in the âdefaultâ way of Spec. For example the following is not standard: the double instantiation of models in initializeWidgets and the splitting up in many small methods in initializeWidgets and in initialize. [â¦] > I want to use Morphic and extend it where it does not fit my style or my needs. Sure, I have no problem with that. I just want Spec to be as clear and usable as possible. If itâs not your style, no problem. > Just a side note, what I did with Spec is follow its documentation and its examples, its not as if I made all this up out of my head. 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. > We can also debate what is "constructive criticism" but it wont be a long pointless debate since its a very vague definition anyway. I know however one thing in life, that complain is way more valuable than applauding, though less desirable. In this case, I explicitly asked for comments so Iâm OK with all your feedback. ---> 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

"Lines 4 to 11 are not necessary. Just remove them" thats great it removed one big thing that annoyed me. Why is this not necessary ? "Lines 20 to 26 introduce 7 methods that are not needed, you could include this in initializeWidgets itself. So we go from 36 to 29 methods at instance side." why would I want to do that ? it will increase the method by 20 lines of code and would look much meshier . I am not in a desperate need to decrease the amount of methods so I can make other methods bigger and messier. "Lines 7 through 12 introduce 6 methods that are not needed, you could include this in initialize itself. So we go from 29 to 23 methods at instance side." again I will pass, I rather brake down things down to small method than having one long method. "10 methods for a UI class is not so bad, is it?" I will say its worse because what we have now is a code that is as verbose with less method but now harder to read as well because of very big methods for Smalltalk standards. One thing that interests me is , can avoid having to return the model by separate methods and instead pass them to a dictionary/list/array and return from only one method ? If yes that would be the turning point for me towards Spec.

Dec. 20, 2014

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

by Johan Fabry

A quick review of your code, just looking at what is on gitHub: At class side, the layout method looks really good ( https://github.com/kilon/Nireas/blob/master/Nireas.package/Nireas.class/cla… ) I think it is hard to get something cleaner than that in any textual UI framework. initializeWidgets ( https://github.com/kilon/Nireas/blob/master/Nireas.package/Nireas.class/ins… ) Lines 4 to 11 are not necessary. Just remove them Lines 20 to 26 introduce 7 methods that are not needed, you could include this in initializeWidgets itself. So we go from 36 to 29 methods at instance side. initialize ( https://github.com/kilon/Nireas/blob/master/Nireas.package/Nireas.class/ins… ) Lines 7 through 12 introduce 6 methods that are not needed, you could include this in initialize itself. So we go from 29 to 23 methods at instance side. A quick look at the method counts 13 accessors. In my book, accessors donât count. So we go from 23 to 10 methods at instance side. 10 methods for a UI class is not so bad, is it? > On Dec 19, 2014, at 20:18, kilon alios <kilon.alios(a)gmail.com> wrote: > > 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. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Dec. 19, 2014

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

by kilon alios

"Spec is all about *composing* models. If you want a GUI with many UI elements and try to build this with a single model, spec won't be much help." whats a model ? whats a composing model ? "Not both are needed, either you call newXmodel for every model or you call instantatieModels with an array of "instanceVars and Models"" no idea what newXmodel is "spec is designed to provide *reusable* models." dont understand what that means since I dont understand model and documentation does explain it clearly. "Take a look at DynamicComposableModel (the examples in pharo or the examples posted on this list), for a simple GUI you only need some few lines of code." yes that is more to what I like but I was trying to do thing the "default" way of Spec. "That's not unusual. 90% spec means "not 90% morphic" no what I meant is that 90% is what Spec requires and 10% what is actually would make sense to me that Spec should require. "If you have 100 buttons in one GUI without the possiblity to divide it in small reusable parts, then spec may be your smallest problem." divinding something to smaller parts you dont make it simpler or less verbose you make it more manageable. "The two years I am working with pharo and reading this list, I have read more complains than constructive critics (about morphic and spec). We have the following options: - complain - constructive critics - contribute - develop a new framework (develop *active*)" My choice is pretty much final on "neither" . I want to use Morphic and extend it where it does not fit my style or my needs. Just a side note, what I did with Spec is follow its documentation and its examples, its not as if I made all this up out of my head. On the matter of complaining , you may want to think that coding is about gettting a job done but I can assure you this definetly NOT how I see coding. For me coding is for fun and anything that kills my fun I pay it back by not using it. At some point obviously we have to be practical about how we get things done but anyone who believes that what motivates coding in general is practical application and not personal emotions is a person about to be severely surprised. We can also debate what is "constructive criticism" but it wont be a long pointless debate since its a very vague definition anyway. I know however one thing in life, that complain is way more valuable than applauding, though less desirable.

Dec. 19, 2014

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

by kilon alios

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. 19, 2014