September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2984 #collect:displayingProgress: vs #do:displayingProgress: (New Inspector)

by Frederic Pluquet

There is fixed in the last version of NewInspector. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Mon, Sep 20, 2010 at 8:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks this is an important reflex because of the volume and variety of > issue. > > > > Turned into http://code.google.com/p/pharo/issues/detail?id=2984 > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

[Pharo-project] Metacello as a package management system for Pharo

by Mariano Martinez Peck

Hi folks. First of all, sorry for the long email (I guess it will be long). After thinking and discussing hundred of times in the mailing lists, last week we all meet and talk about Metacello and Pharo. Dale, Stef, Marcus, Esteban, all were present. I want to write down all the ideas and solution in order to: not to forget them; and to get feedback and opinions from you. *Problems we want to face: * 1) Right now a user CANNOT know which version of a project is the stable for a specific Pharo version. For example, suppose ConfigurationOfXXX. The user cannot know that XXX 3.45 is the stable for 1.0 and that XXX 5.7.3 is the one for 1.1....etc...so users end up confused not knowing which version to download. In addition, #latestVersion is not enough, because that will answer you the latest version, but that may not be the correct one for older Pharo images. Suppose in the previous case, latestVersion may answer 5.7.3 which may not work in Pharo 1.0..... We want the user to be able to autaticallly load the stable version for each pharo version without needing to know that. 2) Have a repository for each Pharo version so that someone can easily browse the available configurations for that Pharo version, and load them. Not only one as it is now woth MetacelloRepository. 3) Be self contained. Sometimes developers removed packages of versions from their repositories. In such case, Metacello cannot do anything and the load may not work anymore. We want to be able to reproduce the load and be able to load the same 10 years after. *Solution proposed: * The proposed solution may not even involve Metacello. You may have heard about Metacello Project Loader developer by Esteban Lorenzano. See http://www.smallworks.com.ar/en/community/GoferProjectLoader The idea is rename that project to that it is a general name like GoferProjectManager or something like that, because now it will do load but also write :) I will call it GoferProjectManager in this email. The idea is that every developer of a configuration define the stable version for each Dialect version. There are two possible alternatives: a) That each Conf class implements #stableVersion: spec, which could be something like: ConfigurationOfXXX >> stableVersion: spec spec for: #Pharo1.0 do: [ ^ self version: '3.45' ]. spec for: #Pharo1.1 do: [ ^ self version: '5.7.3' ]. spec for: #Pharo1.2 do: [ self error: 'There is no stable version for Pharo 1.2' ]. spec for: #Gemstone do: [ ^ self version: '4.2' ]. ..... or something like that...the idea is that you define stable versions for each platform. The idea is that now the user could do something like this: ConfigurationOfXXX project stableVersion load but he won't do that ;) b) another approach is to specify something in each version, for example: ConfigurationOfXXX >> version345: spec <version: '3.45' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.0' and ConfigurationOfXXX >> version573: spec <version: '5.7.3' imports: #('1.2-baseline')> spec for: #common do: [ spec blessing: #release. spec description: 'Blah balh...'. spec platformVersion: 'Pharo 1.1' Now...any of those alternatives would solve problem 1) Now to solve 3) the idea is that GoferProjectManager could provide something like this: (Gofer project 'XXX') publishVersion: '3.45' for: 'Pharo 1.0' or then (Gofer project 'XXX') publishVersion: '5.7.3' for: 'Pharo 1.1' etc... Then this would do different things: a) Automatically take the conf class (it is important the name conventions!!) b) Commit it into the correct Pharo repository version. For example for 3.4.5 it will commit it in PharoMetacelloRepository10 and 5.7.3 to PharoMetacelloRepository11 c) Traverse all the dependencies of all needed packages and commit all of them to PharoPackagesContainer10 or PharoPackagesContainer11....etc Dale sent few weeks ago a script that does that: takes a conf, a version and a repo and commits all the files to that repo. With all this we solve 2). The idea is that for EACH pharo version we will have 2 repositories, one for the confs and another one for the packages (as a backup). The last point is that when loading we should load everything from the PharoPackagesContainer10 or PharoPackagesContainer11...but we don't want to change all our confs (for example, they are pointing to they own repos or MetacelloRepository)....so the solution is that we use GoferProjectManager to load. Example: Gofer project: 'XXX' loadStable and loadStable would be something like: self stableVersion repositoryOverrides: (self containerRepo); load The idea is that it can use #repositoriesOverride to override with the correct repository... So.....that's all. What do you think? does this make sense? Cheers Mariano

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Jimmie Houchin

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

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by StÃ©phane Ducasse

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(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

Re: [Pharo-project] HwaJong Oh

by StÃ©phane Ducasse

Now I'm curious since I was running around during the show us your project session. Stef

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Igor Stasenko

On 20 September 2010 22:45, Chris Muller <asqueaker(a)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(a)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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Chris Muller

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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] HwaJong Oh

by Norbert Hartl

On 20.09.2010, at 13:58, ë¬ë£ì¤íì¢ wrote: > Hi, > > i joined this mailinglist. > > I am Korean Hobby Smalltalker first time Europe first time ESUG. > > Hope you remember me. Of course I remember. We spent quite some time discussing. And I still think you should show Stef your smalltalk quiz. He'll like it :) Norbert

Sept. 20, 2010

[Pharo-project] [ANN] TDDFacilities - Restarting a test sends #tearDown and #setUp

by Hernan Wilkinson

Hi, I created a new version of TDDFacilities (TDD-Facilities-HernanWilkinson.15) that includes: 1) When debugging a test and the test is changed or restarted, the messages #tearDown and #setUp are sent to the test to restart it in the correct state. (This is something I asked to Niall when showing SUnit 4 at Esug) 2) Fixed and error with the "Create" button that did not appear when doing "Step Into" or "Step Over". 3) Removed code to make it compatible with Pharo 1.1 I hope you like it! Hernan. -- * HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/> *

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Juan Vuletich

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(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)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 > >

Sept. 20, 2010