December 2014 - Pharo-users

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

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