[PROPOSAL] Put the WorldMenu in a Menu bar
Hi everyone, With Guille we are trying to improve the usability of the WorldMenu. The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu... You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it: https://github.com/pharo-project/pharo/pull/1470 See screen in the PR. It still have room for improvements but we think it's stable enough for integration in Pharo. 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) Feedback is welcome. Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar Guille & Cyril -- Cyril Ferlicot https://ferlicot.fr
Hi Guille & Cyril, On 1 June 2018 at 14:22, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi everyone,
With Guille we are trying to improve the usability of the WorldMenu.
The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu...
You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it:
https://github.com/pharo-project/pharo/pull/1470
See screen in the PR.
It still have room for improvements but we think it's stable enough for integration in Pharo.
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)
Feedback is welcome.
Thanks for this. Along with being able to maximise windows completely, making the task-bar distinct at the bottom, these are great changes. Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen (especially if applications add entries), how about a "Start" button in the task-bar that pops up the menu a-la Windows? I'm not tied to the name "Start", it could just be an earth icon, which would save space. (This is actually how I interpreted Cyril's original suggestion) Cheers, Alistair
Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
Guille & Cyril
-- Cyril Ferlicot https://ferlicot.fr
- For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work
I thought that this was due to be swapped for Pharo 7? Was that idea scraped? Peter On Fri, Jun 1, 2018 at 3:18 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Guille & Cyril,
On 1 June 2018 at 14:22, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi everyone,
With Guille we are trying to improve the usability of the WorldMenu.
The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu...
You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it:
https://github.com/pharo-project/pharo/pull/1470
See screen in the PR.
It still have room for improvements but we think it's stable enough for integration in Pharo.
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)
Feedback is welcome.
Thanks for this. Along with being able to maximise windows completely, making the task-bar distinct at the bottom, these are great changes.
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen (especially if applications add entries), how about a "Start" button in the task-bar that pops up the menu a-la Windows? I'm not tied to the name "Start", it could just be an earth icon, which would save space. (This is actually how I interpreted Cyril's original suggestion)
Cheers, Alistair
Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
Guille & Cyril
-- Cyril Ferlicot https://ferlicot.fr
Guille & Cyril wrote>
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows.
Alistair wrote
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen how about a "Start" button in the task-bar that pops up the menu a-la Windows
So this basically reduces to the two UI options: 1. Should Pharo look like an application (and have the menu at the top) 2. Should Pharo look like an OS itself (with a primary "Start" menu in the taskbar as on Windows) Maybe we should support both styles using a setting. Bye T.
On 6/1/18, Torsten Bergmann <astares@gmx.de> wrote:
Guille & Cyril wrote>
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows.
Alistair wrote
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen how about a "Start" button in the task-bar that pops up the menu a-la Windows
So this basically reduces to the two UI options:
1. Should Pharo look like an application (and have the menu at the top)
2. Should Pharo look like an OS itself (with a primary "Start" menu in the taskbar as on Windows)
Maybe we should support both styles using a setting.
Bye T.
+1
I believe we should move to Commander with first class commands.
How would that work when menu entries can be generated dynamically? Peter On Sat, Jun 2, 2018 at 1:32 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 6/1/18, Torsten Bergmann <astares@gmx.de> wrote:
Guille & Cyril wrote>
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows.
Alistair wrote
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen how about a "Start" button in the task-bar that pops up the menu a-la Windows
So this basically reduces to the two UI options:
1. Should Pharo look like an application (and have the menu at the top)
2. Should Pharo look like an OS itself (with a primary "Start" menu in
the
taskbar as on Windows)
Maybe we should support both styles using a setting.
Bye T. +1
Hi Peter. 2018-06-02 19:17 GMT+03:00 Peter Uhnák <i.uhnak@gmail.com>:
I believe we should move to Commander with first class commands.
How would that work when menu entries can be generated dynamically?
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:
Peter
On Sat, Jun 2, 2018 at 1:32 PM, H. Hirzel <hannes.hirzel@gmail.com> wrote:
On 6/1/18, Torsten Bergmann <astares@gmx.de> wrote:
Guille & Cyril wrote>
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows.
Alistair wrote
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen how about a "Start" button in the task-bar that pops up the menu a-la Windows
So this basically reduces to the two UI options:
1. Should Pharo look like an application (and have the menu at the top)
2. Should Pharo look like an OS itself (with a primary "Start" menu in
the
taskbar as on Windows)
Maybe we should support both styles using a setting.
Bye T. +1
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
There is booklet https://github.com/SquareBracketAssociates/ Booklet-Infrastructure (Commander chapter). 2018-06-03 16:23 GMT+03:00 Peter Uhnák <i.uhnak@gmail.com>:
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
On 01/06/2018 15:18, Alistair Grant wrote:
Hi Guille & Cyril,
Thanks for this. Along with being able to maximise windows completely, making the task-bar distinct at the bottom, these are great changes.
Yes, I did not see the problem because I use backgrounds and it was visible :)
Instead of a menu bar at the top, which takes quite a bit of space, and as mentioned may not fit on a small screen (especially if applications add entries), how about a "Start" button in the task-bar that pops up the menu a-la Windows? I'm not tied to the name "Start", it could just be an earth icon, which would save space. (This is actually how I interpreted Cyril's original suggestion)
Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one.
Cheers, Alistair
-- Cyril Ferlicot https://ferlicot.fr
Hi, I really love this idea. I've already added (hacked together) something similar for some of my projects so I am happy to see this is going into Pharo.
- Make it parametrizable to allow users to build a bar with their own menu builder
I would love if it was possible to somewhere (Settings?) just specify a pragma that should be used for the construction of the menu... or perhaps even a list of pragmas. That way the existing mechanism can be simply reused and custom menus can be created just as easily. I think this should be very easy to add. I would really love to have this option also for the regular world menu, but I didn't find a way to easily achieve that.
- What do we do when Pharo is not wide enough?
Hamburger menu?
- What to do when a window is dragged behind?
Currently you cannot drag window above the top side (which I've learned only now :-D ), so the constraint would just move a bit lower? Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion. Peter On Fri, Jun 1, 2018 at 2:22 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:
Hi everyone,
With Guille we are trying to improve the usability of the WorldMenu.
The world menu is by large un-intuitive: - Users are not used to click on a background to open a menu - For those that "get it" they try to do it with right click (Of course, it looks like a context menu!) and that does not work
Since some decades now the default way to display a menu in applications is to have a bar at the top of the windows. We should change that world menu by a menu bar like any application. That will lower the entrance barrier to new users, at the cost of having to move the cursor to the top to look for the menu...
You can find here a PR that add the WorldMenu as a top bar to Pharo and reorganize it:
https://github.com/pharo-project/pharo/pull/1470
See screen in the PR.
It still have room for improvements but we think it's stable enough for integration in Pharo.
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)
Feedback is welcome.
Related issue: https://pharo.fogbugz.com/f/cases/22038/Replace-World-Menu-by-Menu-bar
Guille & Cyril
-- Cyril Ferlicot https://ferlicot.fr
On 01/06/2018 15:25, Peter Uhnák wrote:
Hi,
I really love this idea. I've already added (hacked together) something similar for some of my projects so I am happy to see this is going into Pharo.
- Make it parametrizable to allow users to build a bar with their own menu builder
I would love if it was possible to somewhere (Settings?) just specify a pragma that should be used for the construction of the menu... or perhaps even a list of pragmas. That way the existing mechanism can be simply reused and custom menus can be created just as easily. I think this should be very easy to add.
I don't know if it should be in the SettingBrowser since Pharo currently comes with only one menu (if someone know how to implement a new one it will be easy for him to find the option to change the pragma of the MenuBarMorph), but the pragma should be parametrizable in any case.
I would really love to have this option also for the regular world menu, but I didn't find a way to easily achieve that.
 - What do we do when Pharo is not wide enough?
Hamburger menu?
I'll rephrase, we have ideas to manage all those problems but how do we implement it? Currently there is no widget to do that and sadly we don't have enough time to create them :(
 - What to do when a window is dragged behind?
Currently you cannot drag window above the top side (which I've learned only now :-D ), so the constraint would just move a bit lower?
Yes, but for now when can detect a drop on the menu bar only if the cursor is over the MenubarMorph. If the user drop the window by dragging the bottom, the top of the windows will be under the MenubarMorph.
Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion.
For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it.
Peter
-- Cyril Ferlicot https://ferlicot.fr
Hi Cyril, On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:18, Alistair Grant wrote:
Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones
Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one.
Fair enough. (I haven't had time to do much of anything recently) On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:25, Peter Uhn??k wrote:
Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion.
For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it.
+1 (to integrating a first version and iterating) Cheers, Alistair
Hi, @Cyril I don't know if it should be in the SettingBrowser since Pharo currently
comes with only one menu (if someone know how to implement a new one it will be easy for him to find the option to change the pragma of the MenuBarMorph), but the pragma should be parametrizable in any case.
Adding a new pragma is not a problem, you can use whatever name you want (see e.g. worldMenuExample pragma), but there is no way to tell Pharo to use this instead of the default one. I don't know if it should be in the SettingBrowser since Pharo currently comes
with only one menu
Oh, never mind. I just found out that this is already in place, in WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed to miss this in the past. So if the new menu bar just uses this (WorldState class>>discoveredMenuPragmaKeyword), or uses a similar mechanism (so the menus can differ, which would be also nice), then all is well. I'll rephrase, we have ideas to manage all those problems but how do we
implement it? Currently there is no widget to do that and sadly we don't have enough time to create them :(
I don't know about menu morph, but the bottom menu can handle overflow, can that be used for the time-being? @Sean: Were these projects where you were the only user? No. For experienced users, I struggle to see how "Navigate over to Xyz which
takes up screen real estate" is better than "click wherever the cursor happens to be"
Pharo adds 25px margin on all sides of a full-screen window. This is enough to add menu to each side. So in fact Pharo already wastes 4x as much space to do what you want. Secondly, my menu doesn't match the world menu, it provides the most important/common options that user needs; so yes, it is faster, because it is one or two clicks instead of going through items that are not relevant to the user. Finally, even if I didn't consider full screen, very often I find myself having to move windows, just so I can expose a piece of desktop to click on. Please don't forget that some Pharo applications are meant for (non-programmer) end users, and not for (Pharo) developers. But don't see a problem with adding a checkbox to settings "Menu bar [x]". There is already such a setting for the bottom task bar ("Taskbar..."). Peter On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Cyril,
On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:18, Alistair Grant wrote:
Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones
Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one.
Fair enough. (I haven't had time to do much of anything recently)
On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:25, Peter Uhn??k wrote:
Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion.
For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it.
+1 (to integrating a first version and iterating)
Cheers, Alistair
On Fri, Jun 1, 2018 at 5:11 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
Hi,
@Cyril
I don't know if it should be in the SettingBrowser since Pharo currently
comes with only one menu (if someone know how to implement a new one it will be easy for him to find the option to change the pragma of the MenuBarMorph), but the pragma should be parametrizable in any case.
Adding a new pragma is not a problem, you can use whatever name you want (see e.g. worldMenuExample pragma), but there is no way to tell Pharo to use this instead of the default one.
I don't know if it should be in the SettingBrowser since Pharo currently comes
with only one menu
Oh, never mind. I just found out that this is already in place, in WorldState class>>desktopMenuPragmaKeyword:. I don't know how I managed to miss this in the past. So if the new menu bar just uses this (WorldState class>>discoveredMenuPragmaKeyword), or uses a similar mechanism (so the menus can differ, which would be also nice), then all is well.
Well, actually we are right now doing this: open "self open" self new menuBarItems: WorldState new menuBuilder menuSpec items; open. So the menu bar uses the menuBuilder used by the system, which is hiding the pragma and everything from us :)
I'll rephrase, we have ideas to manage all those problems but how do we
implement it? Currently there is no widget to do that and sadly we don't have enough time to create them :(
I don't know about menu morph, but the bottom menu can handle overflow, can that be used for the time-being?
Well, one thing is to overflow like the bottom bar (growing so all items fit). But I'd like to have a solution (now for this iteration) where overflowing items are hidden and shown in a "..." button or a hamburguer button.
@Sean:
Were these projects where you were the only user?
No.
For experienced users, I struggle to see how "Navigate over to Xyz which
takes up screen real estate" is better than "click wherever the cursor happens to be"
Pharo adds 25px margin on all sides of a full-screen window. This is enough to add menu to each side. So in fact Pharo already wastes 4x as much space to do what you want. Secondly, my menu doesn't match the world menu, it provides the most important/common options that user needs; so yes, it is faster, because it is one or two clicks instead of going through items that are not relevant to the user. Finally, even if I didn't consider full screen, very often I find myself having to move windows, just so I can expose a piece of desktop to click on.
Please don't forget that some Pharo applications are meant for (non-programmer) end users, and not for (Pharo) developers.
But don't see a problem with adding a checkbox to settings "Menu bar [x]". There is already such a setting for the bottom task bar ("Taskbar...").
Peter
On Fri, Jun 1, 2018 at 4:27 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Cyril,
On Fri, Jun 01, 2018 at 03:48:54PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:18, Alistair Grant wrote:
Personally, I would like to have display strategies for the WorldMenu and the user could select the one he likes (because nobody will agree on UI). For example: - Menu bar strategy - World menu strategy - Start button strategy - Composite strategy to have multiple ones
Now it is simple to do the two first, but I will probably not have the time to implement the "Start button" one.
Fair enough. (I haven't had time to do much of anything recently)
On Fri, Jun 01, 2018 at 03:56:14PM +0200, Cyril Ferlicot D. wrote:
On 01/06/2018 15:25, Peter Uhn??k wrote:
Also, is it (easily) possible to configure the position of the menu? Both top/down, as well as RTL and LTR direction (or right-aligned LTR) which I mentioned for the bottom menu in an earlier github discussion.
For now I don't think so. I think it would be cool to integrate this first version then everyone can try to improve it.
+1 (to integrating a first version and iterating)
Cheers, Alistair
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
Peter Uhnák wrote
Pharo adds 25px margin on all sides of a full-screen window.
Good point. I wonder why that's the case! Maybe as you later pointed out to keep some desktop available for clicking. Peter Uhnák wrote
it provides the most important/common options that user needs
Ah! Good to know and interesting, but presumably very subjective. This would seem to point to the need for total individual customizability of the World Menu. Although it is currently flexible, I don't think we have that now. Peter Uhnák wrote
very often I find myself having to move windows, just so I can expose a piece of desktop to click on.
Why don't you use the 25px margin?! ha ha j/k Seriously though, thanks for the explanation it was very helpful. As long as the proposal can be turned on and off it sounds good. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Peter Uhnák wrote
Pharo adds 25px margin on all sides of a full-screen window.
Good point. I wonder why that's the case!
According to the github issue discussion, this is the case.
Peter Uhnák wrote
it provides the most important/common options that user needs
Ah! Good to know and interesting, but presumably very subjective.
For sure. But for an end-user application it is my responsibility to figure out the UI/UX.
Although it is currently flexible, I don't think we have that now.
The pragma collection can be filtered, but it is not used by the code, so it is all-or-nothing, not very flexible. I think this is for future iterations. Peter Uhnák wrote
very often I find myself having to move windows, just so I can expose a piece of desktop to click on.
Why don't you use the 25px margin?! ha ha j/k
This applies to fullscreen only. It doesn't apply when you manually move a window to this space. And for fullscreen, I often have the margin disabled. So that's why. :) Peter
Looks like Pharo 7 will be the most impressive release in all aspects of system:). About pragmas: I believe we should move to Commander with first class commands. It requires to create command classes for all menu items. For example "Save image": SaveImageCommand>>execute Smalltalk snapshot: true andQuit: false. SaveImageCommand class>>worldMenuActivation <classAnnotation> ^CmdContextMenuCommandActivation byRootGroupItemFor: *CmdWorldMenuContext * SaveImageCommand class>>globalShortcutActivation <classAnnotation> ^CmdShortcutCommandActivation by: $s meta shift for: *CmdWorldMenuContext * It will bring reusable commands which activation can be extended 2018-06-01 20:23 GMT+03:00 Peter Uhnák <i.uhnak@gmail.com>:
On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Peter Uhnák wrote
Pharo adds 25px margin on all sides of a full-screen window.
Good point. I wonder why that's the case!
According to the github issue discussion, this is the case.
Peter Uhnák wrote
it provides the most important/common options that user needs
Ah! Good to know and interesting, but presumably very subjective.
For sure. But for an end-user application it is my responsibility to figure out the UI/UX.
Although it is currently flexible, I don't think we have that now.
The pragma collection can be filtered, but it is not used by the code, so it is all-or-nothing, not very flexible. I think this is for future iterations.
Peter Uhnák wrote
very often I find myself having to move windows, just so I can expose a piece of desktop to click on.
Why don't you use the 25px margin?! ha ha j/k
This applies to fullscreen only. It doesn't apply when you manually move a window to this space. And for fullscreen, I often have the margin disabled. So that's why. :)
Peter
Yes, Commander should drive a lot of these things. Very useful for scripting things as well and add new macros. Phil On Fri, Jun 1, 2018, 21:06 Denis Kudriashov <dionisiydk@gmail.com> wrote:
Looks like Pharo 7 will be the most impressive release in all aspects of system:).
About pragmas: I believe we should move to Commander with first class commands. It requires to create command classes for all menu items. For example "Save image":
SaveImageCommand>>execute
Smalltalk snapshot: true andQuit: false.
SaveImageCommand class>>worldMenuActivation <classAnnotation> ^CmdContextMenuCommandActivation byRootGroupItemFor: *CmdWorldMenuContext *
SaveImageCommand class>>globalShortcutActivation
<classAnnotation> ^CmdShortcutCommandActivation by: $s meta shift for: *CmdWorldMenuContext *
It will bring reusable commands which activation can be extended
2018-06-01 20:23 GMT+03:00 Peter Uhnák <i.uhnak@gmail.com>:
On Fri, Jun 1, 2018 at 6:46 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Peter Uhnák wrote
Pharo adds 25px margin on all sides of a full-screen window.
Good point. I wonder why that's the case!
According to the github issue discussion, this is the case.
Peter Uhnák wrote
it provides the most important/common options that user needs
Ah! Good to know and interesting, but presumably very subjective.
For sure. But for an end-user application it is my responsibility to figure out the UI/UX.
Although it is currently flexible, I don't think we have that now.
The pragma collection can be filtered, but it is not used by the code, so it is all-or-nothing, not very flexible. I think this is for future iterations.
Peter Uhnák wrote
very often I find myself having to move windows, just so I can expose a piece of desktop to click on.
Why don't you use the 25px margin?! ha ha j/k
This applies to fullscreen only. It doesn't apply when you manually move a window to this space. And for fullscreen, I often have the margin disabled. So that's why. :)
Peter
Peter Uhnák wrote
I really love this idea. I've already added (hacked together) something similar for some of my projects so I am happy to see this is going into Pharo.
Were these projects where you were the only user? I'm very leery of this change. For experienced users, I struggle to see how "Navigate over to Xyz which takes up screen real estate" is better than "click wherever the cursor happens to be". Could the setting actually be between the current behavior and the new, and not variations on something new that many existing users may not want/benefit from? The new user argument makes some sense, but of all the difficulties I had learning Squeak/Pharo I for one never found the World Menu confusing as a new user. I guess we have to defer to people who deal more directly with newbies on that point⦠----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
But if we can have - the old situation (world menu is click on background) + new task/open window widget - the new task/open window widget + optional 1st special 'start' button (and keep world menu is click on background) - the new task/open window widget + the new menu bar widget that would then cover all cases, no ?
On 1 Jun 2018, at 15:58, Sean P. DeNigris <sean@clipperadams.com> wrote:
Peter Uhnák wrote
I really love this idea. I've already added (hacked together) something similar for some of my projects so I am happy to see this is going into Pharo.
Were these projects where you were the only user? I'm very leery of this change. For experienced users, I struggle to see how "Navigate over to Xyz which takes up screen real estate" is better than "click wherever the cursor happens to be". Could the setting actually be between the current behavior and the new, and not variations on something new that many existing users may not want/benefit from?
The new user argument makes some sense, but of all the difficulties I had learning Squeak/Pharo I for one never found the World Menu confusing as a new user. I guess we have to defer to people who deal more directly with newbies on that pointâ¦
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Sven Van Caekenberghe-2 wrote
- the old situation (world menu is click on background) + new task/open window widget
If there's a "preserve the status quo" option (e.g. World Menu behavior unchanged and no toolbar), I'm happy! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
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
This should definitely be a theme option On Sat, Jul 21, 2018 at 11:28 AM, Sean P. DeNigris <sean@clipperadams.com> 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
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 <hilaire@drgeo.eu> 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
participants (12)
-
Alistair Grant -
Cyril Ferlicot D. -
Denis Kudriashov -
Eric Gade -
Guillermo Polito -
H. Hirzel -
Hilaire -
Peter Uhnák -
phil＠highoctane.be -
Sean P. DeNigris -
Sven Van Caekenberghe -
Torsten Bergmann