March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Settings + Menu

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=691 On Mar 26, 2009, at 12:28 AM, Alain Plantec wrote: > Hi all, > > Here my last setting package version > with a test package (Tests-System-Settings) :) > > I've also added a Menu part which allows the using of > pragma for menu discovering and assembling on the fly. > This addon fully reuse what is done for settings. > The idea is the same: use pragma within particular methods > which are defining menu items (thanks to Lukas again for the > idea ;-) ) > The menu assembler is able to collect them and to popup the menu > dynamically. > > The consequences are > - no need for TheWorldMenu class and > - this would be the end of #registerOpenCommand: and > #unregisterOpenCommand:. > > As for settings, the main benefit is that menu items are brought by > packages. > An application specific menu can be added anywhere in the world menu. > One could also use this feature in order to allow user-defined menu > entries. > > As an example, I've re-defined a part of the world menu. > it is implemented in MenuSettings class (package SettingSandBox1). > Such a menu is dynamically assembled and is popup very quickly. > So I think that there would be no more need for a world menu instance > kept alive in the system. > > you can try it with: > > WorldMenuAssembler new doPopUpMenu > > You can also use > > SystemMenuTree new open > > in order to browse all menu entries. > It is only a very simple version. > Maybe it could be used in order to implement a 'menu editor' tool: > define your menus and generate corresponding code. > > > Here are two examples of methods with menu pragma from MenuSettings > class. > > - the Save item : a simple item with one target and one selector > wmSave > <worldMenu> > ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; > selector: #saveSession; > previous: #wmSystemSettings; > description: 'save the current version of the image on disk' > > - the ToolsSet item set : a multi node with a collection of menu items > wmToolSet > <worldMenu> > ^ (SettingManager newMenuSiblings name: 'Toolset') > line: true; > menus: (ToolSet default mainMenuItems > collect: [:item | (SettingManager newMenu: item first) > target: ToolSet default; > selector: item second]) > > Cheers > > alain > > > > > > > > > > <SettingSandBox1-alain_plantec.4.mcz><SettingSandBox2-alain_plantec. > 2.mcz><System-Settings-alain_plantec.22.mcz><Tests-System-Settings- > alain_plantec. > 4.mcz><Menu.gif>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009

[Pharo-project] call for mcm support in Squeaksource

by StÃ©phane Ducasse

Dear wonderful great (no super great) maintainers of the great (no really great) gorgeous squeaksource.... Ok dear Santa It would be great to have mcm support on squeaksource because right now I cannot move mcm files between project nor move their dependent files. Stef

March 26, 2009

Re: [Pharo-project] Settings + Menu

by StÃ©phane Ducasse

On Mar 26, 2009, at 1:15 PM, Henrik Johansen wrote: > Nice! > Haven't had time to delve deep in the code, but installing went fine. > One thing I feel would be useful is some more class-comments, > for example in the core-package explaining each setting type, when to > use it over another (FixedSetting vs Setting), etc. YES YES This is really important that we increase the level of comments in the system > One thing I was wondering after reading the declaration parts in > previous mails was how to add an item to an existing setting's list > (alÃ¡ > SettingSandBox1>> themeSetting) in a separate package (and remove it > if > package is unloaded), the pragmas make this doable I guess? > > Cheers, > Henry > > Alain Plantec wrote: >> Hi all, >> >> Here my last setting package version >> with a test package (Tests-System-Settings) :) >> >> I've also added a Menu part which allows the using of >> pragma for menu discovering and assembling on the fly. >> This addon fully reuse what is done for settings. >> The idea is the same: use pragma within particular methods >> which are defining menu items (thanks to Lukas again for the >> idea ;-) ) >> The menu assembler is able to collect them and to popup the menu >> dynamically. >> >> The consequences are >> - no need for TheWorldMenu class and >> - this would be the end of #registerOpenCommand: and >> #unregisterOpenCommand:. >> >> As for settings, the main benefit is that menu items are brought by >> packages. >> An application specific menu can be added anywhere in the world menu. >> One could also use this feature in order to allow user-defined menu >> entries. >> >> As an example, I've re-defined a part of the world menu. >> it is implemented in MenuSettings class (package SettingSandBox1). >> Such a menu is dynamically assembled and is popup very quickly. >> So I think that there would be no more need for a world menu instance >> kept alive in the system. >> >> you can try it with: >> >> WorldMenuAssembler new doPopUpMenu >> >> You can also use >> >> SystemMenuTree new open >> >> in order to browse all menu entries. >> It is only a very simple version. >> Maybe it could be used in order to implement a 'menu editor' tool: >> define your menus and generate corresponding code. >> >> >> Here are two examples of methods with menu pragma from MenuSettings >> class. >> >> - the Save item : a simple item with one target and one selector >> wmSave >> <worldMenu> >> ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; >> selector: #saveSession; >> previous: #wmSystemSettings; >> description: 'save the current version of the image on disk' >> >> - the ToolsSet item set : a multi node with a collection of menu >> items >> wmToolSet >> <worldMenu> >> ^ (SettingManager newMenuSiblings name: 'Toolset') >> line: true; >> menus: (ToolSet default mainMenuItems >> collect: [:item | (SettingManager newMenu: item first) >> target: ToolSet default; >> selector: item second]) >> >> Cheers >> >> alain >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 >

March 26, 2009

Re: [Pharo-project] Unicode merge

by StÃ©phane Ducasse

If you want that I try it tell me where I can find it. Then another question is what is the fallback if people do not have the plugin (I mean something else than getting a primitive failed). Stef On Mar 26, 2009, at 11:50 AM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> Now I get >> MacOsClipboard>>primitiveFailed >> >> ioReadClipboardData > > you need the extended clipboard plugin. > It is included in the unicode test app. > > We also need to include that in the one-click download. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2009

Re: [Pharo-project] Pharo download version

by Marcus Denker

On 26.03.2009, at 13:36, Torsten Bergmann wrote: > http://code.google.com/p/pharo/wiki/Downloads?tm=2 > > the link is called "Pharo0.1Core-10256.zip" but it downloads > the newer 10259 version. Please update the site ... fixed Marcus -- Marcus Denker -- denker(a)acm.org New! Skype Fwd for iPhone: http://appshopper.com/utilities/voip-fwd

March 26, 2009

[Pharo-project] Pharo download version

by Torsten Bergmann

http://code.google.com/p/pharo/wiki/Downloads?tm=2 the link is called "Pharo0.1Core-10256.zip" but it downloads the newer 10259 version. Please update the site ... Thx Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

March 26, 2009

Re: [Pharo-project] Settings + Menu

by Henrik Johansen

Nice! Haven't had time to delve deep in the code, but installing went fine. One thing I feel would be useful is some more class-comments, for example in the core-package explaining each setting type, when to use it over another (FixedSetting vs Setting), etc. One thing I was wondering after reading the declaration parts in previous mails was how to add an item to an existing setting's list (alÃ¡ SettingSandBox1>> themeSetting) in a separate package (and remove it if package is unloaded), the pragmas make this doable I guess? Cheers, Henry Alain Plantec wrote: > Hi all, > > Here my last setting package version > with a test package (Tests-System-Settings) :) > > I've also added a Menu part which allows the using of > pragma for menu discovering and assembling on the fly. > This addon fully reuse what is done for settings. > The idea is the same: use pragma within particular methods > which are defining menu items (thanks to Lukas again for the idea ;-) ) > The menu assembler is able to collect them and to popup the menu > dynamically. > > The consequences are > - no need for TheWorldMenu class and > - this would be the end of #registerOpenCommand: and > #unregisterOpenCommand:. > > As for settings, the main benefit is that menu items are brought by > packages. > An application specific menu can be added anywhere in the world menu. > One could also use this feature in order to allow user-defined menu > entries. > > As an example, I've re-defined a part of the world menu. > it is implemented in MenuSettings class (package SettingSandBox1). > Such a menu is dynamically assembled and is popup very quickly. > So I think that there would be no more need for a world menu instance > kept alive in the system. > > you can try it with: > > WorldMenuAssembler new doPopUpMenu > > You can also use > > SystemMenuTree new open > > in order to browse all menu entries. > It is only a very simple version. > Maybe it could be used in order to implement a 'menu editor' tool: > define your menus and generate corresponding code. > > > Here are two examples of methods with menu pragma from MenuSettings > class. > > - the Save item : a simple item with one target and one selector > wmSave > <worldMenu> > ^ (SettingManager newMenu: 'Save') target: SmalltalkImage current; > selector: #saveSession; > previous: #wmSystemSettings; > description: 'save the current version of the image on disk' > > - the ToolsSet item set : a multi node with a collection of menu items > wmToolSet > <worldMenu> > ^ (SettingManager newMenuSiblings name: 'Toolset') > line: true; > menus: (ToolSet default mainMenuItems > collect: [:item | (SettingManager newMenu: item first) > target: ToolSet default; > selector: item second]) > > Cheers > > alain > > > > > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009

Re: [Pharo-project] Unicode merge

by Michael Rueger

StÃ©phane Ducasse wrote: > Now I get > MacOsClipboard>>primitiveFailed > > ioReadClipboardData you need the extended clipboard plugin. It is included in the unicode test app. We also need to include that in the one-click download. Michael

March 26, 2009

Re: [Pharo-project] Settings + Menu

by StÃ©phane Ducasse

I agree with lukas :) For the integration right now I have the closure and all the pending issues on my todo list but this should be really no problem Once you have the ordering ok I will intergate it. Thanks again. I like to see this cool energy floating in pharo. stef >>> Instead of introducing these hard dependencies (and possiblity >> conflicts) to define the order and groups, why not use simple >> order/priority number that the items are then sorted along? When >> using >> floats you could even group them along the same integer value. I >> think >> VW does something like that ... >> >> 1.1 Tools >> 1.2 Windows >> 1.3 Debug >> > yes, I suspected there was a problem with the ordering. > I make a try. > thanks for your review. > > Cheers > alain >> Lukas >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 26, 2009

Re: [Pharo-project] Which Squeak problem do you try to solve

by StÃ©phane Ducasse

Markus We loved Squeak: I'm amongst the guy with marcus that did so much etoy and squeak presentations... We translated etoy books in french, german.... We wrote SqueakByExample, we gave lecture all around europe.... We produced a robust release (3.9) We pushed unit tests in squeak. But but but we got burnt to the point of being sick of smalltalk because of code rot and lack of consciousness. Squeak nearly killed our fun and before turning to ruby or python we gave a try to do pharo. Did you look at the code of squeak Project Etoy PasteUpMorph Morph classes? if not I suggest you do it :) This is striking. Take for example Project>>enter: returningFlag revert: revertFlag saveForRevert: saveForRevert Pharo is not an exploratory project. We want to have a good open source smalltalk. Eventually with a scripting syntax, closure, modules, new mop, new files library, unicode support, clean compiler, ..... better IDE, refactoring, better Lint rules, smaller memory footprint. We want to make sure that people can invent good/excellent sotfware system with pharo and at the same time we want to reinvent/rethink smalltalk. So this will be difficult because users will complain but they will get a better system: more tests, more documentation, better design.... Even rebuild etoy on top of it. But only on top not everywhere inside. So we free to join. Now pharo is not a democracy there is no voting board process (because we were with goran the guys that started the squeakfoundation): we will let the community discuss, propose, argue, **send code** and at the end if there is a conflict we will decide (adrian, marcus, mickael, and me) Normally this will be a rare case. We can decide to ask somebody to join the board but this is our decision. We will be transparent, all our decisions are public. Now as a contributor you can really get an impact: alain/gary are a clear examples of that -- we value their code action -- alain removed MVC and isMorphic. So we will always consider your contributions and tell you why we do not integrate them, we will always consider code that improve the system. Stef > After reading your interesting project website, I'm still not quite > sure which (Squeak) problem do you try to solve with Pharo? Or is it > more an exploratory project? > > Thanks in advance for any reply > > Markus Boehm > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 26, 2009