Re: My GWorkspace feature request

[Eric Christopherson]

On Tue, Jun 17, 2003 at 03:55:59AM +0200, Pascal Bourguignon wrote:
> That's not a context menu, that's a the-thing-selected menu.

It operates on an object in its current context.

> That's something that already exist in a form: this is exactly the way
> the Macintosh  menues have always  worked: enabling or  disabling menu
> items in function of the current selection.

I don't see any way in which traditional Macintosh menus are similar at all
to context menus or (in your words) "the-thing-selected menu"s.

> Gathering these items on a special menu does not change a lot.

My reason for gathering them into a special menu was so that 1) the right
click could bring up both the application menu and the context menu, thus
solving a problem that annoys me (I'm not saying it annoys anyone else); and
2) the menu could be available in the permanent application menu and in the
transient menu, so that a user would not have to know about the transient in
order to access the functionality. It's just an idea, though.

> The  NeXTSTEP  UI guidelines,  enabling  or  disabling  menu items  is
> disapproved.  The  main  menu   should  be  rather  static,  to  avoid
> surprizing the user  by adding/removing items or by  puzzling him with
> enabled/disabled items.

But still, sometimes entries must be grayed out, since you can't perform
every action on every object.

> Merging this notion with that  of the contextual pop-up menus is plain
> wrong.
> 
> When you right-click on an object to get a contextual pop-up menu, you
> can have a selection that  is meaningful and completely different than
> the clicked  object:
[...skipping something to be addressed in a moment...]
> Putting  such a  contextual  pop-up menu  in  the menu  bar is  silly,
> because once you've  reached the menu bar, the context  is no more the
> object your cursor was over, but the menu bar.

Yes, that is a problem which would need to be worked around. To be most
consistent, I think the popup context/object/item menu would have to include
entries relevant to the *selected* item, not necessarily the item under the
cursor at the time. As you say, moving the cursor away from the object and
onto the application menu (or menu bar) would render any idea of "the object
under the cursor" nearly meaningless.

On the other hand, judging from this list, at least one person besides me is
annoyed at having to first click to select an item before invoking
GWorkspace's currently implemented context menu. We prefer instead being
able to just right-click on an item and having the menu apply to *that*
item, without having to left-click to select it. I admit it'd be tricky to
try to solve this dilemma. The one idea I have is to make right clicking
actually *select* the object before opening the menu, as is done in some
other UIs; but that would be really annoying if the user only intended to
invoke the application menu and not select that object. Hmm.

> the  selection is dead  data, while the  objet is
> life and  you're talking  to it, sending  a message selected  from the
> pop-up menu.

I don't understand what you meant by "dead" vs. live.

> Please, don't mix things that work well separated.

At this point in time there isn't much to "mix", since OpenStep and GNUstep
do not really have context menus to speak of, except in a few unusual cases
such as GWorkspace.

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