> > 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 ]. (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) * 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? Peter
