" Then I guess it grew rapidly and radically out of control and became this monstrosity "

Where are the people running screaming , where are the superheroes to save the day ? Think about it, if Morphic was really ugly that started as something beautiful then someone would have rebooted Morphic by now and started something from scratch and replaced Morphic by now. I have been very closely following pharo lists for a couple of years now and I have not seen so many people complain about Morphic. Sure Morphic has its own messes to deal with but please find me a library of the size of Morphic that is not messy in some areas. You think that QT , GTK , Winforms etc are not heavily criticized ? Think again. GUI APIs are big ugly and prone to confusion and bad designs. The problem with modern GUI APIs are that the demands for them are super complex. Looks at web browser which are now the forefront of GUI design is a ton of mess because the demands are really that complex . Take a look at 3d applications, 2d app, audio apps and music apps and you will find that many of them use their own GUI APIs. Why people tolerate these big messy GUIs APIs , why they tolerate the ugliness of html/css ? The answer Is simple . because they offer what they need . Same applies with Morphic, its big and complex because we need it to be big and complex. Could the design being improved ? sure and Morphic is constantly improving , I make my own contribution as well because its an area that heavily interests me. But make no mistake about it, you will never have a shoe that fits all. For me its much better to have several tools and libraries that help us deal with the complexity of Morphic than simplifying Morphic by removing useful features in sake of simplifying. If you want to see what real monstrosity looks like take a look at MFC, its the only library of any kind that I know that desperately needs an exorcism. "Following the Spec tutorial (which is excellent, by the way!)" See this is where we get in the area of personal preference, I find Spec very ugly. I mean really , really ugly. I used it to develop my theme manager Nireas and I definetly dont like its workflow and now I am seriously looking into porting Nireas back to Morphic and developing my own library to fix Morphic shortcomings. However this is what is amazing about Pharo we live in a time that because of the active development and contribution you have many choices and you can choose the one that fits you better or the one you like the most. For the example even though I dont like html/css as you may have guessed by now, I would love to have webkit or some other web browser engine embeded inside the pharo image and so being able to display websites from inside pharo. None can question the incredible value of diversity of options. "I have also heard that Morphic made more sense in its original habitat in Self, because you really could just clone a UI component and start customizing it, because Self only has instances, no classes." I think prototype based programming is great because offers to the developer more power in more elegant way than classes. I think you will find few people not agreeing on this, even one of the creators of Smalltalk , Ingalls, said something along the lines that if he had to redesign Smalltalk would have made it prototype based. But and thats a big but in practice I seriously question the usefulness of prototype based programming. Take a look at Pharo its class based but still easy to hack , right ? Yet people are reluctant to hack and for a good reason. Because you have to deal with merge hell , people hacking the same thing as you or you do something and system misbehaves because you hacked an object that another object depended on. So classes for me are there to provide a more concrete implementation and area that is labeled "modify with extreme care" . Afterall its not that hard to take a Morph class subclass it and create your own class instead of changing that Morph class directly. But as I said I agree that prototype based programming is more elegant but in the end it does not matter as much as you think it does, because if it did then Prototype based would be dominant by now. So to summarize , no Morphic fits Pharo like a glove. "Spec seems to be promising non-Morphic backends, is that an active development interest and if so what targets are being explored?" Spec is a wrapper meaning knowing spec does not require to know Morphic and that means also it can exist without Morphic, not currently, but probably one day. PolyMorph is an extension of Morphic meaning you have to know Morphic and depends on it. So they are two very fundamentally different things. I think however this is a moot point. The bottom line is that GUI development is an extremely important part of Pharo and any other programming language. If you can bet on anything is that GUI APIs of any kind will keep evolving , so yes Morphic will keep improving, Spec will keep improving and we will see new kids in the block like we already see with Bloc and Brick, Some of them will be small and elegant solutions but limited, other will be big and complex but powerful. But hey who can predict the future ?

Well Spec from what I understand requires a model for each thing you add to it which makes classes bigger and unecessary complex. 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. Generally speaking Spec is a library that I find very hard to figure out from example and reading the code compared to Morphic. 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. 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. 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. 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. 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. 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. On Fri, Dec 19, 2014 at 5:50 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:

...

On Dec 19, 2014, at 07:44, kilon alios <kilon.alios@gmail.com> wrote:

See this is where we get in the area of personal preference, I find Spec very ugly. I mean really , really ugly. I used it to develop my theme manager Nireas and I definetly dont like its workflow and now I am seriously looking into porting Nireas back to Morphic and developing my own library to fix Morphic shortcomings.

I ask this to understand the problem: can you tell me what you find really ugly about Spec, why you don’t like its workflow, and why Morphic does it better in your opinion?

TIA

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

if I can say it, I think Spec has several design flaws, that prevent us to actually use it productively. 1st: I believe Spec is 80% of what Morphic should do by it self, but since is now that monster no body wants to take by the horns, Spec provides a layer. 2nd: The original idea of Spec is to produce composable objects that can be some-kind described and then reused by plugging them, but - is an idea that has a lot of sense is we have a UI builder… which we dont. 2 - 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) 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 :) So, to summarise, IMHO: - Spec wouldn’t have much sense in a well-defined, clean, Morphic - Even as a layer, Spec still does not has much sense without: -- a rebuild of the descriptive model -- an UI builder to use it. cheers, Esteban

On 19 Dec 2014, at 17:32, nacho <0800nacho@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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Le 19/12/14 17:53, nacho a écrit :

Esteban, I agree 100%. In fact that was, in part, the reason of my question. As I don't see a Spec UI coming soon I was wondering if perhaps Morphic will be trimmed in Pharo 4. No Now have a look at Bloc in AlainPlantec/Bloc

Thanks Cheers Nacho

----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796452.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Look for AlainPlantec/Bloc on smalltalk hub. Le 23/12/14 14:34, nacho a écrit :

...

No Now have a look at Bloc in AlainPlantec/Bloc Thanks Stef, Where I can find about Bloc?? I want to take a look at it! cheers

----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796781.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

if I can say it, I think Spec has several design flaws, that prevent us to actually use it productively.

1st: I believe Spec is 80% of what Morphic should do by it self, but since is now that monster no body wants to take by the horns, Spec provides a layer. 2nd: The original idea of Spec is to produce composable objects that can be some-kind described and then reused by plugging them, but - is an idea that has a lot of sense is we have a UI builder… which we dont. 2 - 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) 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 :)

So, to summarise, IMHO:

- Spec wouldn’t have much sense in a well-defined, clean, Morphic Not really we need a way to express and reuse logic. This is what we saw with alain so we will valueholder and may be spec to compose widgets but we will see. - Even as a layer, Spec still does not has much sense without: -- a rebuild of the descriptive model -- shrinking of the api -- cleaning of announcement mess -- an UI builder to use it.

yes

cheers, Esteban

...

On 19 Dec 2014, at 17:32, nacho <0800nacho@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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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@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

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@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

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

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

"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@dcc.uchile.cl> wrote:

...

On Dec 19, 2014, at 21:54, kilon alios <kilon.alios@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

On 20 Dec 2014, at 13:44, Sean P. DeNigris <sean@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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Le 20/12/14 13:44, Sean P. DeNigris a écrit :

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 This is not the case from my experience fighting with morphic.

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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

stepharo wrote

...

...

Morphic = make and understand any UI This is not the case from my experience fighting with morphic. Agreed, of course ;) We were talking about intention, not implementation.

:) but I live in reality not dreams :)

In what little experience I have, I think that statement would be true full stop for Self's Morphic.

----- Cheers, Sean -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796783.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

ok thank you for taking it the time explaining things. I will figure this out myself. On Sat, Dec 20, 2014 at 3:46 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:

This is my last mail to the thread as we are going around in circles.

...

"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

And you also said that you had a class with 36 methods and you were clearly upset about it. There were three exclamation marks.

...

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.

These methods are called accessors. Please use the conventional terminology so that we can better understand each other. You were talking about the names of the spec elements before and that was very confusing (and you never cleared it up).

As I said in a previous mail, you don’t write accessors by hand, you generate them. Try in Nautilus: click on a class name, right click for the menu, Refactoring->Class Refactoring->Generate accesors. Or cmd-h-a. It will propose a list of accessors to generate for you.

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

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/clas... ) 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/inst... ) 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/inst... ) 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@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@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

On Dec 19, 2014, at 21:14, kilon alios <kilon.alios@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

no I am sorry but I cannot understand it, looks like I am too stupid for Spec . Its ok though thats my fault , thank you all for trying to help me understand. Unfortunately the whole design of Spec looks extremely hard to me. On Sat, Dec 20, 2014 at 3:48 PM, Nicolai Hess <nicolaihess@web.de> wrote:

This is how I would do it. (see attachement) What do you say? Is it clearer now what I meant with compose and reusable models?

I am curios how would a pure morphic based solution look like.

As it is just a simple dialog, I think the pure morphic version would be similar (in code size) and of course, it can be build by small reusable parts as well.

2014-12-20 0:18 GMT+01:00 kilon alios <kilon.alios@gmail.com>:

...

yes you can find my code here

https://github.com/kilon/Nireas

On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <jfabry@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@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

On Dec 19, 2014, at 9:24 AM, kilon alios <kilon.alios@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

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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

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@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

Daniel Lyons wrote

My impression is that Morphic must have started out as a small and beautiful core. Otherwise you wouldn't find so many people talking about how amazing it was in writings dated 10 years ago and earlier

The idea is revolutionary and beautiful - that everything you see on the screen can be dealt with like a physical object in the real world; you would "pick up" a picture from a web page or "pick up" a menu item to anchor to the desktop as easily as you can pick up a file icon and drop it in another folder. It was originally implemented in Self, so "small and beautiful" buzz may have been from that setting. From what I understand, Squeak's Morphic was stuffed with experiments from very early on. Daniel Lyons wrote

I have also heard that Morphic made more sense in its original habitat in Self, because you really could just clone a UI component and start customizing it, because Self only has instances, no classes. The "direct manipulation" argument is slightly sabotaged by the intrusion of a class hierarchy and textual coding.

I have heard that a lot too, but don't think it's really true. If you define the state that makes a morph a morph, why can't you implement a way to save that current state to a subclass or update the current class? It's just that no one's implemented it yet, probably because few people remember the Dynabook and Morphic visions that make direct, live, uniform manipulation important, and the blue plane ideas have degenerated to pink plane "how do we easily make business UIs; not that that's not an important goal, too, but I would hate to forget the revolutionary power we have underneath! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796438.ht... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.