Morphic
Locked
123
123
 
Administrator
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Cheers,
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: [hidden email] [[hidden email]] On Behalf Of DeNigris Sean [[hidden email]] Sent: Friday, September 17, 2010 1:29 PM To: The general-purpose Squeak developers list; [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sean P. DeNigris
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sean P. DeNigris
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Morphic
|
|
In reply to this post by Juan Vuletich-4
Yes
and I would like to have a kind of MVP model. Stef On Sep 18, 2010, at 9:15 AM, Hilaire Fernandes wrote: > Le 17/09/2010 23:58, Juan Vuletich a écrit : >> 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. > > > I agree too. This is also why I like so much Polymorph, it adds the > widgets layer on top of Morphic. So now we have the option to use > barebone Moprh for very special widgetries and also standard widget > provided by Polymorph. It becomes very productive to write GUI > application... > > Hilaire > > > -- > Dr. Geo, to discover geometry on Linux, Windows, MAC and XO > http://community.ofset.org/index.php/DrGeo > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
In reply to this post by Stéphane Ducasse
CONTENTS DELETED
The author has deleted this message.
|
|
|
In reply to this post by Juan Vuletich-4
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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
Administrator
|
In reply to this post by Jimmie Houchin-5
See Mars[1] 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
Cheers,
Sean |
|
Administrator
|
In reply to this post by Juan Vuletich-4
I'll email you. Yes, but the handler for my morph will never get called because the TextMorphForShout will handle it first. Cool, I downloaded it at ESUG and started exploring.
Cheers,
Sean |
|
|
In reply to this post by Sean P. DeNigris
>
> 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hilaire
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Or was it to have *any* control?
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]] Sent: Monday, September 20, 2010 11:50 AM To: [hidden email] 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
CONTENTS DELETED
The author has deleted this message.
|
|
|
Nice response summary Hillaire!
Exactly how I feel... Regards, Gary ----- Original Message ----- From: "Hilaire Fernandes" <[hidden email]> To: <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hilaire
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > 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 > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hilaire
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 <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 20 September 2010 22:45, Chris Muller <[hidden email]> 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 <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Chris Muller-3
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 <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |