[Pharo-project] Morphic
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? * what would it take (if possible) to get there from the current implementation? Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. Sean
Ironically, I am one of those "pushing" for native widgets. Ironic, because I do so not for the usual argument of speed (which I consider to be a fallacy in general), but because we need discipline. I think Morphs would be a wonderful thing inside a native MorphicWorldPresenter or some other entity in an MVP or similar framework based on native widgets and used for the main tool shells. People working on new UI concepts would create a "boring" tool shell with a world in it an knock themselves with Morphic. The text editors would be platform native so input focus, modality etc. would work as expected almost by default. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of DeNigris Sean [sean@clipperadams.com] Sent: Friday, September 17, 2010 1:29 PM To: The general-purpose Squeak developers list; pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Morphic I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? * what would it take (if possible) to get there from the current implementation? Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. Sean _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 9/17/2010 12:29 PM, DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. I don't know all the answers. But I do believe there is a tremendous amount of unsubstantiated claims about "native" UIs and there value or importance. First and foremost the biggest offenders of non-native UIs or rather look-and-feel for apps on almost any OS is the OS vendor themselves. Yet, there users seem to do fine.
Come on, is iTunes a native look-and-feel for an OS? Or Safari, two apps from the creator of oh so elegant and beautiful. I don't really think so. I don't even think they are particularly attractive or intuitive. Or Quicktime. Or Internet Explorer. Or Windows Media. etc... I really can't go into any further detail as I am not currently using a Mac and I use as little MS software as I possibly can on my Windows OS machine. How about old Visual Basic or Hypercard apps? How about AIM, Yahoo Messenger, or whatever current cool tool is out there. Are they following any of the mantras tossed around by the we want native crowd? Not really. How about educational software and games. Both very common with lots of use. People seem to manage fine. Do I think Squeak/Pharo have to have arrived at their best UI. No, not at all. But I definitely do not believe "native" is better. And "native" never automatically means intuitive. It may be or not depending on the app. And non-native does not mean un-intuitive and poor quality. I do think we can do better. I do like the idea of having multiple OS windows available to the app developer. But I don't like being dependent on anybody else to fix a bug or port their UI or widgets to the next great OS. Heck I'm ready for Pharo 2.x/3.x to become my next OS. :) Whatever we do. I believe it is very important for us to maintain our control over our destiny. For me, wx, qt or whatever just simply reduces us to the same playing field as Python, Ruby, etc. I really believe we can be better. It is one of the reasons I use Squeak/Pharo/Smalltalk. To me the more we can do in Smalltalk the better. I say that fully understanding outside requirements. I am currently in the process of building an application in Pharo which requires the use of a Windows COM dll. This is a business requirement. Unfortunately, that is something I can not do in Pharo right now. Yes I know one of you wizard may be able to do something with Alien, FFI, or whatever. But it is something not currently accessible to people who only use the Smalltalk side of things. It is very easy to do in Python, which is what I used to write an intermediate application which communicates between the COM dll and my Pharo app. So I do understand, certain real world use case requirements for interfacing outside elements. I just don't believe the UI is really one, especially when counter examples are so incredibly abundant and are some of the biggest apps in use anywhere and often written by the OS vendor. I am not an implementer of any of these things, only a user. But these are some things I observe. YMMV, IMHO, all the standard disclaimers. :) :) :) Jimmie
Jimmie Houchin-5 wrote:
I do like the idea of having multiple OS windows available to the app developer.
See Mars[1] Jimmie Houchin-5 wrote:
So I do understand, certain real world use case requirements for interfacing outside elements. I just don't believe the UI is really one, especially when counter examples are so incredibly abundant and are some of the biggest apps in use anywhere and often written by the OS vendor.
iOS? Esteban said at ESUG that you must have them to be accepted in the app store I think whether we individually care or agree with native widgets doesn't matter, and wastes valuable resources that could be put to improving Morphic ;-). There are people that want them and if we can provide things that people want, great. I personally won't use native widgets myself for the same reasons you mentioned, but I'm happy to have it as an option. [1] http://smallworks.com.ar/en/community/Mars -- View this message in context: http://forum.world.st/Morphic-tp2544184p2545949.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already. You'd really try Cuis. You'll find it much easier to understand and extend. Cheers, Juan Vuletich
Hi Juan My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great. Stef On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. Anyway the open source ecosystem Darwin alike evolution law will prevail. Hilaire Le 18/09/2010 10:09, Stéphane Ducasse a écrit :
Hi Juan
My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great.
Stef
On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you? IMHO the reason is having total control and that's the same reason why Pharo was created. Levente
Anyway the open source ecosystem Darwin alike evolution law will prevail.
Hilaire
Le 18/09/2010 10:09, Stéphane Ducasse a écrit :
Hi Juan
My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great.
Stef
On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Or was it to have *any* control? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 11:50 AM To: Pharo-project@lists.gforge.inria.fr Cc: Stéphane Ducasse Subject: Re: [Pharo-project] [squeak-dev] Morphic On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you? IMHO the reason is having total control and that's the same reason why Pharo was created. Levente
Anyway the open source ecosystem Darwin alike evolution law will prevail.
Hilaire
Le 18/09/2010 10:09, Stéphane Ducasse a écrit :
Hi Juan
My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great.
Stef
On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't. Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective. In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community. Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter. Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
Nice response summary Hillaire! Exactly how I feel... Regards, Gary ----- Original Message ----- From: "Hilaire Fernandes" <hilaire.fernandes@gmail.com> To: <pharo-project@lists.gforge.inria.fr> Sent: Monday, September 20, 2010 5:33 PM Subject: Re: [Pharo-project] [squeak-dev] Morphic Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't. Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective. In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community. Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter. Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :) I still develop for Pharo, but one of my concerns has been the short time between releases. It means there is not much time for a stable, proven Pharo foundation to form before it is abandoned already. Combined with the Pharo philosophy about backward compatibility, I am quite nervous that Magma is going to get "stuck" in some "old" (what, 3 months?!) version of Pharo that never had much time to gestate in the first place.. - Chris PS - Congratulations on your latest Dr. Geo. 2010/9/20 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine  are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 20 September 2010 22:45, Chris Muller <asqueaker@gmail.com> wrote:
Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... Â :) I still develop for Pharo, but one of my concerns has been the short time between releases. Â It means there is not much time for a stable, proven Pharo foundation to form before it is abandoned already.
Combined with the Pharo philosophy about backward compatibility, I am quite nervous that Magma is going to get "stuck" in some "old" (what, 3 months?!) version of Pharo that never had much time to gestate in the first place..
Fear not, Chris. Magma were always on my radar since i first seen it. And i seen many other people mentioned Magma. And i understand, that many Pharoers use it or want to use it in future, so there is no chance that such important project will be left behind unattended. It may be slower than other solutions, but with release of Cog, i think, it is now time to kick some ass :)
 - Chris
PS - Congratulations on your latest Dr. Geo.
2010/9/20 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine  are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Sep 20, 2010, at 9:45 PM, Chris Muller wrote:
Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :)
:)
I still develop for Pharo, but one of my concerns has been the short time between releases. It means there is not much time for a stable, proven Pharo foundation to form before it is abandoned already.
I would not call it abandoned. Because this is not abandoned. Now the system is in such a state even if we are working a lot that we must change it. I do not like to live with duplicated code. I thought we fixed most of it. Or a texteditor/compiler from 30 years ago, even if the age is not a problem :). Did you get that many changes impacting you between 1.0 and 1.1? For example inceptive worked a lot with 1.0 and recently moved to 1.1. I do not know what is their experience but it seems to be good from their side and their application is really sexy and demanding. We do not want to have long release cycle because we get more beta phases where effort is on stabilization and feedback. With longer periods we would be too much alone hacking and people waiting to try the new one. So I think that this is nice tension. Two/Three releases per year give 3 months minimum of beta phase. Now you can also skipped on release on two.
Combined with the Pharo philosophy about backward compatibility, I am quite nervous that Magma is going to get "stuck" in some "old" (what, 3 months?!) version of Pharo that never had much time to gestate in the first place..
I think that the pace of changes will probably slow down. Now what I see with Moose and moose is complex (using AST and other internal parts is that it took 1 day to migrate it). In addition, we will not change for the sake of it but there are still really places that should be changed. I think that magma can gain benefit of the bytecode rewriting library marcus will migrate on top of Opal. In addition I would really like to have more bits so that we can nicely have an immutability bit. And I imagine that the write barrier would benefit greatly of it.
- Chris
PS - Congratulations on your latest Dr. Geo.
2010/9/20 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hopefully Polymorph can help. Hillaire. Sure there are ongoing changes, but hopefully insulated from the "end user". Not by any means perfect, but a start at having a stable interface between look-and-feel and people's expression of user interfaces... My vision, as such, for Polymorph is to evolve to a "competent" interface that can be relied upon. Both the interface and lower level details are in flux, but there's much that can be relied on. The experiment is to flesh-out the needs and standardise (with flexibility). Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr>; <ma.chris.m@gmail.com> Sent: Monday, September 20, 2010 9:12 PM Subject: Re: [Pharo-project] [squeak-dev] Morphic On Sep 20, 2010, at 9:45 PM, Chris Muller wrote:
Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :)
:)
I still develop for Pharo, but one of my concerns has been the short time between releases. It means there is not much time for a stable, proven Pharo foundation to form before it is abandoned already.
I would not call it abandoned. Because this is not abandoned. Now the system is in such a state even if we are working a lot that we must change it. I do not like to live with duplicated code. I thought we fixed most of it. Or a texteditor/compiler from 30 years ago, even if the age is not a problem :). Did you get that many changes impacting you between 1.0 and 1.1? For example inceptive worked a lot with 1.0 and recently moved to 1.1. I do not know what is their experience but it seems to be good from their side and their application is really sexy and demanding. We do not want to have long release cycle because we get more beta phases where effort is on stabilization and feedback. With longer periods we would be too much alone hacking and people waiting to try the new one. So I think that this is nice tension. Two/Three releases per year give 3 months minimum of beta phase. Now you can also skipped on release on two.
Combined with the Pharo philosophy about backward compatibility, I am quite nervous that Magma is going to get "stuck" in some "old" (what, 3 months?!) version of Pharo that never had much time to gestate in the first place..
I think that the pace of changes will probably slow down. Now what I see with Moose and moose is complex (using AST and other internal parts is that it took 1 day to migrate it). In addition, we will not change for the sake of it but there are still really places that should be changed. I think that magma can gain benefit of the bytecode rewriting library marcus will migrate on top of Opal. In addition I would really like to have more bits so that we can nicely have an immutability bit. And I imagine that the write barrier would benefit greatly of it.
- Chris
PS - Congratulations on your latest Dr. Geo.
2010/9/20 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I sometimes get overwhelmed and have probably hit about every other beta or release that I intended to use. The improvements are accumulating and very much appreciated. Thanks! Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, September 20, 2010 4:12 PM To: Pharo-project@lists.gforge.inria.fr; ma.chris.m@gmail.com Subject: Re: [Pharo-project] [squeak-dev] Morphic On Sep 20, 2010, at 9:45 PM, Chris Muller wrote:
Hi Hilaire, I'm not sure if you meant "thrust" or "trust" but... :)
:)
I still develop for Pharo, but one of my concerns has been the short time between releases. It means there is not much time for a stable, proven Pharo foundation to form before it is abandoned already.
I would not call it abandoned. Because this is not abandoned. Now the system is in such a state even if we are working a lot that we must change it. I do not like to live with duplicated code. I thought we fixed most of it. Or a texteditor/compiler from 30 years ago, even if the age is not a problem :). Did you get that many changes impacting you between 1.0 and 1.1? For example inceptive worked a lot with 1.0 and recently moved to 1.1. I do not know what is their experience but it seems to be good from their side and their application is really sexy and demanding. We do not want to have long release cycle because we get more beta phases where effort is on stabilization and feedback. With longer periods we would be too much alone hacking and people waiting to try the new one. So I think that this is nice tension. Two/Three releases per year give 3 months minimum of beta phase. Now you can also skipped on release on two.
Combined with the Pharo philosophy about backward compatibility, I am quite nervous that Magma is going to get "stuck" in some "old" (what, 3 months?!) version of Pharo that never had much time to gestate in the first place..
I think that the pace of changes will probably slow down. Now what I see with Moose and moose is complex (using AST and other internal parts is that it took 1 day to migrate it). In addition, we will not change for the sake of it but there are still really places that should be changed. I think that magma can gain benefit of the bytecode rewriting library marcus will migrate on top of Opal. In addition I would really like to have more bits so that we can nicely have an immutability bit. And I imagine that the write barrier would benefit greatly of it.
- Chris
PS - Congratulations on your latest Dr. Geo.
2010/9/20 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 9/20/2010 11:33 AM, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you? No, I can't.
Pharo provides me a clear vision I can trust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
I too agree. It is very nice to have a clean, clear vision statement in which the community can put its resources behind to accomplish. We can accomplish more together than each alone. The whole is greater than the sum of its parts. Without a unifying vision, you have the sum of its parts. With a vision, you have common goal, a unifying purpose. You have something that can inspire. Something that can guide, in where to draw lines, what to add, what to cut, what belongs in, what belongs out. You can do most anything in either Squeak or Pharo that you can do in the other. But ultimately I believe that Pharo is moving in a direction which empowers more people. Many of the Squeak users can use Squeak for most anything they need or want, primarily because they are very skilled/expert in both Smalltalk/Squeak and also interfacing outside systems via FFI, Alien, plugins, etc. But for those of us who are not so able, who do not have the training or knowledge, Pharo's vision and implementation therefore will IMHO be more enabling and empowering, especially to the less than expert, the little guy. And when Pharo achieves the smaller cleaner core, it will also be more enabling/empowering to the expert. Pharo is explicitly more business friendly in its vision, goals, leadership and community. I am a huge advocate of business in open source. I think as business prospers within the Squeak/Pharo communities that the community improves as does the artifact itself. It is my opinion that Pharo is explicitly more open towards this synergy with business. Squeak is not necessarily against such, but is more of the perspective of we happen to be walking together in the same direction. Pharo is explicitly pro-business. Squeak will not prohibit, but not really support. And yes I know there are businesses based upon Squeak, but primarily owned and operated by experts. For me my initial push into Pharo came simply from wanting/requiring/desiring code completion in workspaces and the browsers. Squeak was and is broken on OCompletion. And I did not see any other alternatives. I read all the messages, tried many things. No success. Even today the issue pops up again on the list. 5 months after the last series of messages which had no clear answer on how to get it working in Squeak. Pharo it just worked out of the box. And thank you Levente for showing how to get it working in Squeak. That might be a little thing, but it is an important thing and it highlights some of the differences and goals of the two projects and communities. I am not against Squeak. I would that we were all one big happy family putting all our energies into something that works for all. But that is not the case and one has to choose where to put ones energies and time. Hopefully most efforts will be usable by both. But as each diverge that may be increasingly difficult. I presently do not see a Pro-business or even particularly business-friendly vision from Squeak. Just my perspective and opinions. Thanks. Jimmie
On Mon, 20 Sep 2010, Jimmie Houchin wrote:
On 9/20/2010 11:33 AM, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you? No, I can't.
Pharo provides me a clear vision I can trust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction. You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
I too agree. It is very nice to have a clean, clear vision statement in which the community can put its resources behind to accomplish. We can accomplish more together than each alone. The whole is greater than the sum of its parts. Without a unifying vision, you have the sum of its parts. With a vision, you have common goal, a unifying purpose. You have something that can inspire. Something that can guide, in where to draw lines, what to add, what to cut, what belongs in, what belongs out.
You can do most anything in either Squeak or Pharo that you can do in the other. But ultimately I believe that Pharo is moving in a direction which empowers more people. Many of the Squeak users can use Squeak for most anything they need or want, primarily because they are very skilled/expert in both Smalltalk/Squeak and also interfacing outside systems via FFI, Alien, plugins, etc. But for those of us who are not so able, who do not have the training or knowledge, Pharo's vision and implementation therefore will IMHO be more enabling and empowering, especially to the less than expert, the little guy. And when Pharo achieves the smaller cleaner core, it will also be more enabling/empowering to the expert.
Pharo is explicitly more business friendly in its vision, goals, leadership and community.
I am a huge advocate of business in open source. I think as business prospers within the Squeak/Pharo communities that the community improves as does the artifact itself. It is my opinion that Pharo is explicitly more open towards this synergy with business. Squeak is not necessarily against such, but is more of the perspective of we happen to be walking together in the same direction.
Pharo is explicitly pro-business. Squeak will not prohibit, but not really support. And yes I know there are businesses based upon Squeak, but primarily owned and operated by experts.
For me my initial push into Pharo came simply from wanting/requiring/desiring code completion in workspaces and the browsers. Squeak was and is broken on OCompletion. And I did not see any other alternatives. I read all the messages, tried many things. No success. Even today the issue pops up again on the list. 5 months after the last series of messages which had no clear answer on how to get it working in Squeak. Pharo it just worked out of the box. And thank you Levente for showing how to get it working in Squeak.
That might be a little thing, but it is an important thing and it highlights some of the differences and goals of the two projects and communities.
I am not against Squeak. I would that we were all one big happy family putting all our energies into something that works for all. But that is not the case and one has to choose where to put ones energies and time. Hopefully most efforts will be usable by both. But as each diverge that may be increasingly difficult.
I presently do not see a Pro-business or even particularly business-friendly vision from Squeak.
Just my perspective and opinions.
Thanks, this is really helpful. The only thing I don't really get is what do you mean by "pro-business" and "business-friendly". What makes Pharo "pro-business"? The pre-installed tools? The familiar looking default UI? (only for mac users) Levente
Thanks.
Jimmie
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Jimmie Houchin wrote:
On 9/20/2010 5:30 PM, Levente Uzonyi wrote: On Mon, 20 Sep 2010, Jimmie Houchin wrote: I presently do not see a Pro-business or even particularly business-friendly vision from Squeak.
Just my perspective and opinions.
Thanks, this is really helpful. The only thing I don't really get is what do you mean by "pro-business" and "business-friendly". What makes Pharo "pro-business"? The pre-installed tools? The familiar looking default UI? (only for mac users)
Hello Levente,
Pharo the artifact is itself not necessarily more or less pro-business than Squeak. Pharo the vision, goals, leadership and community are.
Stephane posted a message on the list back in August: "Poll: missing libraries to support business"
I have never seen such a post on squeak-dev. Nor in my 10+- years on squeak-dev seen many posts for/about business that received much audience. Now if you post about the fun things, etoys, midi, robots, mpeg, ... you get a fair amount of response. Many/most Squeakers are very Squeak being multimedia. I am definitely pro that. But I believe if you support people making money with Squeak/Pharo that the fun stuff is also supported. It has been reasonably, historically the opinion of many that Squeak equates to multimedia, with a strong educational leaning. If you wanted something else, it could be tolerated but not well supported. The Seaside guys had to work hard to arrive at their status. As I say, these are my opinions from reading and lightly participating in the Squeak community for 10+- years.
The post in itself may be impressive, but take into account that Stephane asked the question after people being unhappy about ESUG supporting the developement of an XML-RPC library for Pharo/Squeak.
I have had a very long love/hate relationship with Squeak. I really, really love Squeak. The hate comes in when I find something I can't do in Squeak but can easily do in Python. That frustrates the heck out of me. Python is very pro-business, very business friendly, and it has a large enough community to accomplish those goals. Squeak doesn't have the community to accomplish all that Python has. But Squeak/Smalltalk is much more stable target. Code can last so much longer, be developed much faster. So I believe the community, though smaller, can and will accomplish more and better. At least I believe I accomplish more, better, faster in Squeak/Pharo than in Python.
Most often Squeak lost me whenever I have do things outside of Squeak or Python interfacing with the OS or outside libraries. Python has superior support for databases, etc. Currently I have a business requirement to interface with a COM dll. So at the moment Python empowers or enables me to do that and Squeak/Pharo do not.
This is all I have to do in Python. I have this in my Python app which interfaces the COM dll to interface the server to which I need to communicate.
def make_libraries(self):    """    Before you can use the libraries inside Python, you have to run once the makepy.py script    (.\Lib\site-packages\win32com\client\makepy.py).    Select "The Desired Library" in the choose box.    This will create a wrapper library usable by Python and in the path.    mylib = win32com.client.Dispatch("DesiredLibraryClass") and use.    """    # This line should default to the Python being used by this program.    os.system(r"Lib\site-packages\win32com\client\makepy.py")
And most of the above code is simply to remind me how to use the makepy.py library as I use it so seldom that I don't remember between invocations. Most of my time is spent using the library it provides which gives me access to the dll. I would love to have this capability in Squeak/Pharo. It enables/empowers the little guy who has ideas but can't go low level. He can do Python/Smalltalk but not C or system level programming.
I see more openness for this in Pharo than Squeak. Sure Squeak would accept such a library if it became available. But there isn't much community desire for such business software. It isn't sexy or fun. But it does get the job done and enables business and commerce.
Someone has to write those bindings. If there's no need expressed for such bindings, they won't be written. Btw there's a package named COM on SqueakSource.
From squeak.org "Squeak is the vehicle for a wide range of projects from multimedia applications, educational platforms to commercial web application development."
From pharo-project.org Pharo's goal is to deliver a clean, innovative, free open-source Smalltalk environment. By providing a stable and small core system, excellent developer tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical Smalltalk applications.
Which sounds business oriented, business friendly, pro-business?
The first one is the last sentence of Squeak's description from squeak.org. It doesn't tell us the goals of Squeak, it tells us what it is (or was when the text was written). The first two sentence of the description tells a lot more about Squeak: "Squeak is a modern, open source, full-featured implementation of the powerful Smalltalk programming language and environment. Squeak is highly-portable - even its virtual machine is written entirely in Smalltalk making it easy to debug, analyze, and change." The second one describes (reached and unreached) goals of Pharo. It's hard to compare those, because they don't describe the same thing. AFAIK the goals of Squeak are not available on squeak.org, the mailing list and the Board's site give you more information about this.
Nothing in the Squeak statement sounds like business unless your business is multimedia, education and web apps. Mine is none of those. But I want what is in the Pharo description. Yes, I know much of what is in that description is also in Squeak the artifact. Which leads back to vision, goals, leadership and community. Overtime the artifacts will potentially diverge more due to those intangibles. Those elements in Squeak tend towards primarily multimedia and education and only very secondarily Seaside. Whereas those intangibles in Pharo are seeking to build a community of businesses, researchers, students and individuals who want to use Smalltalk as the basis for what is important to them. IMHO this is a very important aspect for building for the future.
Watching the lists, the players, the discussions and my participation in those has lead to these very subjective opinions. I would be extraordinarily please for Squeak to prove me wrong. I think that Squeak can as it becomes smaller and more modular. But that's the artifact. The intangibles would have to be improved also. The intangibles are often as important and sometimes more so than the artifact. And perceptions are a real basis for decisions.
I would love Squeak/Pharo to eliminate or at least incredibly reduce any need, requirement or desire to drop down to Python to accomplish any of my goals or requirements.
IMHO you can help this by dropping a note to the mailing lists whenever you have to use Python instead of Pharo/Squeak.
Hope this helps.
Yes, it was helpful, thanks. Levente
Jimmie
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about? Levente
Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. I much prefer Pharo. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 5:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about? Levente
Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. I much prefer Pharo.
And why? Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 5:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about?
Levente
Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There are no doubt a growing list of reasons, but the big one is usability. Squeak's (lack of) concept of input focus is a HUGE pain; its defaults of mouse buttons are weird. I could go on, but I prefer to use and (to the extent that I can) help to advance Pharo. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 6:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. I much prefer Pharo.
And why? Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 5:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about?
Levente
Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21 September 2010 02:45, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
There are no doubt a growing list of reasons, but the big one is usability. Â Squeak's (lack of) concept of input focus is a HUGE pain; its defaults of mouse buttons are weird. Â I could go on, but I prefer to use and (to the extent that I can) help to advance Pharo.
I like to use both. And i paying attention to make my projects to run on both projects w/o problems. Both currently are constantly improving in UI and code quality areas. Both having own pros and cons, but its natural, since they are separate projects.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 6:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic
On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote:
Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. Â I much prefer Pharo.
And why?
Levente
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Monday, September 20, 2010 5:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine  are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about?
Levente
Squeak defunct development model? I think so. IMHO, Pharo is trying to fix that, and this is terribly important for a community.
Now, Squeak model of development is may be different, so it may not happen again, I don't know.
IMHO the reason is having total control and that's the same reason why Pharo was created.
This does not matter.
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Le 20/09/2010 23:30, Levente Uzonyi a écrit :
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
In may, when I ported back istoa artifact with Etoys scripting. It was quite pleasant to update these code within Squeak.
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
yes, but not only.
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about?
Sophie. Hilaire -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
On Tue, 21 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 23:30, Levente Uzonyi a écrit :
On Mon, 20 Sep 2010, Hilaire Fernandes wrote:
Le 20/09/2010 17:50, Levente Uzonyi a écrit :
On Sat, 18 Sep 2010, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision.
You could ask the same question with Pharo and Squeak instead of Cuis and Pharo, couldn't you?
No, I can't.
Pharo provides me a clear vision I can thrust: a Smalltalk environment to build third party applications (ie makes my developer life easier). Squeak does not provide me this thrust nor indication of that direction.
When was the last time you used Squeak?
In may, when I ported back istoa artifact with Etoys scripting. It was quite pleasant to update these code within Squeak.
You can object it is matter of point of view, I will object it is a matter of ressources you can allocate to write an application. Mine are limited: I start writing DrGeo under Squeak, then I continued with Pharo. I can really fell the difference: nice Widgets, cleaner system I can understand, ease to integrate changes/improvements upstream. All in all, I get the job done more nicely from my perspective.
So you're using Pharo because of Polymorph?
yes, but not only.
What are the other reasons?
In the past, project got hudge resources (ie Sophie), this project failed to give back to the community in a proper way. Was it because
I don't really get this, which project are you talking about?
Sophie.
Why can't we have stuff from Sophie back to Squeak/Pharo? - only the Sophie developers are familiar with the code and they are not motivated enough to extract it - the license is BSD, so the code can't be included in Pharo/Squeak Levente
Hilaire
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Why can't we have stuff from Sophie back to Squeak/Pharo? - only the Sophie developers are familiar with the code and they are not motivated enough to extract it
Not necessarily their task..... :-) Writing libraries and reusable components is a different project.
- the license is BSD, so the code can't be included in Pharo/Squeak
I googled for BSD MIT license compatibility and found some interesting information see for example http://www.dwheeler.com/essays/floss-license-slide.html the paragraph about BSD in http://producingoss.com/en/license-choosing.html The license might be compatible depending on the "version" of the BSD license. And if not you could extract code and then ask the developers to release it as MIT. MIT and BSD are very close (or the same depending on the version) To summarize: The statement "the license is BSD, so the code can't be included in Pharo/Squeak" is too strong. There might be some problems including code, but they may be solved easily with by writing a few emails.... --Hannes
On Thu, 23 Sep 2010, Hannes Hirzel wrote:
Why can't we have stuff from Sophie back to Squeak/Pharo? - only the Sophie developers are familiar with the code and they are not motivated enough to extract it
Not necessarily their task..... :-)
That's right, but tell me who else is up to the task?
Writing libraries and reusable components is a different project.
- the license is BSD, so the code can't be included in Pharo/Squeak
I googled for BSD MIT license compatibility
and found some interesting information
see for example http://www.dwheeler.com/essays/floss-license-slide.html
the paragraph about BSD in http://producingoss.com/en/license-choosing.html
The license might be compatible depending on the "version" of the BSD license. And if not you could extract code and then ask the developers to release it as MIT.
MIT and BSD are very close (or the same depending on the version)
To summarize: The statement
"the license is BSD, so the code can't be included in Pharo/Squeak"
is too strong. There might be some problems including code, but they may be solved easily with by writing a few emails....
The license is the 3-clause BSD license, it contains the following non-endorsement clause: "Neither the name of the University of Southern California, Los Angeles nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." I wonder what can be done about this. Levente
--Hannes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 9/23/10, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 23 Sep 2010, Hannes Hirzel wrote:
Why can't we have stuff from Sophie back to Squeak/Pharo? - only the Sophie developers are familiar with the code and they are not motivated enough to extract it
Not necessarily their task..... :-)
That's right, but tell me who else is up to the task?
Writing libraries and reusable components is a different project.
- the license is BSD, so the code can't be included in Pharo/Squeak
I googled for BSD MIT license compatibility
and found some interesting information
see for example http://www.dwheeler.com/essays/floss-license-slide.html
the paragraph about BSD in http://producingoss.com/en/license-choosing.html
The license might be compatible depending on the "version" of the BSD license. And if not you could extract code and then ask the developers to release it as MIT.
MIT and BSD are very close (or the same depending on the version)
To summarize: The statement
"the license is BSD, so the code can't be included in Pharo/Squeak"
is too strong. There might be some problems including code, but they may be solved easily with by writing a few emails....
The license is the 3-clause BSD license, it contains the following non-endorsement clause:
"Neither the name of the University of Southern California, Los Angeles nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission."
I would say it means you cannot use University of Southern California, Los Angeles for advertising your software. Or maybe in addition the Sophie developers?
I wonder what can be done about this.
Carve out the pieces we think are useful and ask the Sophie developers to re-license it as MIT. That would be on the safe side. HJH
Levente
--Hannes
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hilaire there is nothing that simple :) I know that some people think that I'm black and white but these people just do not know me well. I know juan and discuss with him since years (when he started his no-etoy image) and I discussed with him at last Smalltalks. It was cool. He realized that I was right about the fact that you should let a chance to people to chose and the time to migrate from one system Morphic to Morphic3 for example and not do the mistake of Flow. I respect his work and vision (= this tells a lot for me because I can be quite disrespectful -- you know my hard rock band attitude). Juan nicely gave me a list of changes he did in Cuis for Pharo and I discussed with him from time to time. I should tell him more when I fix something and I noticed that this is not fixed in cuis but I often do not have the time to check CUIS. Now Juan needs a system to run on 200Mhz machine on shopping mall tv. So I understand that his goal was: control his life and levente is right on that point. Now of course we share common goal, he removed etoys long time ago and pharo redid the same. Some part of CUIS are cleaner than in Pharo but the inverse is true too and it will be more and more. Now we did not started from CUIS because we wanted to take care of the huge pain and effort we put in 3.9 + widestring... Ideally I would love to have a system that is so small, fast and clean that juan would like to use it for his own project. But for that we should work hard :). We should also collaborate more. Now people can help - check CUIS changeset and see how they apply to pharo. I think that Pharo will arrive slowly to the point where the little cleans is less pressuring us and that we will see big changes for the better: for example the new compiler. In addition, several large changes should happen but they will require more effort from us but we will do them: MC clean, new package integration, Code model, tools model. Stef On Sep 18, 2010, at 10:43 AM, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. Anyway the open source ecosystem Darwin alike evolution law will prevail.
Hilaire
Le 18/09/2010 10:09, Stéphane Ducasse a écrit :
Hi Juan
My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great.
Stef
On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks, Stef. I agree on all you say. Stéphane Ducasse wrote:
Hilaire
there is nothing that simple :) I know that some people think that I'm black and white but these people just do not know me well. I know juan and discuss with him since years (when he started his no-etoy image) and I discussed with him at last Smalltalks. It was cool. He realized that I was right about the fact that you should let a chance to people to chose and the time to migrate from one system Morphic to Morphic3 for example and not do the mistake of Flow. I respect his work and vision (= this tells a lot for me because I can be quite disrespectful -- you know my hard rock band attitude). Juan nicely gave me a list of changes he did in Cuis for Pharo and I discussed with him from time to time. I should tell him more when I fix something and I noticed that this is not fixed in cuis but I often do not have the time to check CUIS.
Yes, that would be great.
Now Juan needs a system to run on 200Mhz machine on shopping mall tv. So I understand that his goal was: control his life and levente is right on that point.
Well, obviously I forked from Squeak because the Squeak community didn't want to follow the path I'm walking. But I'd rather not put much emphasis on the "control my life" part. I stated the Cuis objectives as clearly as I could, in the hope to attract others with similar objectives. To me, following those objectives is more important that being in control.
Now of course we share common goal, he removed etoys long time ago and pharo redid the same. Some part of CUIS are cleaner than in Pharo but the inverse is true too and it will be more and more. Now we did not started from CUIS because we wanted to take care of the huge pain and effort we put in 3.9 + widestring...
Yes. I didn't want WideString in Cuis. Building an optional package for it, and refactoring lots of code everywhere in the system to make it NarrowString / WideString agnostic is what it would take to rebase Pharo (or Squeak for that matter) on top of Cuis. It would be quite some work. But until then, I guess Cuis will be a separate project. Cheers, Juan Vuletich
Ideally I would love to have a system that is so small, fast and clean that juan would like to use it for his own project. But for that we should work hard :). We should also collaborate more. Now people can help - check CUIS changeset and see how they apply to pharo. I think that Pharo will arrive slowly to the point where the little cleans is less pressuring us and that we will see big changes for the better: for example the new compiler. In addition, several large changes should happen but they will require more effort from us but we will do them: MC clean, new package integration, Code model, tools model.
Stef
On Sep 18, 2010, at 10:43 AM, Hilaire Fernandes wrote:
Really I don't understand CUIS long term objective, why this work is not done in Pharo? They share the same vision. Anyway the open source ecosystem Darwin alike evolution law will prevail.
Hilaire
Le 18/09/2010 10:09, Stéphane Ducasse a écrit :
Hi Juan
My main problem is that I do not have your knowledge of morph else I would already integrated in pharo the change you did in CUIS. If somebody wants to help this would be great.
Stef
On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
-- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.851 / Virus Database: 271.1.1/3143 - Release Date: 09/18/10 03:34:00
we cleaned a lot already but juan where would you start to clean (which kind of features for example)? On Sep 17, 2010, at 11:58 PM, Juan Vuletich wrote:
DeNigris Sean wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood.
I agree.
Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it?
I _am_ implementing Morphic today. In fact I'm doing it twice at the same time: - Morphic in Cuis ( www.jvuletich.org/Cuis/Index.html ) is much simpler and smaller than in Squeak, although the basic ideas are the same. - Morphic 3 ( http://www.jvuletich.org/Morphic3/Index.html and http://www.jvuletich.org/Morphic3/Morphic3-201006.html ) is a deep redesign. The main ideas are to make it a ZUI, independent of pixel resolution, and use new, higher quality techniques for rendering.
* what would it take (if possible) to get there from the current implementation?
The path I'm walking is: Phase 1 - Remove all non-essential stuff, simplify as much as possible. Phase 2 - Redesign from there. Morphic in Cuis is phase 1. Morphic 3 is phase 2.
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
I'd like to be part of that. Are you setting up a mail list?
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Sean
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
You'd really try Cuis. You'll find it much easier to understand and extend.
Cheers, Juan Vuletich
Juan Vuletich-4 wrote:
I'd like to be part of that. Are you setting up a mail list?
I'll email you. Juan Vuletich-4 wrote:
Your morph should answer true to #handlesMouseDown: and implement #mouseDown:. Same for mouseUp, mouseMove, etc. There are many examples of this in the image already.
Yes, but the handler for my morph will never get called because the TextMorphForShout will handle it first. Juan Vuletich-4 wrote:
You'd really try Cuis. You'll find it much easier to understand and extend.
Cool, I downloaded it at ESUG and started exploring. -- View this message in context: http://forum.world.st/Morphic-tp2544184p2545950.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
If you use NewTextMorph it becomes trivial, because it uses Announcements to announce editions, enter and escape. | m newTextMorph | SmalltalkEditor initialize. TextEditor initialize. Editor initialize. m := Morph new. m class compile:'changeColor self fillStyle: Color random. self extent: self submorphs anyOne extent . self changed'; compile: 'rollbackMorphClass self delete . self class removeSelector: #changeColor; removeSelector: #rollbackMorphClass. '. newTextMorph := NewTextMorph new. newTextMorph padding: 0 ; borderWidth: 0 ; fillStyle: Color transparent ; onEscapeSend: #rollbackMorphClass to: m; onAcceptSend: #changeColor to: m; onEditionSend:#changeColor to: m ; readOnly: false ; announcesEditions: true; autoFit: true . m addMorph: newTextMorph; perform: #changeColor ; openInWorld.
Hi, iâm one of the â hobbyist â end users.. All i read about Morphic is really thrilling, and all i miss is documentation. Expecially on the subject of what design principles Morphic was designed in mind with. All i could find about Morphic was the - one chapter in the Pharo/Squeak by Example book, - the original Self documentation - and a thesis on the subject of âNaked Objectsâ which talks a bit about the ideas that might have been behind Morphic. The little bit of Morphic i could understand seems really interesting and i would really love someone could explain the ideas (it seems it had a different design principle in mind than the MVC paradigm?) of Morphic in Pharo/Squeak more thoroughly to âend usersâ. It also seems that other users have similar problems: http://stackoverflow.com/questions/670727/writing-a-gui-in-squeak -- View this message in context: http://forum.world.st/Morphic-tp2544184p2548950.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
All i could find about Morphic was the - one chapter in the Pharo/Squeak by Example book, - the original Self documentation - and a thesis on the subject of âNaked Objectsâ which talks a bit about the ideas that might have been behind Morphic.
Here you go: http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final.... This is chapter 2 of the "New Blue Book" which describes Morphic top-to-bottom. From design-principles to proper implementation of your #drawOn: method. This is just one of many books that you can read on-line at: http://stephane.ducasse.free.fr/FreeBooks.html - Chris
The little bit of Morphic i could understand seems really interesting and i would really love someone could explain the ideas (it seems it had a different design principle in mind than the MVC paradigm?) of Morphic in Pharo/Squeak more thoroughly to âend usersâ.
It also seems that other users have similar problems: http://stackoverflow.com/questions/670727/writing-a-gui-in-squeak -- View this message in context: http://forum.world.st/Morphic-tp2544184p2548950.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 9/22/10, Chris Muller <asqueaker@gmail.com> wrote:
All i could find about Morphic was the - one chapter in the Pharo/Squeak by Example book, - the original Self documentation - and a thesis on the subject of âNaked Objectsâ which talks a bit about the ideas that might have been behind Morphic.
Here you go:
http://stephane.ducasse.free.fr/FreeBooks/CollectiveNBlueBook/morphic.final....
This is chapter 2 of the "New Blue Book" which describes Morphic top-to-bottom. From design-principles to proper implementation of your #drawOn: method.
The chapter is still a good introduction. The only thing is that now every Morph has the capability to do the layout of its submorphs. So there is no need for an AlignmentMorph anymore. Class comment of AlignmentMorph in current Squeak 4.1 "Used for layout. Since all morphs now support layoutPolicy the main use of this class is no longer needed. Kept around for compability. Supports a few methods not found elsewhere that can be convenient, eg. newRow " See also some info which still holds on http://wiki.squeak.org/squeak/1820 (Morph) http://wiki.squeak.org/squeak/1285 (Morphic Architecture)
This is just one of many books that you can read on-line at:
http://stephane.ducasse.free.fr/FreeBooks.html
- Chris
The little bit of Morphic i could understand seems really interesting and i would really love someone could explain the ideas (it seems it had a different design principle in mind than the MVC paradigm?) of Morphic in Pharo/Squeak more thoroughly to âend usersâ.
It also seems that other users have similar problems: http://stackoverflow.com/questions/670727/writing-a-gui-in-squeak
There's a whole bunch of documentation available in the web, i posted here some interesting ones. http://www.google.ch/url?sa=t&source=web&cd=4&ved=0CDEQFjAD&url=http%3A%2F%2... http://wiki.squeak.org/squeak/30 http://portal.acm.org/citation.cfm?id=215636 http://static.squeak.org/tutorials/morphic-tutorial-1.html Fernando On Sep 21, 2010, at 6:06 PM, reluctant wrote:
Hi, iâm one of the â hobbyist â end users..
All i read about Morphic is really thrilling, and all i miss is documentation. Expecially on the subject of what design principles Morphic was designed in mind with.
All i could find about Morphic was the - one chapter in the Pharo/Squeak by Example book, - the original Self documentation - and a thesis on the subject of âNaked Objectsâ which talks a bit about the ideas that might have been behind Morphic.
The little bit of Morphic i could understand seems really interesting and i would really love someone could explain the ideas (it seems it had a different design principle in mind than the MVC paradigm?) of Morphic in Pharo/Squeak more thoroughly to âend usersâ.
It also seems that other users have similar problems: http://stackoverflow.com/questions/670727/writing-a-gui-in-squeak -- View this message in context: http://forum.world.st/Morphic-tp2544184p2548950.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thank you Sean, for bringing up this topic, joining a bit late, here a few remarks. --Hannes On 9/17/10, DeNigris Sean <sean@clipperadams.com> wrote:
I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it.
I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible
Yes,
2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI.
Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? * what would it take (if possible) to get there from the current implementation?
Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood
Yes
I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users.
A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph.
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best? There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......) I assume Juan does not have this variety anymore in his CUIS image..... Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo. I have started reading the Cuis code, it is helpful for understanding Morphic and once you know your way around you do not mind so much that there are a lot of other things.
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but: 1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol. 2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this. 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case. Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Let's keep the list posted if we come up with anything. Sean p.s. #1 seems to be broken in Squeak and Pharo. I'm going to start another thread. -- View this message in context: http://forum.world.st/Morphic-tp2544184p2608440.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but:
1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol.
2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this.
3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case.
Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Let's keep the list posted if we come up with anything.
Sean
p.s. #1 seems to be broken in Squeak and Pharo. I'm going to start another thread.
Juan has in Cuis 2.6 Morph on: eventName send: selector to: recipient self flag: #jmv. "Do NOT implement EventHandler in Morphic 3 or LightWidgets. Even more. Try to avoid all the stuff in Morphic-OldEvents" self eventHandler ifNil: [self eventHandler: EventHandler new]. self eventHandler on: eventName send: selector to: recipient So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work..... HJH
On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel@gmail.com> wrote:
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but:
1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol.
2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this.
3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. Â IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case.
Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Â Let's keep the list posted if we come up with anything.
Sean
p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start another thread.
Juan has in Cuis 2.6
Morph
on: eventName send: selector to: recipient
i saw such message pattern. Guess where? Announcements! :) announcer on: MyAnnouncement send: #foo to: bar
    self flag: #jmv.     "Do NOT implement EventHandler in Morphic 3 or LightWidgets.     Even more. Try to avoid all the stuff in Morphic-OldEvents"
    self eventHandler ifNil: [self eventHandler: EventHandler new].     self eventHandler on: eventName send: selector to: recipient
So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work.....
The dichotomy here is , that Morph from one side acts as an event recipient, but from another side, it acts as an events source for eventHandler. (as far as i can tell, this is an intent of introducing EventHandler). This could be managed in more gracious manner, by having a single entry point for all events, which coming to morph. Then you can write: singleEntryPointForAllEvents: anEvent self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent fromMorph: self ]. self handleEvent: anEvent and get rid of repetituous code from all places, like: keyStroke: anEvent "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it." self eventHandler ifNotNil: [self eventHandler keyStroke: anEvent fromMorph: self].
HJH
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Thanks, Igor Two questions. 1) I have not been following closely the Pharo development. Does Pharo rely mainly on Announcements (Event objects) for Morphic GUI code these days? MCHttpRepository location: 'http://source.lukas-renggli.ch/announcements' user: '' password: '' 2) I found How Morphic processes events http://wiki.squeak.org/squeak/118 written by Andreas Raab in 2003 Could somebody have a quick look at it and tell me if this still more or less applies to the current Squeak and Pharo implementations? Where do I find a description how Pharo handles Morphic events these days? --Hannes On 9/25/10, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel@gmail.com> wrote:
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but:
1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol.
2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this.
3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. Â IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case.
Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Â Let's keep the list posted if we come up with anything.
Sean
p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start another thread.
Juan has in Cuis 2.6
Morph
on: eventName send: selector to: recipient
i saw such message pattern. Guess where? Announcements! :)
announcer on: MyAnnouncement send: #foo to: bar
    self flag: #jmv.     "Do NOT implement EventHandler in Morphic 3 or LightWidgets.     Even more. Try to avoid all the stuff in Morphic-OldEvents"
    self eventHandler ifNil: [self eventHandler: EventHandler new].     self eventHandler on: eventName send: selector to: recipient
So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work.....
The dichotomy here is , that Morph from one side acts as an event recipient, but from another side, it acts as an events source for eventHandler. (as far as i can tell, this is an intent of introducing EventHandler).
This could be managed in more gracious manner, by having a single entry point for all events, which coming to morph. Then you can write:
singleEntryPointForAllEvents: anEvent self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent fromMorph: self ]. self handleEvent: anEvent
and get rid of repetituous code from all places, like:
keyStroke: anEvent "Handle a keystroke event. The default response is to let my eventHandler, if any, handle it."
self eventHandler ifNotNil: [self eventHandler keyStroke: anEvent fromMorph: self].
HJH
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 25 September 2010 10:41, Hannes Hirzel <hannes.hirzel@gmail.com> wrote:
Thanks, Igor
Two questions.
1) I have not been following closely the Pharo development. Does Pharo rely mainly on Announcements (Event objects) for Morphic GUI code these days?
No. Its just my observation, that some parts of it look almost exactly as in announcements. Yes, and Announcements was born later than Morphic.
MCHttpRepository location: 'http://source.lukas-renggli.ch/announcements' user: '' password: ''
2) I found How Morphic processes events  http://wiki.squeak.org/squeak/118 written by Andreas Raab in 2003
Could somebody have a quick look at it and tell me if this still more or less applies to the current Squeak and Pharo implementations?
Where do I find a description how Pharo handles Morphic events these days?
They are almost the same. This problem with Morphic, for any entry-level developer, that its a huge code base, and it sparsely documented. So, it is really hard to make conclusions about what model it using and what might break, if you change/remove some code.
--Hannes
On 9/25/10, Igor Stasenko <siguctua@gmail.com> wrote:
On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel@gmail.com> wrote:
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass.
Which method did you like best?
Ha ha, should have been *none of these felt...*, but:
1. The on:send:to: was what I /wanted/ to do, with the downside being that it did nothing, lol.
2. The intercept of Morph>>processEvent:using: was okay, but dangerous because it's easy to lock the image when messing with this.
3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy weight for listening in on one event. Â IOW I may have gone that route eventually if the behavior got complex, but didn't like being chained to it for my simple case.
Hannes Hirzel-2 wrote:
There are some notes on this issue at http://wiki.squeak.org/squeak/2477 ( Eddie Cottongim writes: I know of three main ways to handle events in Morphic.......)
Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Â Let's keep the list posted if we come up with anything.
Sean
p.s. #1 seems to be broken in Squeak and Pharo. Â I'm going to start another thread.
Juan has in Cuis 2.6
Morph
on: eventName send: selector to: recipient
i saw such message pattern. Guess where? Announcements! :)
announcer on: MyAnnouncement send: #foo to: bar
    self flag: #jmv.     "Do NOT implement EventHandler in Morphic 3 or LightWidgets.     Even more. Try to avoid all the stuff in Morphic-OldEvents"
    self eventHandler ifNil: [self eventHandler: EventHandler new].     self eventHandler on: eventName send: selector to: recipient
So the best thing as of now would be to remove this in Squeak and Pharo so that the next people who analyze this do not loose time with it and can advance more with the things which work.....
The dichotomy here is , that Morph from one side acts as an event recipient, but from another side, it acts as an events source for eventHandler. (as far as i can tell, this is an intent of introducing EventHandler).
This could be managed in more gracious manner, by having a single entry point for all events, which coming to morph. Then you can write:
singleEntryPointForAllEvents: anEvent   self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent fromMorph: self ].   self handleEvent: anEvent
and get rid of repetituous code from all places, like:
keyStroke: anEvent    "Handle a keystroke event.  The default response is to let my eventHandler, if any, handle it."
   self eventHandler ifNotNil:        [self eventHandler keyStroke: anEvent fromMorph: self].
HJH
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 9/24/10, Sean P. DeNigris <sean@clipperadams.com> wrote:
Hannes Hirzel-2 wrote:
Conclusion: It might be worthwile to find out more how Juan has pruned Morphic in Cuis and if it is still valuable for use, document that and put it to use in Squeak and Pharo.
Cool, I've started this as well. Let's keep the list posted if we come up with anything.
Sean
Yes, for a start, here are some very simple metrics. --Hannes metrics ^HelpTopic title: 'Metrics' contents: ' http://www.squeak.org/ Squeak 4.1 Morph allSubclasses size 323 http://ftp.squeak.org/trunk/ Squeak4.2-alpha-10382 Morph allSubclasses size 330 Squeak4.2-alpha-10548 Morph allSubclasses size 330 http://pharo-project.org/pharo-download/release-1-1 Pharo 1.1 Morph allSubclasses size 282 http://www.jvuletich.org/Cuis/Index.html (Description) http://www.jvuletich.org/Cuis (Download) Cuis 2.7 Morph allSubclasses size 57 Cuis 2.6 Morph allSubclasses size 56 ' -------------------------------------------------------------------------------------------------------------------- The form is a page of a help book which you get when you do for example CustomHelp subclass: #NotesOnMorphicByHannesHirzel instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Help'
This thread is about Morphic and how we can make it great. Please move any other topics (e.g. Squeak vs. Pharo, and why one would use one or the other) off my thread. Have a nice day :) Thanks. Sean -- View this message in context: http://forum.world.st/Morphic-tp2544184p2609146.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (14)
-
Chris Muller -
DeNigris Sean -
Fernando olivero -
Gary Chambers -
Hannes Hirzel -
Hilaire Fernandes -
Igor Stasenko -
Jimmie Houchin -
Juan Vuletich -
Levente Uzonyi -
reluctant -
Schwab,Wilhelm K -
Sean P. DeNigris
-
Stéphane Ducasse