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

[Pharo-project] Issue 2983: ThemeSettings>>#menuSelectionColor: should return self

by Sven Van Caekenberghe

I turned this into an issue: http://code.google.com/p/pharo/issues/detail?id=2983 On 31 Aug 2010, at 17:14, Sven Van Caekenberghe wrote: > I was playing with the new Pro theme, and this bit me hard (crashed my image several times before I found out why): > > ThemeSettings>>#menuSelectionColor: should return self not a Color, just like all other setters, > > otherwise the cascades in UITheme class>>#newDefaultSettings won't work, although a final #yourself would be good style there too. > > 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] Community in the IDE

by Mariano Martinez Peck

2010/9/18 laurent laffont <laurent.laffont(a)gmail.com> > 2010/9/18 GÃ¶ran Krampe <goran(a)krampe.se> > > On 09/17/2010 12:58 PM, George Herolyants wrote: >> >>> Implemented in some commercial Java IDE. Never tried, but sounds great! >>> :) >>> >> >> I have thought about going further - a publish/subscribe system for >> "development events" where you decide what events you want to publish and >> what you want to receive. Then you could get immediate feedback if someone >> *right now* is modifying a class you wrote, or if someone is publishing a >> new version of a package you are using etc etc. >> > > I like the idea. > > Do someone know a working IRC client (or have the courage to don his > superhero costume and make it working to save our lives :) on Pharo ? So we > can use #pharo-project channel on irc.freenode.net. > I know there was. I think Edgar use to have it in SqueakFUn or similar....not sure where, maybe this: http://map.squeak.org/package/895674d5-0063-49f9-890d-03a69d45b157 http://squeak.preeminent.org/irc-help/irc-help.html > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > > >> >> regards, GÃ¶ran >> >> >> _______________________________________________ >> 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

+1 Yes carla now you can smile 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

Sept. 20, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by StÃ©phane Ducasse

Hi alexander I did: BloclClosure>>silent ^[ self value ] on: ProgressInitiationException do: [ :ex | ex sendNotificationsTo: [ :min :max :curr | Transcript show: min printString,' ',max printString,' ',curr printString; cr ]. ]. On Sep 20, 2010, at 10:33 AM, Alexander LazareviÄ wrote: > Hi Stef, > > this is a tricky thing to do from _within_ Morphic, because even if > you avoid progress notification completely during recompilation by > doing something like this in a workspace > > [ > ClassBuilder beSilent: true. > > Morph subclass: #BorderedMorph > instanceVariableNames: 'borderWidth borderColor borderStyle' > classVariableNames: '' > poolDictionaries: '' > category: 'Morphic-Kernel'. > > ] ensure: [ > ClassBuilder beSilent: false] > > the recompilation will succeed, but you'll end up with an error from > the TextMorph (or subclass of it) of the workspace you've "done" this > code in, because it is also a subclass of BorderedMorph. Yes I got it too :) > You can ignore > the debugger or wrap that code in an error handler that just does a > resume, but yes ... it's not ideal. > > Alex > > 2010/9/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> hi guys >> >> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >> So we should really have a way to specify silent ui action. >> Does anybody have an idea how I could do that? >> >> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >> >> Stef >> _______________________________________________ >> 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] [Pharo-users] moose 4.1

by StÃ©phane Ducasse

cool! On Sep 20, 2010, at 6:14 PM, Tudor Girba wrote: > Hello, > > We are happy to announce the Moose Suite version 4.1: > http://moosetechnology.org/download > > What's new: > > â¢ Significant speed improvements of Mondrian and Glamour > â¢ Improved Mondrian drawing of complex shapes > â¢ Improved Glamour engine to handle cyclic updates > â¢ New user interface look an feel > â¢ Improved set of Glamour widgets > â¢ Re-packaging to strengthen the naming convention > â¢ Re-organization of the code to break unwanted dependencies > â¢ Cleaning of FAMIX > â¢ New extensible design of the Moose Finder > â¢ New PetitParser-based parsers for MSE, Java, and MANIFEST.MF files > â¢ New browser for meta-models described in MSE files > â¢ Based on Pharo 1.1 > > A complete list of issues fixed in this release can be found at:http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fix… > > An incomplete set of future actions: > > â¢ Better browsers for various analyses use cases > â¢ Improved FAMIX query API (MooseChic) > â¢ Improved Glamour widgets > â¢ EyeSee engine for drawing charts > â¢ AST for Java > > > Have fun, > The Moose Team > > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Sept. 20, 2010

Re: [Pharo-project] OT: Transistor-level Simulation of the 6502 CPU in JavaScript

by Eliot Miranda

On Mon, Sep 20, 2010 at 1:46 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > See http://visual6502.org/JSSim/index.html gorgeous! > > > Cheers, > -- Pavel > > _______________________________________________ > 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] [squeak-dev] Morphic

by Gary Chambers

Nice response summary Hillaire! Exactly how I feel... Regards, Gary ----- Original Message ----- From: "Hilaire Fernandes" <hilaire.fernandes(a)gmail.com> To: <pharo-project(a)lists.gforge.inria.fr> 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 Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2010

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

by Hilaire Fernandes

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

Sept. 20, 2010

[Pharo-project] moose 4.1

by Tudor Girba

Hello, We are happy to announce the Moose Suite version 4.1: http://moosetechnology.org/download What's new: â¢ Significant speed improvements of Mondrian and Glamour â¢ Improved Mondrian drawing of complex shapes â¢ Improved Glamour engine to handle cyclic updates â¢ New user interface look an feel â¢ Improved set of Glamour widgets â¢ Re-packaging to strengthen the naming convention â¢ Re-organization of the code to break unwanted dependencies â¢ Cleaning of FAMIX â¢ New extensible design of the Moose Finder â¢ New PetitParser-based parsers for MSE, Java, and MANIFEST.MF files â¢ New browser for meta-models described in MSE files â¢ Based on Pharo 1.1 A complete list of issues fixed in this release can be found at:http://code.google.com/p/moose-technology/issues/list?can=1&q=status=Fix… An incomplete set of future actions: â¢ Better browsers for various analyses use cases â¢ Improved FAMIX query API (MooseChic) â¢ Improved Glamour widgets â¢ EyeSee engine for drawing charts â¢ AST for Java Have fun, The Moose Team

Sept. 20, 2010

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

by Schwab,Wilhelm K

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

Sept. 20, 2010