Question about Morphic in Pharo 4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
50 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Question about Morphic in Pharo 4

nacho
Hi folks,
I'm doing some project in Morphic in Pharo 3. I was wondering if big changes are expected in Moprhic in Pharo 4 or if it will remain relatively unchanged.
Thanks in advance.
Nacho
Nacho Smalltalker apprentice. Buenos Aires, Argentina.
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

kilon.alios
No the improvements are gradual and try to clean up some of the design of Morphic but as you can imagine backward compatibility has to be retained because there is loads of Pharo tools, apps , code and libraries that rely on Morphic and Morphic's design. Even if Morphic is replaced at some point it will be a very gradual process and still some compatibility will be retained to keep things familiar for experience pharo coders. 

Most of all Morphic is by far the biggest and most complex pharo library so producing a replacement it wont be a walk in the park. So yes you can rely on the fact that things will stay not exactly the same but pretty similar for a very very long time. If I had to say an estimate I would say at least 10 years down the road. 

On Thu, Dec 18, 2014 at 4:28 PM, nacho <[hidden email]> wrote:
Hi folks,
I'm doing some project in Morphic in Pharo 3. I was wondering if big changes
are expected in Moprhic in Pharo 4 or if it will remain relatively
unchanged.
Thanks in advance.
Nacho




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

Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

stepharo
In reply to this post by nacho
Hi

You never know but in general we pay attention not to break for the
shake of it.
Then Morphic is several things
     - low level
     - widgets
     - polymorph
So this is difficult to be fully affirmative. What I can say is that we
did not change much.
stef
Le 18/12/14 15:28, nacho a écrit :

> Hi folks,
> I'm doing some project in Morphic in Pharo 3. I was wondering if big changes
> are expected in Moprhic in Pharo 4 or if it will remain relatively
> unchanged.
> Thanks in advance.
> Nacho
>
>
>
>
> -----
> Nacho
> Smalltalker apprentice.
> Buenos Aires, Argentina.
> --
> View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

Daniel Lyons

> On Dec 18, 2014, at 3:31 PM, stepharo <[hidden email]> wrote:
>
> Hi
>
> You never know but in general we pay attention not to break for the shake of it.
> Then Morphic is several things
>    - low level
>    - widgets
>    - polymorph
> So this is difficult to be fully affirmative. What I can say is that we did not change much.

Not the OP, but I've been confused about the history and future plan for some time. 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. It must have been much faster and easier to work with than the earlier MVC. Then I guess it grew rapidly and radically out of control and became this monstrosity sitting in the Squeak image, which has been pared down significantly in the Pharo image but is still basically huge. Squeak mostly evolved by shared changes to the image, so there was no concept of separate packages adding this or that method to this system class, so everything eventually wound up depending on everything. As our infrastructure is inherited, we inherit this problem, even as we go about breaking everything down and simplifying it, there is a long way to go to get back to the original small and beautiful core—and that may not even really be a goal for Pharo and Morphic. Is this fair and accurate?

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'm just regurgitating a wisp of a memory though, I don't know if anybody who used it a lot would agree or not. (I'm not sure how one is able to make comprehensive principled changes in such a system, but that's an unnecessary diversion.) It seems to me that as Morphic halos get harder to get access to, direct manipulation becomes harder to effect; on the other hand, halos are probably a lot more confusing to beginners than helpful to anyone. Comments?

From there I'm not quite sure what Polymorph is and what its development status/future outlook are like. Is it actively developed and are we happy with people building new stuff with it? Seems like it was the preferred UI paradigm a few years ago but now we have Spec. Spec seems to be promising non-Morphic backends, is that an active development interest and if so what targets are being explored? Historically, Morphic itself seems to promise multiple backends (the comment on Canvas says "A canvas is a two-dimensional medium on which morphs are drawn in a device-independent manner"), did that ever come to fruition, or did they just mean it supported different kinds of monitors?

In the old books I see a lot of mentions of things like "pluggable" widgets, and in the image I see things like PluggableTextMorph. Following the Spec tutorial (which is excellent, by the way!), it feels like I have a lot of manual copying around of data in whenTextChanged: handlers. In fact, the old books also talk about the changed/changed:/changed:with: observer system, which I see is still in the image but it's not clear to me if any of these systems make use of that or if this whole system is considered deprecated. My suspicion is that it is deprecated because there is NewValueHolder. Is it?

I'm mostly asking for history as I try to get my bearings and not trying to deprecate anyone or anything, so if anything in the above is offensive, it is an accident, please correct me.

Thanks,


Daniel Lyons




Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

kilon.alios
 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 ? 
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

Sean P. DeNigris
Administrator
In reply to this post by Daniel Lyons
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

jfabry
In reply to this post by kilon.alios

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


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

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

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



Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

nacho
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.
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

EstebanLM
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 <[hidden email]> 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.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

nacho
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.
Thanks
Cheers
Nacho
Nacho Smalltalker apprentice. Buenos Aires, Argentina.
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

Sean P. DeNigris
Administrator
In reply to this post by jfabry
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

jfabry
In reply to this post by kilon.alios

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


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

jfabry
In reply to this post by nacho

Just to be clear: Morphic in Self was very graphical with much emphasis on direct manipulation (IIRC) Would a graphical UI builder solve your problems for you?

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



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

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


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

jfabry
In reply to this post by EstebanLM
Thanks for the clear description. I have just 2 things I would like to clarify:

> On Dec 19, 2014, at 13:55, Esteban Lorenzano <[hidden email]> wrote:
>
> - the metadata itself is not very well defined (I would like something like the ones in VW and StX, but is like a weird array right now), because of this, Spec has created some “in the middle” way to define specs in a more “declarative way”, breaking the original design (the one I just pointed)

This is the part of Spec that I like the least. But I do not see a nicer way to do it than this “declarative way” you mention. It is however a complex problem and I welcome any suggestions on how to better address it!

> 3rd: Frankly, with this “more declarative way” spec adopted more or less the same path glamour took. But if this is the point, glamour does a really better work on the “declarative” part. Of course, it does that at the cost of being less reusable, but well… we are talking about Spec, not Glaour here :)

Yes, that is the typical tradeoff of a domain-specific solution versus a general-purpose solution. Because Glamour is more restricted it can solve this difficult problem in a cleaner way. But if you want to do things that fall outside of the Glamour way of doing things you are in trouble (or even deep trouble. I have experienced that).

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

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


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

jfabry
In reply to this post by Sean P. DeNigris
I understand that you find it ugly but, for me, your comments are about implementation issues that as a user of the framework you should not really come in contact much.

So I have a question. Does this bother you from user point of view, or from the point of view of somebody that wants to make changes to the framework (and why?).

> On Dec 19, 2014, at 15:14, Sean P. DeNigris <[hidden email]> wrote:
>
> jfabry wrote
>> can you tell me what you find really ugly about Spec
>
> Two main things:
> - Giant nested arrays of literals instead of objects
> - deeply nested model e.g.
>  1. DropListExample new openWithSpec
>  2. Explore window through halos
>  3. self model model model "really, 3 levels?
> SpecWindow->MorphicWindowAdapter->WindowModel->NewValueHolder. There is
> something fishy here"
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Question-about-Morphic-in-Pharo-4-tp4796331p4796457.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>



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

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


Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

Sean P. DeNigris
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

kilon.alios
In reply to this post by jfabry
"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 ??
Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

philippeback
In reply to this post by Sean P. DeNigris


Le 19 déc. 2014 20:16, "Sean P. DeNigris" <[hidden email]> a écrit :
>
> jfabry wrote
> > as a user of the framework you should not really come in contact much.
>
> Well the API is not bad (although it can seem a little heavy-weight when
> spiking to create a class, implement #defaultSpec, #initializeWidgets,
> #initializePresenter, etc). But as we know Smalltalk blurs the distinction
> between user and developer, and it's hard not to come in contact with the
> ugliness. When something doesn't work as expected, or when drilling down to
> see how existing tools work for inspiration, I've felt the internals as
> serious barriers to understanding.
>
> As I understood it, Spec was supposed to be a framework agnostic facade so
> one could describe once and e.g. deploy to both a js web UI and a Morphic
> desktop UI, so it's meaningless to compare Morphic to Spec.
>
> What could be cool is, if we agree that the Spec Model API is pretty cool
> (IMHO TextModel is much easier to work with than PluggableTextMorph to make
> e.g. a method editor with highlighting and completion), then to reimplement
> the Morphic widgets to use that API. Either way, since we control Spec and
> Morphic, it seems that we should agree on a satisfying API and use the same
> for both.
>
> I feel like that was a bit rambling so let me know if that didn't answer the
> question.
>

Morphic has the base elements right:

* Events from Sensor
* Morphs and gui loop
* Stepping
* Halos
* Layouts

For the other level, widgets the story is that Polymorph widgets is the most complete thing we have. Not perfect but the best we have in stock.

Layouts aren't the best in the world either. But are workable.

What we need is a set of nice base widgets. And themable ones at that.

Spec is using the widgets and tries to adapt them. The declarative array is not the best but works. Of course the concept is not that explorable.  For a quick Ui it is OK.  For larger stuff I am not sure.

Glamour is to build browser style things.

Now the text edition widget is age old and TxText is moving forward. As an interim measure we do have Rubric which is cool but has been stopped by Alain.

That's confusing at best.

Bloc is a new kid around.

At one point we need to come to terms with what we really need as a solid open source Smalltalk enabling business.

We need a polar star as a reference.

And the lack of current doc about Morphic is not helping.

Phil

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

Reply | Threaded
Open this post in threaded view
|

Re: Question about Morphic in Pharo 4

Daniel Lyons
In reply to this post by kilon.alios

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



123