December 2014 - Pharo-users

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

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

by kilon alios

I used legos to make my own creations , I was never interested in pre built solutions. I have not see the lego master builder series no , I have left lego as childhood memory actually I stopped playing with legos when I was introduced into coding at age 9 and coding has been my lego ever since. Documentation for Morphic exist in squeak wiki (there is plenty of it there) and in self documentation, its only Pharo that has Morphic undocumented. Well not entirely there is a chapter about it in PBE but I think thats ported from Squeak By Example. There also a lot of video tutorial on youtube for Morphic if I remember correctly. Frankly I dont completely understand what the target audience of Spec really is On Fri, Dec 19, 2014 at 11:43 PM, Daniel Lyons <fusion(a)storytotell.org> wrote: > > On Dec 19, 2014, at 9:24 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > > That also may have to do with how I work which is that I was raised with > legos so I love to assemble things together instead of abstracting them > away which I think is what Spec tries to do. So Morphic definitely fits my > way of thinking better. > > > My brother and I both played with Legos a lot as kids. We'd each get a big > set. I would follow the instructions and build the model on the box. Then > I'd play with it, and eventually get bored with it and it would go on the > shelf. My brother would get halfway through following the instructions and > get bored, start making his own stuff. Eventually the pieces would wind up > in the big bin under his bed, along with whatever bits and pieces he hadn't > taken apart yet. I always thought his stuff was terrible, didn't look as > cool as what was on the box. He always thought I was boring because I'd > just build the one or two things it would tell you how to make. > > Today, I am a professional Java web developer, with roots in Python, > Haskell and Prolog. My brother, on the other hand, is a writer, potter, > musician, and professional industrial hygienist but does not program at all. > > When you compare Smalltalk programmers to other developers, you get a lot > of people who taught themselves by messing around in the image > (autodidacts) and you have a lot of people who only know Smalltalk and > don't really use other languages. The autodidacts I think, tend to love > Morphic. But I'm not sure how many of them learned it in Pharo versus > Squeak. And I think most of you probably loved Legos and were a lot more > like my brother, building your own things to suit yourselves from your own > imagination. Part of the genius of Pharo, in my opinion, is that it is a > lot more welcoming to people like me. The downside, of course, is that you > have to deal with a lot more people like me. :) > > Have you seen the Lego Master Builder series? They realized there were a > lot of kids out there who would benefit from more documentation. Even > unimaginative parents like myself can benefit from them. I got Lego MBA #1 > and read the manual closely. It's obviously intended for a 10â12-year-old > but I benefited from it. > > Spec's documentation is a lot like the Lego MBA. You're not the target > audience, I am. I wish everything in the image were documented like that. I > think that was sort of the intention behind Pharo by Example, which I read > and got a lot out of. Spec's documentation being out there and > Polymorph/Morphic not having anything like it definitely sends a message > about Polymorph and Morphic though, which leads to questions like mine. > > â > Daniel Lyons > > > >

Dec. 19, 2014

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

by Nicolai Hess

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. 2014-12-19 20:54 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > > "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 > That's the distinction spec makes for composing models MyModel>>initialize "do whatever your model *implementation* needs MyModel>>initializeWidget "instantiate the (sub)models your model is build upon" MyModel>>initializePresenter "interconnect the internals of your (composed)model" > > 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 > Not both are needed, either you call newXmodel for every model or you call instantatieModels with an array of "instanceVars and Models" > > 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 > spec is designed to provide *reusable* models. > > 6) I have to define a method at the class side for positioning the button > . No idea why this goes to the class side > A model is defined by its structure and layout, if you want to use a different layout, you can subclass the model and define your own defaultSpec, or a pragma, or you call it explicitly #buildWithSpec: > > 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. > 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. > > 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 . > Can you show me the UI (screenshot/ or a drawing of it) you try to develop? I would love to see how I would construct the UI based on spec. > > 36 !!! > > By the way in case you wonder 90% of the code is just Spec. For me thats > plain unacceptable. > That's not unusual. 90% spec means "not 90% morphic" > > So what happens if I have a GUI with over 100 buttons do I need 300 > methods just for Spec ? Really ?? > 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. The existing API and implementation of spec is not well designed. Even though it is meant to be independent of the backend, the existing models and adapter pretty much resemble morphics (not well designed (or badly grown) ) api. Some parts of the exising models looks like: "hey look how easy it was to add this and that and ..." (Just look at the number of instVars and announcers and different whenXDo: methods) Both, spec and morphic are grown, and that is bad for most frameworks. Of course we can discuss this and try to fix bugs or cleanup the implementation - > bugtracker. 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*) choose wisely

Dec. 19, 2014

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

by Johan Fabry

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

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

by Sean P. DeNigris

jfabry wrote > with: #initializeWidgets versus #initializePresenter. The motivation for > that is to have small methods (you know, Smalltalk style â¦) and to have > clear responsibilities for each method (the first is for widgets, the > second for their interaction). I guess since my dream is composing and tweaking live visual objects, I would not be happy with /any/ API. That rationale seems good, and certainly the separation makes things less confusing for complex UIs. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796488.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 19, 2014

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

by Johan Fabry

Thanks Sean for your response, you may think its rambling but it gave me a good enough answer :-) Questions, motivated by your response, and apparently something that more people are uncomfortable with: #initializeWidgets versus #initializePresenter. The motivation for that is to have small methods (you know, Smalltalk style â¦) and to have clear responsibilities for each method (the first is for widgets, the second for their interaction). Is this motivation not clear ? Is it not convincing? Why? > On Dec 19, 2014, at 16:16, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Well the API is not bad (although it can seem a little heavy-weight when > spiking to create a class, implement #defaultSpec, #initializeWidgets, > #initializePresenter, etc). ---> 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