Re: My GWorkspace feature request

[Philippe C . D . Robert]

Hi,

my last post to this thread, I swear ...:-)

On Monday, June 23, 2003, at 07:48 PM, MJ Ray wrote:

> Philippe C.D Robert <philippe.robert@gmx.net> wrote:
> > I do not, at least not intentionally. Contextual menus are as much
> > hidden as any other submenu of the app's menu.
>
> How does one detach a context menu to make it continuously visible?  I
> do that often with submenus when I use them a lot.

You cannot, you should not, it would be just wrong. The name 
"contextual" implies that the menu can only be used within a certain 
context. Do not mix detached menus with contextual menus here, they are 
not the same.

> > And it is definitely faster to point-click an object directly than to 
> > select it and move the
> > mouse to the app's menu and find/select the submenu of choice.
>
> Huh?  Surely you have to select it and then activate the menu, else it
> would break the concept of "targeted actions"...

You point-click an object to show the menu, this is one user action and 
does not break any concept.

> > > The object you point at, or the object you selected?  If you are 
> > > going
> > > to have context menus, you have to deal with things like that too 
> > > and will
> > > probably always confuse people.
> > What is your point, the correct way of dealing with submenus is 
> > covered
> > by the API specs. If this is done in a clean way then users will not 
> > be
> > confused.
>
> My point is that some context menu supporters seem to not want 
> "targeted
> actions".  Instead, they want some sort of "action on object" which is
> not in the UIG at all.

Wrong implementation or wrong usage is not an argument against the 
concept of contextual menus. To bring up a contextual menu you would 
just point-click the particular "object", this is how it is done 
properly, I'd say.

Besides I never read anything about an "action on an object" in this 
thread, as you call it...

> [...]
> > The opposite is true, you operate on objects not on menus. [...]
>
> The development platform is object-orientated.  The GNUstep user 
> interface
> uses objects as a metaphor to help you do actions.  This is not the
> same thing, deliberately so.  The objects that you see in the user
> interface are a metaphor to allow you to carry out actions.  They are
> not the actions.

If you select a text and want to copy it then you have to select it and 
go to the Edit menu and perform the Copy operation. Instead you could 
just point-click the selection of choice and perform the same 
operations w/o moving to the application menu. I often do this in 
Mail.app for example (on Mac OS X), it is very nice and very effective. 
So here the "object" would be the selected text.

> If you want to make a step-look full-OO UI, then go on, but that isn't 
> step, is it?

I do not want to make anything, again do not put words in my mouth. The 
reason why I am writing these emails is because I believe contextual 
menus are a useful addition to our UI and should (IMHO) be defended 
against FUD.

> [...]
> > The fact that *you* call it 'EWB' does not mean that it is 'EWB'.
>
> If you read my sig, you can see I do not claim otherwise.  I am not a
> god and neither are you.  Neither of us has anything other than an a
> opinion on this.  Although, what is fact is that our current UIG has no
> role for context menus and none of their supporters have yet justified
> them to everyone's satisfaction.

Of course we are not gods, but still I disagree with your comment about 
our UIG and moreover - but this is maybe caused by my bad knowledge of 
the English language - to me it seems you claim to know exactly what is 
true and what not, and you do not even try to understand arguments or 
opinions brought in by others. The way you phrase some of your 
arguments indicates a lot to me here... if this is wrong then I 
apologise.

> > And I can only repeat myself, contextual menus do not alter or
> > negatively affect the application main menu. If they do then it's the
> > developer's fault, and has IMHO nothing to do with the overall concept
> > of contextual menus.
>
> I think it does, as the only way for them not to screw consistency is
> to only include elements already on the app menu.  Therefore, 
> developers
> will have to maintain both.  Because developers write the app, they 
> will
> know what is on the hidden menus, so they will use them primarily and
> the app menu is more likely to break.

That is not bad per se, it is the same with 'toolbar' icons for example 
(I do not refer to NSToolbar here but to its concept which is a typical 
element in our UI) .

> Yes, I know the guidelines will say that they should check both, but 
> the
> very fact that we are having this debate illustrates that even the best
> and brightest developers don't always follow the guidelines.

So what? This does not make anything bad, just because some developers 
don't do their job correctly!

> [...]
> > Well, I don't know you, but I think one can call me a big NEXTSTEP 
> > fan,
> > especially because of its UI concepts and style - but still I am open
> > for good inventions, useful additions and enhancements. And while I
> > hope that GNUstep one day will be a good successor to 
> > NEXTSTEP/OPENSTEP
> > I also hope that it continues to evolve, and this certainly includes
> > the UI as well.
>
> As do I, but, as the saying goes: "In God We Trust -- all others must
> bring data."  Trying to screw consistency by coding it into important
> apps and conducting a "UI change by stealth" should be resisted.  That
> way is the road to hell.

I agree, but I do not see an argument against contextual menus here 
either.

That's all from my side,

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip