- Pharo-users - lists.pharo.org

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

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

by Daniel Lyons

> 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 phil＠highoctane.be

Le 19 dÃ©c. 2014 20:16, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > > jfabry wrote > > as a user of the framework you should not really come in contact much. > > 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). But as we know Smalltalk blurs the distinction > between user and developer, and it's hard not to come in contact with the > ugliness. When something doesn't work as expected, or when drilling down to > see how existing tools work for inspiration, I've felt the internals as > serious barriers to understanding. > > As I understood it, Spec was supposed to be a framework agnostic facade so > one could describe once and e.g. deploy to both a js web UI and a Morphic > desktop UI, so it's meaningless to compare Morphic to Spec. > > What could be cool is, if we agree that the Spec Model API is pretty cool > (IMHO TextModel is much easier to work with than PluggableTextMorph to make > e.g. a method editor with highlighting and completion), then to reimplement > the Morphic widgets to use that API. Either way, since we control Spec and > Morphic, it seems that we should agree on a satisfying API and use the same > for both. > > I feel like that was a bit rambling so let me know if that didn't answer the > question. > Morphic has the base elements right: * Events from Sensor * Morphs and gui loop * Stepping * Halos * Layouts For the other level, widgets the story is that Polymorph widgets is the most complete thing we have. Not perfect but the best we have in stock. Layouts aren't the best in the world either. But are workable. What we need is a set of nice base widgets. And themable ones at that. Spec is using the widgets and tries to adapt them. The declarative array is not the best but works. Of course the concept is not that explorable. For a quick Ui it is OK. For larger stuff I am not sure. Glamour is to build browser style things. Now the text edition widget is age old and TxText is moving forward. As an interim measure we do have Rubric which is cool but has been stopped by Alain. That's confusing at best. Bloc is a new kid around. At one point we need to come to terms with what we really need as a solid open source Smalltalk enabling business. We need a polar star as a reference. And the lack of current doc about Morphic is not helping. Phil > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796471.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 kilon alios

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

Dec. 19, 2014

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

by Sean P. DeNigris

jfabry wrote > as a user of the framework you should not really come in contact much. 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). But as we know Smalltalk blurs the distinction between user and developer, and it's hard not to come in contact with the ugliness. When something doesn't work as expected, or when drilling down to see how existing tools work for inspiration, I've felt the internals as serious barriers to understanding. As I understood it, Spec was supposed to be a framework agnostic facade so one could describe once and e.g. deploy to both a js web UI and a Morphic desktop UI, so it's meaningless to compare Morphic to Spec. What could be cool is, if we agree that the Spec Model API is pretty cool (IMHO TextModel is much easier to work with than PluggableTextMorph to make e.g. a method editor with highlighting and completion), then to reimplement the Morphic widgets to use that API. Either way, since we control Spec and Morphic, it seems that we should agree on a satisfying API and use the same for both. I feel like that was a bit rambling so let me know if that didn't answer the question. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796471.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

I understand that you find it ugly but, for me, your comments are about implementation issues that as a user of the framework you should not really come in contact much. So I have a question. Does this bother you from user point of view, or from the point of view of somebody that wants to make changes to the framework (and why?). > On Dec 19, 2014, at 15:14, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > jfabry wrote >> can you tell me what you find really ugly about Spec > > Two main things: > - Giant nested arrays of literals instead of objects > - deeply nested model e.g. > 1. DropListExample new openWithSpec > 2. Explore window through halos > 3. self model model model "really, 3 levels? > SpecWindow->MorphicWindowAdapter->WindowModel->NewValueHolder. There is > something fishy here" > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796457.h… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > ---> 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