[Pharo-project] Settings + Menu
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
thanks alain I was a bit on vacation because we have some troubles with our house. Stef 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse a écrit :
thanks alain
I was a bit on vacation because we have some troubles with our house. Hi Stephane,
I think the setting should be ok for integration. Can I upload it to Inbox ? I would like to start changing preference declarations. About menus, it seems ok. The main problem is the ordering of menu items. My solution is, for a menu item, to declare its previous item (see worldmenu example in SettingSandBox1) maybe people here have other solutions ? If the menu feature is not desired, it is quite easy to remove it. anyway, I've improved it a little bit. I've attached the new packages. test setting and menu features with: SystemSettingTree new open "browse/change setting values" SystemMenuTree new open "browse/test world menu items (see item menu)" WorldMenuAssembler new doPopUpMenu "popup the world menu test (TheWorldMenu replacement)" Cheers alain
Stef 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Looks cool and I would be glad to see this in Pharo.
    previous: #wmSystemSettings; line: true;
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 1.4 System 2.1 Save 2.2 Save as.. 2.3 Save as new version 2.4 Quit Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Lukas Renggli a écrit :
Looks cool and I would be glad to see this in Pharo.
thanks
previous: #wmSystemSettings; line: true;
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Henrik Henrik Johansen a écrit :
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,
yes, I have to document more, this is the next step.
for example in the core-package explaining each setting type, when to use it over another (FixedSetting vs Setting), etc.
so far use examples implemented in SettingSandBox[12]
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?
You only need to declare your settings in your package. try it: ------------------ - Open the setting tree with "SystemSettingTree new open" - load SettingSandBox1 package you are now able to browse all settings of SettingSandBox1 - then unload SettingSandBox1 package you see that all settings declared in SettingSandBox1 are not viewed anymore ----------------- this is the magic of pragmas (see PragmaCollector class) if you implement a package named 'XXXX', then in XXX, you can have a class named XXXSettings which holds settings declarations (implemented as methods in XXXSettings class). When you load your package, the settings are here and you can use them. Thanks to pragma, the SystemSettingTree browser is able to discover currently installed settings on the fly. Nothing else is needed. This will be exactly the same with the world menu. Imagine you want an entry in the world menu for your application named XXXBrowser. then, in class XXXSettings class, implements the following menu settings: in order to have a submenu: wmXXX <worldMenu> ^ (SettingManager newMenu: 'XXX...') order: 2.1; "just after the second menu item but before the third one" line: true "I want a menu line after my item". and your XXXBrowser open item in your submenu wmXXXBrowserOpen <worldMenu> ^ (SettingManager newMenu: 'Browser' translated) target: XXXBrowser; parent: wmXXX; selector: #open "I guess XXXBrowser class understands #open" or wmXXXBrowserOpen <worldMenu> ^ (SettingManager newMenu: 'Browser' translated) parent: wmXXX; target: [XXXBrowser new window]; selector: #openInWorld and for another XXX related tool wmXXXConfigurationOpen <worldMenu> ^ (SettingManager newMenu: 'Configuration' translated) parent: wmXXX; target: XXXConfig; order: 2; "after wmXXXBrowserOpen" selector: #open "I guess XXXConfig class understands #open" or, all together in a single method: wmXXX <worldMenu> ^ (SettingManager newMenuSiblings: 'XXX...' translated) order: 2.1; menus: { (SettingManager newMenu: 'Browser' translated) target: XXXBrowser; selector: #open. (SettingManager newMenu: 'Configuration' translated) target: XXXConfig; selector: #open } If you unload your package XXX, then XXXSettings and XXX menus are unloaded, that all. If you want to test it, take the new version I have attached to this mail. Hope it is clearer now Thanks for your remarks Cheers Alain
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Alain Plantec -
Henrik Johansen -
Lukas Renggli -
Stéphane Ducasse