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 |
There is booklet https://github.com/
2018-06-03 16:23 GMT+03:00 Peter Uhnák <[hidden email]>:
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.
Look at booklet. In common cases you will not need to use context classes in activation methods. This one can be implemented using World:
But I wanted to not put morphic dependency into such global commands..
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.
|
In reply to this post by CyrilFerlicot
Can the bar menu be customized as it is the case with the World menu ?
(i.e. DrGeo world menu) Hilaire Le 01/06/2018 à 14:22, Cyril Ferlicot D. a écrit : > Missing features: > - What do we do when Pharo is not wide enough? > - What to do when a window is dragged behind? > - Make it parametrizable to allow users to build a bar with their own > menu builder > - Add shortcuts to open the menu windows like (maybe) > - Update it when we change the font size (this is a general Pharo problem) -- Dr. Geo http://drgeo.eu |
Hi Hilaire,
On Tue, Jun 5, 2018 at 9:38 PM, Hilaire <[hidden email]> wrote: Can the bar menu be customized as it is the case with the World menu ? (i.e. DrGeo world menu) The menu bar is populated the same way as the World menu. So if you change the world menu, or the world menu pragma and you rebuild the menu the menu bar will be updated accordingly. |
Cool.
Hilaire Le 06/06/2018 à 13:11, Guillermo Polito a écrit : > The menu bar is populated the same way as the World menu. So if you > change the world menu, or the world menu pragma and you rebuild the > menu the menu bar will be updated accordingly. -- Dr. Geo http://drgeo.eu |
Administrator
|
In reply to this post by Sean P. DeNigris
Sean P. DeNigris wrote
> If there's a "preserve the status quo" option (e.g. World Menu behavior > unchanged and no toolbar), I'm happy! Is there still no way to get the old World Menu back in Pharo 7? Am I the only one that wants this? On the positive side, I had to finally learn and use the tool opening shortcuts. My understanding of general experimental-new-feature etiquette is that whoever broke something should fix it… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Cheers,
Sean |
This should definitely be a theme option On Sat, Jul 21, 2018 at 11:28 AM, Sean P. DeNigris <[hidden email]> wrote: Sean P. DeNigris wrote -- Eric |
Free forum by Nabble | Edit this page |