December 2014 - Pharo-users

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

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

by Johan Fabry

Thanks for the clear description. I have just 2 things I would like to clarify: > On Dec 19, 2014, at 13:55, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > - the metadata itself is not very well defined (I would like something like the ones in VW and StX, but is like a weird array right now), because of this, Spec has created some âin the middleâ way to define specs in a more âdeclarative wayâ, breaking the original design (the one I just pointed) This is the part of Spec that I like the least. But I do not see a nicer way to do it than this âdeclarative wayâ you mention. It is however a complex problem and I welcome any suggestions on how to better address it! > 3rd: Frankly, with this âmore declarative wayâ spec adopted more or less the same path glamour took. But if this is the point, glamour does a really better work on the âdeclarativeâ part. Of course, it does that at the cost of being less reusable, but wellâ¦ we are talking about Spec, not Glaour here :) Yes, that is the typical tradeoff of a domain-specific solution versus a general-purpose solution. Because Glamour is more restricted it can solve this difficult problem in a cleaner way. But if you want to do things that fall outside of the Glamour way of doing things you are in trouble (or even deep trouble. I have experienced that). ---> 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 Johan Fabry

Just to be clear: Morphic in Self was very graphical with much emphasis on direct manipulation (IIRC) Would a graphical UI builder solve your problems for you? > On Dec 19, 2014, at 13:32, nacho <0800nacho(a)gmail.com> wrote: > > I too prefer Morphic over Spec. I find Spec too much verbose. And in fact, > Morphic as presented in the Self language it's a much modern approach to > building UIs than Spec which is pure code. So as complicated as it might > have become, I'm still attached to Morphic. > > > > > ----- > Nacho > Smalltalker apprentice. > Buenos Aires, Argentina. > -- > View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796449.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

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

by Johan Fabry

I have some comments and questions inline. Again to clarify: I want to understand what people are thinking about Spec so I appreciate your feedback and I want to keep on asking until I think I really understand. > On Dec 19, 2014, at 13:24, kilon alios <kilon.alios(a)gmail.com> wrote: > > Well Spec from what I understand requires a model for each thing you add to it which makes classes bigger and unecessary complex. The models are the classes of the user interface. Each thing you add is a widget (more or less), and called a model. I do not understand how this differs from Morphic in that if you want to add e.g. a button you need to add the button morph. Can you help me understand? > I also dont like the name defaultSpec which for me mean nothing and creates confusion. Other classes I see use name defaultSpec2 which makes even less sense. OK the name could be better chosen. BTW, you donât need to call it like this, you can just use a pragma instead. This is why some methods are called defaultSpec2 (also a bad name) > Generally speaking Spec is a library that I find very hard to figure out from example and reading the code compared to Morphic. Yes, it is absolutely not designed to be learned by example. I agree with that. If you want to learn by example you should follow the examples in the doc, not browse the code. I understand that not everbody is OK with that. > Also a shortcoming of spec is that is not designed to be custom gui friendly from what I see since it seems to just wrap morphs if you want custom element guis. 100% agree. This is not the focus of Spec. > Also I dont understand why we need initialise and instiate , looks to me like Spec requires too many definitions to add stuff together which is an area that Morphic excel AFAIK where in example of Morphic all you have to do is addMorph: in Spec it appears to me there so many steps. > > If I want to add a button then I should using a single line of code. I donât understand. As you said before, GUI stuff is complex. So I donât see how you can do everything in 1 line of code. For example, how can I add an âOKâ button to a window, in a specific location, with a specific action to be taken in 1 simple line? How can I do that in Morphic? > Generally speaking my Nireas class is an extremely simple GUI that is uneccessary complex. Sure I could brake the GUI to smaller Spec widgets but for me that makes no sense for such a small GUI. I cant see with all this overhead how Spec would be useful for me for very complex guis I want to create in the long run when Morphic design is so clear to me. I think this is a matter of taste so I cannot really comment here except on that I respect that your taste is different from mine :-) > Another thing to note here is that I have read the Spec documentation again and again and it has been a seriously struggle to make sense of Spec because of this complex and weird design. Ok this is a serious problem for the documentation. I want everybody to understand it. So can you clarify why this is a struggle so that we can work on that? (We will be reworking the documentation again one of these days) > Morphic on the other hand has been a walk in the park for some guis I created with it because its design is so simple and elegant. I never read docs on Morphic , I just take a look at Morph examples and immediately understand how things work. Saying that I had issues understanding how treemorph worked and cant say I liked the code. OK taste again. > 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. I think I can safely bet that I have been playing with Lego for longer than you and that my collection is bigger :-) And I donât agree with your observation. The huge Lego creations are possible when you build smaller units that are than plugged together in well-thought out ways. The easy example are the new 1930-style buildings that you build floor by floor ... ---> 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 > 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.

Dec. 19, 2014

Re: [Pharo-users] Metacello does not load the expected version from ConfigOf

by Dale Henrichs

Usman, With classic Metacello (using the `(ConfigurationOfxxx project version: 'xxx') load` pattern) you can only downgrade via an explicit load of a particular version of the project. When loading projects indirectly via a project reference from another project Metacello is biased towards upgrade. With the Metacello Scripting API[1], you may include an #onDowngradeUseIncoming: clause to selectively permit downgrades: Metacello new configuration: 'DummyParser'; version: '1.0'; repository: '???'; onDowngradeUseIncoming: #('PetitParser'); load. For additional downgrade options see[2]. Since you are interested in using a specific version of a project you may also be interested in locking the project[3][4]. With a `lock` Metacello will not upgrade or downgrade the project but always `honor` the lock unless an #onLock: clause is used ... Note that for `locking` to work, you must use the Metacello Scripting API to do all of your project loads ... Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… [4] https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandR… On 12/19/2014 07:44 AM, Usman Bhatti wrote: > Hi all, > > I am trying to load a specific version of PetitParser in a Moose > image. A Moose image comes with the latest development version of > PetitParser. So, I am trying to downgrade to an older version. So, > when I load the version manually, older versions of the packages are > loaded: > (ConfigurationOfPetitParser project version: '1.51') load > > But when I try to load the same version within my ConfigOf the > expected packages are not loaded and list of the PetitParser packages > loaded remains unchanged. Here is how my baseline looks like: > > ConfigurationOfDummyParser>>baseline01: spec > <version: '0.1-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec project: 'PetitParser' with: [ > spec > className: #ConfigurationOfPetitParser; > versionString: '1.51'; > repository: 'http://smalltalkhub.com/mc/Moose/PetitParser/main/' ]. ]. > > I also tried creating a version but it didn't help. > > ConfigurationOfDummyParser>>version10: spec > <version: '1.0' imports: #('0.1-baseline' )> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec description: 'version 1.0'. > spec author: 'usmanbhatti'. > spec timestamp: '12/19/2014 16:35'. > spec project: 'PetitParser' with: '1.51'. ]. > > I also had a look at the package the configuration tries to load and > the list shows correct packages to be loaded (see screenshot). > > Does anyone have an idea what may be problematic in my code or that of > Metacello? I am attaching the code of my ConfigOf for a Moose image. > > Thanks in advance. > > UsmanInline image 1 > >

Dec. 19, 2014