Smalltalk › Pharo › Pharo Smalltalk Users

Question about Morphic in Pharo 4

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

50 messages Options

123

jfabry

Re: Question about Morphic in Pharo 4

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 <[hidden email]> 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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

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 <[hidden email]> 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

Sean P. DeNigris

Re: Question about Morphic in Pharo 4

Administrator

In reply to this post by jfabry

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

Nicolai Hess

Re: Question about Morphic in Pharo 4

In reply to this post 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.

2014-12-19 20:54 GMT+01:00 kilon alios <[hidden email]>:

"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

kilon.alios

Re: Question about Morphic in Pharo 4

In reply to this post by Daniel Lyons

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 <[hidden email]> wrote:

On Dec 19, 2014, at 9:24 AM, kilon alios <[hidden email]> 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

kilon.alios

Re: Question about Morphic in Pharo 4

In reply to this post by jfabry

yes you can find my code here

https://github.com/kilon/Nireas

On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <[hidden email]> 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 <[hidden email]> 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

kilon.alios

Re: Question about Morphic in Pharo 4

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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

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/class/defaultSpec.st ) 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/instance/initializeWidgets.st )
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/instance/initialize.st )
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 <[hidden email]> wrote:
>
> yes you can find my code here
>
> https://github.com/kilon/Nireas
>
>
>
> On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <[hidden email]> 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

kilon.alios

Re: Question about Morphic in Pharo 4

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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

Answers inline again

> On Dec 19, 2014, at 20:33, kilon alios <[hidden email]> 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

Spec.pier.md (61K) Download Attachment

kilon.alios

Re: Question about Morphic in Pharo 4

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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

> On Dec 19, 2014, at 21:14, kilon alios <[hidden email]> 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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

> On Dec 19, 2014, at 21:54, kilon alios <[hidden email]> 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

kilon.alios

Re: Question about Morphic in Pharo 4

"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 <[hidden email]> wrote:

> On Dec 19, 2014, at 21:54, kilon alios <[hidden email]> 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

Sean P. DeNigris

Re: Question about Morphic in Pharo 4

Administrator

kilon.alios wrote

even if continue to use Spec I will stiil have to rely on Morphic
since custom GUIs is really important for me.

Yes, that's why they can not be compared:
Morphic = make and understand any UI
Spec = make common business UIs easily (on top of a general framework like Morphic)

Cheers,
Sean

EstebanLM

Re: Question about Morphic in Pharo 4

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

jfabry

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

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

Nicolai Hess

Re: Question about Morphic in Pharo 4

In reply to this post by kilon.alios

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 <[hidden email]>:

yes you can find my code here

https://github.com/kilon/Nireas

On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <[hidden email]> 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 <[hidden email]> 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

theme_editor.cs (10K) Download Attachment

kilon.alios

Re: Question about Morphic in Pharo 4

In reply to this post by jfabry

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 <[hidden email]> 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

kilon.alios

Re: Question about Morphic in Pharo 4

In reply to this post by Nicolai Hess

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 <[hidden email]> 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 <[hidden email]>:
yes you can find my code here

https://github.com/kilon/Nireas

On Sat, Dec 20, 2014 at 12:17 AM, Johan Fabry <[hidden email]> 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 <[hidden email]> 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

123