- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [ANN 1.1] Pre-built core 1.1.1

by Mariano Martinez Peck

On Sat, Sep 18, 2010 at 4:19 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Ok, all images have been successfully rebuilt. > > The only thing I noticed (apart from the massive speedup in the > one-click images) is that the 'Test Coverage' button in the test > runner is not disabled. I thought that Mariano fixed that? > No :( Stef integrated a change that solves the tests (doing a check if it is running in cog and if true just do a fail). This way at least we can run the test, mark them as fail and do not crash. Now...it would be nice to integrate a change that disable the option to do a TestCoverage or to raise a popup saying "TestCoverage is not supported in Cog yet" or something like that. Otherwise, final users will try to run coverage and vm will crash. I don't know anything about Mprhic, so I have no idea how to do that, otherwise I would have already done it. Cheers Mariano > > Lukas > > On 18 September 2010 10:09, Lukas Renggli <renggli(a)gmail.com> wrote: > > I am already re-building everything on Hudson with this image. > > Hopefully things go well. One-click images will use Cog. > > > > Lukas > > > > On 18 September 2010 09:58, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> > >> On Sep 18, 2010, at 9:34 AM, Sven Van Caekenberghe wrote: > >> > >>> > >>> On 12 Sep 2010, at 12:02, Marcus Denker wrote: > >>> > >>>> > https://gforge.inria.fr/frs/download.php/27479/PharoCore-1.1.1.zip > >>> > >>> The images inside are 11414 but the filenames say otherwise: > >>> > >> Uhh.... I will redo it. > >> > >> There are two other fixes I missed, too. > >> > >>> > >>> Will the official 'stable' link move to this one too (or did it > already) ? > >>> > >> > >> No, this will be done as soon as we have a full image, too. > >> > >> 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 > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 Levente Uzonyi

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

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

by Hilaire Fernandes

Le 20/09/2010 14:48, Torsten Bergmann a Ã©crit : > If you want the old one back just evaluate: > > WorldState desktopMenuTitle: 'World'. > WorldState desktopMenuPragmaKeyword: 'worldMenu' Or better, execute: WorldState defaultWorldMenu. -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 20, 2010