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