There is booklet https://github.com/SquareBracketAssociates/ Booklet-Infrastructure (Commander chapter).
2018-06-03 16:23 GMT+03:00 Peter Uhnák <[email protected]>: > Commands are responsible to build menu items for themselves. By default >> they build single item. But you can override method and generate multiple >> items. >> Look for example at ClySwitchQueryScopeCommand>>#fillContextMenu:using: >> > > It would be nice to have a complete 1:1 example to a more-complex world > menu. > I see the value of using Commander, but it is (imho) order of magnitude > more complex. > > E.g., for a trivial method that creates a parent and a child entry > > (aBuilder item: #Parent) > icon: #plus asIcon; > label: 'Parent'; > parent: #MostUsedTools; > keyText: 'o, p'; > action: [ self doParentStuff ]. > It looks simpler, yes. But it is completely unreusable. As soon as you will need to access #doParentStuff from places other than standard menu you will duplicate many parts of command (name, icon, shortcut, general initialization of parameters). We already duplicate shortcut information in menu and shortcut builders. Notice #keyText:. I don't think that Commander approach is more difficult than builder. For the first command in application it is almost same. And I would say that adding new menu to application using Commander is much simpler and straightforward task. (aBuilder item: #Child) > parent: #Parent; > label: 'Child'; > icon: #minus asIcon; > keyText: 'o, c'; > action: [ self doChildStuff ]. > > * I would need two classes, one for each command > * For each line of the builder a I need a separate method (shortcut, name, > icon, ...) > * I need another class to represent the "parent" context (similar to > CmdWorldMenuContext) > Look at booklet. In common cases you will not need to use context classes in activation methods. This one can be implemented using World: CmdShortcutCommandActivation by: $s meta for: World But I wanted to not put morphic dependency into such global commands.. * I need to know to know how Commander work to even know what I am doing -- > with the current setup it is obvious and people can just copy paste and be > done. > > I don't really think that it can be any simpler than is the current state, > so any change would inevitably increase complexity. And with commander it > feels like a lot of incidental complexity here. > > Would it be possible to somehow generate commands on the fly? Some sort of > "CmdPluggableCommand" that would be populated based on the current builder? > I don't see the value for this because it will not bring reusable commands. At least I do not see how it could be possible. > > Peter >
