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
