Re: My GWorkspace feature request

[Eric Christopherson]

On Sun, Jun 15, 2003 at 09:47:19PM +0100, Nicolas Roard wrote:
> On 2003-06-15 14:41:35 +0000 Enrico Sersale <enrico@dtedu.net> wrote:
> 
> >Yes, it is a popup; look in GWLib/BIcon.m, in -menuForEvent:, for example.
> 
> Yep I see it, and I updated my local copy of gw ... works great !
> 
> >I think that right-click must show the Application Menu, so I've added a 
> >modifyer.
> 
> That's why I'm asking it; imho, that should be reverse : pop-up menu should
> appears via right-click, and application menu via ctrl-right-click (or 
> meta-right-click).  Anyway if you aren't on an icon, righ-click will show 
> you the application menu...
> As every OS/Toolkit display the popup menu via right-click, I think it will
> be better to adopt the same behavior...

Here's my 2c.

I've been thinking about popup/context menus for quite a while. Mainly I've
been trying to find some sort of compromise (in my mind only, but I might
implement it in some form some day) between the type of menu you get in
Open/GNUstep, on the one hand, and the type you get in KDE, GNOME, Windows,
and MacOS X, on the other. Namely, I really like context-specific menus, but
I also often want to access an application's main menu without moving my
mouse to the menubar. So what follows is a mix of some of the stuff I've
thought about and some other thoughts prompted by the recent revelation that
GWorkspace has context menus :)

I can see the reasonableness of the contention that using ctrl+right click
instead of regular right click is inconsistent with other toolkits and
desktops. However, changing the default right click behavior would be going
against a longstanding OpenStep tradition. I'm not saying necessarily that
that would be a bad thing; just that it requires some consideration and
deliberation.

I realize you can, as you say, have it pop up only when the cursor is over
an icon (or other UI element perhaps), but there are still some difficulties.
For instance, I have seen some KDE usability discussion about the idea of
clicking in "empty" areas vs. clicking on "active" UI elements. A naive
user may not know which space is "empty" and which is taken up by UI
elements (such as text fields, icons, buttons, etc.) Similarly here it might
be non-intuitive where the user could click to get the app menu.

Then again, if only a few sorts of items (e.g. only icons) can popup context
menus, it might not be so bad, especially considering the usual axiom that
only "advanced" users use right-click menus (an axiom which I am skeptical
of, but which probably has *some* truth to it). Also, some sort of visual
distinction might be given to items that can be right-clicked. Just an idea.

Also, it would be good to establish whether the element would need to be
actually *selected*, or merely hovered over. I prefer only having to hover
over them, but I think I could stand it either way as long as it's
consistent.

Another point is that perhaps ctrl+LEFT click would be better for the popup,
since it is what MacOSX uses (for those with no right button, although it
still works with a 2- or 3-button mouse). AFAIK ctrl+left click doesn't have
any default meaning in Open/GNUstep (correct me if I'm wrong).

                                   - - -

I still haven't talked about the idea I have for context menus. Now bear
with me; this is just an idea I've had, and I realize some issues would have
to be worked out for it to apply to GNUstep.

It goes as follows. Each application would have a "special" menu in its
menubar/application menu. I'm not sure what I would call it, but possible
names I've thought of are Object, Item, or Context. Anyway, this menu would
contain actions that deal with whatever object is selected -- be it a file,
a widget in Gorm, a text selection, a mail message, or whatever. The menu
would be shown in both the menubar/main menu *and* the transient menu (that
thing that pops up by default when you hold the right button in Open/
GNUstep).

The entries in the special menu would change depending on what object is
selected (using the word "selected" very loosely; it might just mean the
mouse pointer is over it). So you would only get actions which make sense in
the current context. The problem that I can see with this, unfortunately, is
that things (such as menus) that change tend to give usability junkies fits.

The remaining feature of my menu design would be that when the user presses
the right button, the *whole* transient application menu should show up,
*plus* the context menu, thus allowing the user easy access to either
application-global actions or context-specific ones, while still separating
them spatially.

The way I envision it, the context menu would be positioned such that its
title cell is directly underneath the mouse pointer, just as the
application menu now starts with its title under the pointer. The
application menu would be positioned just to the left of it, such that the
title cell of the context menu is positioned just to the right of its
corresponding entry in the app menu. Thus it would look just the same as
first opening up the app menu and then mousing down to the "Context" entry
(or whatever name it takes), thus popping open the context submenu; except
that the submenu would start up already open.

Well, I've gone on long enough. Let me know what you think. Like I said, I'm
not sure how well my menu idea would fit GNUstep, but I've been curious what
others might think of it.

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