Re: [INFO] NEXTSPACE

[Liam Proven]

On 29 November 2017 at 15:22, Matt Rice <ratmice@gmail.com> 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: lproven@cix.co.uk • Google Mail/Talk/Plus: lproven@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn/AIM/Yahoo: liamproven
UK: +44 7939-087884 • ČR/WhatsApp/Telegram/Signal: +420 702 829 053