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

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

by StÃ©phane Ducasse

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(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 Guillermo Polito

Welcome! On Mon, Sep 20, 2010 at 3:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > +1 > Yes carla now you can smile > Wow, it seems Carla and GermÃ¡n are alive :P > > On Sep 20, 2010, at 2:55 PM, Igor Stasenko wrote: > > > 2010/9/20 ë¬ë£ì¤íì¢ <daliot.oh(a)gmail.com>: > >> Hi, > >> > >> i joined this mailinglist. > >> > >> I am Korean Hobby Smalltalker first time Europe first time ESUG. > >> > >> Hope you remember me. > >> > >> - HwaJong - > >> > > > > HwaJong , could you add your name written in latin letters to your > > email address, > > because i don't have a Korean font , and i guess many of others too, so > > your name is shown as a 5 glyph boxes with numbers :) > > > > Oh, and please, write something about yourself - the projects you did or > doing, > > because not all of people here was on conference. > > And if you wanna participate in Pharo development or have some ideas, > > feel free to > > put them here or ask questions. > > > >> _______________________________________________ > >> 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. > > > > _______________________________________________ > > 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] MethodName is now Finder

by StÃ©phane Ducasse

Benjamin I would rename patterns into example-based Then when on selector I would propose classes if the guy type something that looks like a class or a part of a class name similarly on class I would propose selector if the guy started to type something like a selectors The idea is to help the user as much as possible. We did the same with the sender and implementor, you can browse a class if you type Point and press cmd-M instead of cmd-B Else did you try to remove the progress bar? because this looks strange. Stef > I've fix some bug and discover how to script packages loading ^^ > > Now, just run > > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'ConfigurationOfFinder'; > load > > ConfigurationOfFinder loadDefault > > > > > Ben > _______________________________________________ > 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] MethodName is now Finder

by StÃ©phane Ducasse

What is important is to have a really simple and intuitive tool interface. Indeed removing the other tools may be simple. I thought the same with RecentMessage but this is not the case with the superclass. > which logic? are you talking about the new finder? how the finder is working. Right now it has several lists of symbols and they can be completely desynchronized from the methods in the system. > Now we broke method finder (snifff) because 1 . 2 . 3 does not find + > sad because I like this tool. > > but this is working on the new finder, isn't it ? Yes is does and I do not understand why :) Stef

Sept. 20, 2010

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

by StÃ©phane Ducasse

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 >

Sept. 20, 2010

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

by Sven Van Caekenberghe

Turned into http://code.google.com/p/pharo/issues/detail?id=2984 On 06 Sep 2010, at 12:07, Sven Van Caekenberghe wrote: > Hello, > > Is this a bug or am I looking at this the wrong way ? > > This usage of #collect:displayingProgress: works as expected: > > #(a b c d e f g) > collect: [:each | (Delay forMilliseconds: 100) wait. each ] > displayingProgress: 'Working' > > While this doesn't: > > #(a b c d e f g) > collect: [:each | (Delay forMilliseconds: 100) wait. each ] > displayingProgress: [:each | 'Collecting ', each asString] > > The similar #do:displayingProgress: does work. > It seems the index is passed into the progress block, not the element. > Maybe this is by design ? > > Sven > > > > _______________________________________________ > 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] MethodName is now Finder

by Mariano Martinez Peck

On Mon, Sep 20, 2010 at 8:06 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > yes > We should take the time to nuke the old tools. why we need to nuke them? we cannot directly remove them? or there are code using it? I thought only final users should use them and only from the menu. > Ideally I would like to get also the logic of the finder to be fixed > > which logic? are you talking about the new finder? > Now we broke method finder (snifff) because 1 . 2 . 3 does not find + > sad because I like this tool. > but this is working on the new finder, isn't it ? > > Stef > > On Sep 20, 2010, at 4:37 PM, Mariano Martinez Peck wrote: > > > > > > > 2010/9/20 Marcus Denker <marcus.denker(a)inria.fr> > >> > >> > >> I have a question...for the future of Pharo 1.2....what will happen with > Method names and method finder? Will both of them removed and put instead > this new finder? > >> I ask because I wonder if we need or not to include these packages in > PharoCore... > >> So...in summary...all these changes will be part of core or is the dev > also involved? > >> > > Core for now. And not as it's own package, but as part of the Tools > package. > > > > > > Excellent. So I guess that at some point (would like to see it 1.2) when > this tool gets stable and reviewed it will be integrated and removed old > tools? > > > > mariano > > > > > > Marcus > > > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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] MethodName is now Finder

by StÃ©phane Ducasse

yes We should take the time to nuke the old tools. Ideally I would like to get also the logic of the finder to be fixed Now we broke method finder (snifff) because 1 . 2 . 3 does not find + sad because I like this tool. Stef On Sep 20, 2010, at 4:37 PM, Mariano Martinez Peck wrote: > > > 2010/9/20 Marcus Denker <marcus.denker(a)inria.fr> >> >> >> I have a question...for the future of Pharo 1.2....what will happen with Method names and method finder? Will both of them removed and put instead this new finder? >> I ask because I wonder if we need or not to include these packages in PharoCore... >> So...in summary...all these changes will be part of core or is the dev also involved? >> > Core for now. And not as it's own package, but as part of the Tools package. > > > Excellent. So I guess that at some point (would like to see it 1.2) when this tool gets stable and reviewed it will be integrated and removed old tools? > > mariano > > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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] cog vm and copy/paste

by John M McIntosh

The mac menu plugin was developed for os-9 and ported to os-x and uses the Carbon 1984 era api. For the V5.x series VM it was completely rewritten in Cocoa so it requires a new plugin that understands the Cocoa Menu API. That or use the Objective-C bridge... On 2010-09-20, at 7:30 AM, Mariano Martinez Peck wrote: > > > 2010/9/20 John M McIntosh <johnmci(a)smalltalkconsulting.com> > No, since maybe the menu handling goes back in some day. > > > But the problem is because of CogVM or this has nothing to do? Sorry for my ignorance. > > On 2010-09-20, at 1:13 AM, Norbert Hartl wrote: > > > Thanks John, > > > > good to know. Would it be easy to remove the menu if there is no native handling available? > > > > Norbert > > > > > > > > Am 20.09.2010 um 06:32 schrieb John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > > >> There is no mac menu plugin, therefore no interface to the mac menu system. So instead of a AppleCmd-C being recognized as a menu event and turned into a synthetic character event for use by the event queue in the smalltalk as a AppleCmd-C, we see the AppleCmd-C in the Objective-C keyboard handler and push that up as a character event. > >> > >> On 2010-09-19, at 6:37 AM, Norbert Hartl wrote: > >> > >>> > >>> On 19.09.2010, at 14:25, StÃ©phane Ducasse wrote: > >>> > >>>> I started today using cog vm. I just downloaded the ones from Eliots site: Cog.app.tgz. I'm using it along with a 12142 core image. With this combination I don't have copy&paste. The menu is there but items are greyed out. Keyboard shortcuts don't work as well. > >>>>> > >>>>> Any hints on this? > >>>> > >>>> may be there something that changed again with the mac hst menu > >>>> have a look to see if you can reinitialize them. > >>> > >>> Don't know exactly how. I checked the vm from John. It is working with keyboard shortcuts but the menus aren't active. Doing > >>> > >>> HostSystemMenus default hostSystemProxy > >>> > >>> gives me a debugger with > >>> > >>> primGetMenuHandle: failed > >>> > >>> I don't know enough to see what is going wrong here. > >>> > >>> Norbert > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> -- > >> =========================================================================== > >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > >> =========================================================================== > >> > >> > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 20, 2010

Re: [Pharo-project] Custom World menu for own apps

by StÃ©phane Ducasse

this is a clear example that a good infrastructure makes your life so simple. Thanks alain Thanks torsten for the how to. On Sep 20, 2010, at 2:48 PM, Torsten Bergmann wrote: > Just for the records: > > in Pharo 1.2. it is now possible to define an own custom pragma > that is used to define a world menu. This is especially usefull > when you create a (commercial) application based on Pharo. > > How it works: > ============= > > 1. Define your new world context menu by providing class methods > with your own custom world menu entries. Instead of using the > usual "worldMenu" pragma we use a custom pragma, here > "myAppWorldMenu": > > > menuCommandOn: aBuilder > <myAppWorldMenu> > (aBuilder item: #'About MyApp') > action: [ 'HelloWorld' inspect ]; > icon: ThemeIcons pharoIcon > > > 2. Switch the world state to use the custom pragram: > > WorldState desktopMenuTitle: 'My shiny App'. > WorldState desktopMenuPragmaKeyword: 'myAppWorldMenu' > > If you want the old one back just evaluate: > > WorldState desktopMenuTitle: 'World'. > WorldState desktopMenuPragmaKeyword: 'worldMenu' > > > Maybe someone can add this to the open pharo book or give me > an account, a short howto and time to include it. > -- > Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! > Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail > > _______________________________________________ > 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