- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] MethodName is now Finder

by Mariano Martinez Peck

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 >

Sept. 20, 2010

Re: [Pharo-project] HwaJong Oh

by Serge Stinckwich

On Mon, Sep 20, 2010 at 7:55 PM, Igor Stasenko <siguctua(a)gmail.com> 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. I read the korean characters on my macintosh without problem. What could be very cool is to to have a korean version of the Pharo by Example book. You told me about a translation of the Squeak by Example book, where could i find it ? See you, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Sept. 20, 2010

Re: [Pharo-project] cog vm and copy/paste

by Mariano Martinez Peck

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 >

Sept. 20, 2010