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

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

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

by Hilaire Fernandes

Thanks to you Alain, the infrastructure you implemented makes it easy Hilaire Le 20/09/2010 16:02, Alain Plantec a Ã©crit : > thanks! > Alain > > Le 20/09/2010 14:48, Torsten Bergmann a Ã©crit : >> 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. >> -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 20, 2010

Re: [Pharo-project] HwaJong Oh

by Hilaire Fernandes

Welcome on board! Hilaire Le 20/09/2010 13:58, ë¬ë£ì¤íì¢ a Ã©crit : > Hi, > > i joined this mailinglist. > > I am Korean Hobby Smalltalker first time Europe first time ESUG. > > Hope you remember me. > > - HwaJong - -- Dr. Geo, to discover geometry on Linux, Windows, MAC and XO http://community.ofset.org/index.php/DrGeo

Sept. 20, 2010

Re: [Pharo-project] MethodName is now Finder

by Gary Chambers

Fine by me... ;-) Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, September 20, 2010 3:37 PM Subject: Re: [Pharo-project] MethodName is now Finder 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] Custom World menu for own apps

by Gary Chambers

Maybe add to the HelpBrowser in image? Regards, Gary ----- Original Message ----- From: Mariano Martinez Peck To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, September 20, 2010 3:44 PM Subject: Re: [Pharo-project] Custom World menu for own apps I have just created you a user and sent you by email the data... thanks mariano On Mon, Sep 20, 2010 at 2:48 PM, Torsten Bergmann <astares(a)gmx.de> 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 ------------------------------------------------------------------------------ _______________________________________________ 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] UI states

by Gary Chambers

Indeed. Similar "parent" lookup kind of thing though. Sticking to standard CSS names for our Report Builder XML format iwas/is quite handy though. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, September 20, 2010 2:02 PM Subject: Re: [Pharo-project] UI states > On 20 September 2010 12:50, Gary Chambers <gazzaguru2(a)btinternet.com> > wrote: >> Well, that'd be a big overhaul. May as well do something compatible with >> CSS3 perhaps? >> > > Yeah this would be a lot of work :) > Concerning CSS3, this i thinks is orthogonal, since in CSS you > actually describing the > style(s) of element (morph in our case), depending on their context > and/or state. > > While i was talking mostly about managing the morph states, not the > way how you managing > the style information attached to them. > >> Regards, Gary >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Thursday, September 16, 2010 10:53 PM >> Subject: Re: [Pharo-project] UI states >> >> >>> 2010/9/16 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>> >>>> I might be nice for the appearance of all controls, windows etc. to >>>> adhere >>>> to a standard set of UI states as identified: >>>> >>>> Enabled >>>> Enabled Mouse over >>>> Enabled Mouse down inside >>>> Enabled Mouse down outside (*) >>>> >>>> Enabled Selected >>>> Enabled Selected Mouse over >>>> Enabled Selected Mouse down inside >>>> Enabled Selected Mouse down outside (*) >>>> >>>> Disabled >>>> Disabled Mouse over (*) >>>> Disabled Mouse down inside (*) >>>> Disabled Mouse down outside (*) >>>> >>>> Disabled Selected >>>> Disabled Selected Mouse over (*) >>>> Disabled Selected Mouse down inside (*) >>>> Disabled Selected Mouse down outside (*) >>>> >>>> And repeat for additional "inactive" (non-primary/top window) >>>> >>>> >>>> (*) indicates a nice to have, rather than strictly necessary... >>>> >>>> Thoughts appreciated beforehand. Anything missing, suggestions for >>>> fallback >>>> (don't want to have to do all for everything)?... >>>> >>>> Perhpas worth a tutorial/help/etc. for those making new widgets. >>>> >>>> >>>> I'm sure I discussed this with Igor before, but not sure I had a >>>> response. >>>> >>> >>> We discussed a lot before, so i am also not sure if we touched this >>> topic before :) >>> >>> My own (1 year old) idea about states is different. >>> In short: a widget state is better to describe not by a set of flags >>> (disabled/enabled, mouse over/out etc etc), >>> but with stack of modes, where topmost mode (on stack) having a >>> greater preference above those which follow. >>> >>> Then you can easily control the widget appearance depending on modes. >>> An example. >>> >>> By default, you rendering a button using blue color. >>> When mouse is over it, you render it with light-blue color. >>> When button is disabled, you render it with gray color, regardless if >>> mouse over or not over it. >>> >>> From the above description, its easy to compose a right stack of >>> modes, which affecting the widget appearance: >>> >>> initially, a stack is empty( we assume default mode on stack) >>> >>> - default mode (blue background) >>> >>> when mouse enters a widget, you simply pushing a new mode on widget's >>> mode stack: >>> >>> - mouse over(light-blue) >>> - default mode (blue background) >>> >>> and when it leaves, in response to such event, you simply removing the >>> corresponding mode from stack: >>> >>> - default mode (blue background) >>> >>> But one things with disabled dome, that you want a 'disabled mode' to >>> be always on top of the mode stack, >>> regardless of any other modes, which means that you likely don't wanna >>> have: >>> >>> >>> - mouse over(light-blue) >>> - disabled(gray) >>> - default mode (blue background) >>> >>> but always want >>> >>> - disabled(gray) >>> - mouse over(light-blue) >>> ... >>> - default mode (blue background) >>> >>> so, a color, attached to it is always takes a preference. >>> To deal with this, we need just one more rule: each mode having a >>> priority , or (weight), >>> and a simple rule, that when you pushing a mode with lower priority >>> than currently on top of the stack, >>> you insert it after the mode of highest priority you met, so then, >>> when you have it like following: >>> >>> >>> - disabled(100) >>> - default (0) >>> >>> and mouse enters the widget, you making a 'mouseover' mode to have >0 >>> but < 100 priority value, >>> so it is always pushed after disabled. >>> >>> - disabled(100) >>> - mouseover(1) >>> - default (0) >>> >>> in addition to that, in my experimental project, i can attach any >>> attribute to mode(s), so it is more like >>> a set of css rules (a:hover, a:link ...) , so i can even say that in >>> disabled mode i don't even want to react on >>> a mouse enter/leave events so i don't need to be bothered by using >>> priorities, because mouseover mode is >>> never get pushed on mode stack. >>> >>> The next thing, what i'd like to tell more about modes and styles: >>> to render a widget, i start looking for some property (like background >>> color) along the mode stack. >>> And if topmost mode does not defining it, then i going down the stack >>> and querying this property for next mode. >>> Then finally, if its defined nowhere, it goes down to default mode, >>> where it should answer a default value. >>> >>> In this way i have a quite flexible way to define a styles. I can >>> change a various properties for one mode, but leave the rest >>> untouched. >>> More on top of that, i am even can modify a property value(s), >>> returned by mode with sits down the stack.. but i think this is too >>> much >>> for this mail. >>> I just wanted to show you how much more flexibility you can get by >>> using this model :) >>> >>> >>>> Regards, Gary >>>> >>>> _______________________________________________ >>>> 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 >> > > > > -- > 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

[Pharo-project] Issue 2982: DirectoryEntry on Cog VM OSX does not follow symlinks for determining file size

by Sven Van Caekenberghe

http://code.google.com/p/pharo/issues/detail?id=2982 Sven

Sept. 20, 2010

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

by Mariano Martinez Peck

I have just created you a user and sent you by email the data... thanks mariano On Mon, Sep 20, 2010 at 2:48 PM, Torsten Bergmann <astares(a)gmx.de> 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