[PROPOSAL] Put the WorldMenu in a Menu bar

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

Peter Uhnak
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
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

Denis Kudriashov
There is booklet https://github.com/SquareBracketAssociates/Booklet-Infrastructure (Commander chapter).

2018-06-03 16:23 GMT+03:00 Peter Uhnák <[hidden email]>:
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

Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

HilaireFernandes
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



Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

Guillermo Polito
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. 
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

HilaireFernandes
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



Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: [PROPOSAL] Put the WorldMenu in a Menu bar

darth-cheney
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
> 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




--
Eric
12