On 29 November 2017 at 15:22, Matt Rice <[email protected]> wrote: > > IMO yes having the active app's main menu is intuitive and comfortable, > But i am biased, having the main menu available everywhere without > having to move the mouse ever is > helpful. > > I couldn't find a good example of this, and was having trouble > recalling the behavior when you right clicked on e.g. the dock > miniwindows, the title bar, inactive windows. > > so here is a short video... https://youtu.be/1_glOOYIGlc
I can't and don't speak for anyone else but I do not really understand what is happening in that video. I think I would find this behaviour extremely confusing. The best model I have ever seen for a context-menu *only* driven UI is Acorn RISC OS. I would urge anyone considering this to play with RISC OS in an emulator. It is the only remaining GUI OS still in development that is contemporaneous with NeXTStep without having had a new, different GUI grafted on. (NeXTStep was first demonstrated in 1988-1988 I believe, around the time of Windows 2. Win3 was totally different, Win95 totally different from Win3, although changes since have been smaller. Classic MacOS is no more. Nor, really, are classic AmigaOS or ST TOS/GEM. RISC OS is also the other OS, along with NeXTStep, to have been the only prior art for the Windows TaskBar.) A FOSS emulator for Acorn machines can be downloaded here: https://www.marutan.net/rpcemu/ RISC OS is freely available and the current version is shared-source freeware: https://www.riscosopen.org/content/ RISC OS machines use a 3-button mouse. The buttons are called Select, Menu & Adjust, left to right. Select works like a normal mouse button. Menu opens a context menu _from whatever app the mouse pointer is over when Menu is pressed_ -- regardless of whether it is active or in front or not. Adjust complements Select. Adjust-clicking the "OK" button does Apply -- it applies changes but leaves the dialog open. Adjust-clicking a scrollbar moves in the opposite direction from Select-clicking it. This way, in GNUstep in the video shown, Menu-clicking Edit would get Edit's main menu; Menu-clicking the Workspace filer in the background would get Workspace.app's main menu. Menu-clicking the desktop gets the desktop or window manager's menu. Menu-clicking the Dock gets the Dock's menu. Etc. This is a very efficient and moderately intuitive model; the RISC OS machines were mainly used for teaching schoolchildren. It has improve compliance with Fitts' Law. https://en.wikipedia.org/wiki/Fitts%27s_law Apple pointed out that a top-of-screen menu bar was a huge target; flick the mouse upwards and you will always hit the menu. No aiming is necessary. NeXTStep menus lose this. Top-of-window menus as in Windows require precision aiming. But RISC OS menus require no mouse movement at all. As long as you are over any of the app's windows at all, you get the app's menu. Pointing at a window and getting the menu of a /different app/ would be wildly confusing, IMHO. It seems like a disastrous idea to me. -- Liam Proven • Profile: https://about.me/liamproven Email: [email protected] • Google Mail/Talk/Plus: [email protected] Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053 _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
