[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request for GNUstep HIG and context menu suggestion.

From: Eric Christopherson
Subject: Re: Request for GNUstep HIG and context menu suggestion.
Date: Wed, 7 Jan 2004 14:59:08 -0600
User-agent: Mutt/1.5.4i

On Wed, Jan 07, 2004 at 08:02:28PM +0700, Banlu Kemiyatorn wrote:
> One way to solve this problem
> is 1) by forcing the context menu to be a submenu in the global menu tree.
> (good thing since context menu entries should be in the global menu already)
> And 2) the global menu should be mapped along the submenu, so user can
> roll back to other part of menu in case that she did click in a wrong place.

I came up with that idea a while back, and agree it might be a good way to
do things, but since then I've had some thoughts about drawbacks to it. For
one thing, the direction and distance you move the mouse to get to a certain
action would change depending on what sort of object's context menu
appeared, if any. For example, right now I am really comfortable with
pressing the right button, moving down and to the right a little, and
releasing the button, to access the Preferences... action. Similarly, in a
given app, I know that to quit all I have to do is press the button, go down
a certain distance, and release the button (although the distance from the
top of the menu to Quit differs between applications). Now, I'm not saying
that I am able to select those actions without looking at them, but I think
the "gestures" that I get used to are still somewhat important in
comfortably and easily finding the action I want.

So, If we map the global menu and the context menu, and position the context
menu by default under the cursor, it might disrupt some muscle memory and
give an inconsistent "feel." On the other hand, if the global menu pops up
under the cursor by default, as it does now, the gestures should still
remain pretty much the same, but we will have a visual clue as to what
actions pertain to the currently selected object.

Another possible drawback is that a new policy would have to be put in
place, whereby each context menu would need its own place on the global
menu. Current apps would probably need to be modified to follow that policy.
As things stand right now, actions pertaining to the current selection can
be found all through the global menu. For example, in Terminal.app if I
select some text, not only the Edit menu but also the submenus of Services
contain actions I can carry out on that text. In GWorkspace if I select a
file, actions relevant to that file exist in *three* separate menus: File,
Tools->Inspectors, and the submenus of Services. In order to make the
proposed scheme work well, those would all have to go in one submenu menu...
correct me if I'm wrong.

By the way, I am glad to see the issue of context menus come up again :)

Furrfu!         r a k k o  at  c h a r t e r  dot  n e t

reply via email to

[Prev in Thread] Current Thread [Next in Thread]