Or was it to have *any* control?
________________________________________ From: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] Sent: Monday, September 20, 2010 11:50 AM To: [email protected] 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
