[nzlug] Observations of gnome kbd+gui behavior: for discussion

[Simon Bridge]

This is under Gnome... I'd be interested in a comparison with other
desktop environments.

When I rt-click on a desktop item I get a context menu under the mouse
pointer - this is right and proper.

If I use the keyboard to interact with the gui - I arrow-key (etc)
through the various items... this is cool, and useful to avoid rsi et
al.

I can summon the context menu for any item under the gun (has focus,
activated, highlighted, whatever - you know what I mean) by hitting the
menu key to the right of the space-bar.

I notice that the menu key also places the context menu under the mouse
pointer.

I can see why one may want to do this - it's consistent behaviour (for
eg) and I wouldn't normally notice as I tend to use icon view and you
use the mouse with icons - that how they are designed to be used.

However, I noticed that users who prefer the list view seem to ignore
the mouse, or move it well away. In which case, the menu pops up in
unexpected locations. (Where one would reasonably expect it to pop up
near what you were looking at - that's what's under the gun, after all.)

Exploring this - I discover that this is the behaviour for vista - the
"windows menu" pops up by the start of the entry in list view - which
has me cooling to the idea a bit :)

Initially I figured that the menu key was a MS-thing, and the developers
just linked it to the rt-click behaviour. Except that the focus dosn't
change.

I also noticed that not all applications behave like this. Firefox (eg)
puts the context menu to the left of the window, near the top.

So the question arises... how does one determine the location that the
context menu appears?

Is this "Vista behaviour" present in any other OS/DE? (It would be
interesting to see how Vistix handles this...)

Additionally, I noticed that I cannot seem to activate panel applets
through the keyboard - there is a shortcut for shifting the focus to the
gnome menu... fine. Presumably I need to assign shortcuts to the
applets. Unless there is some way of finding out default shortcuts - or
if there is a way to step through all the panel items using the arrow
keys, like you can step through the desktop icons???

Lastly - the gnome panel is always on top... so if I have a non-expanded
panel a wee way into the desktop, it obscures part of open windows. In
other systems (Xfce, E17) it is possible to set a configuration to be
always behind...

I realise, none of these are serious issues. The first one boils down to
"linux is not windows"... well doh! And the second that "items intended
to be used with a mouse need a mouse to be used".

One of the things that strikes me about the list view thing, is that
whenever I *need* a list view with all it's detail and layout
advantages, I use the command-line.

Forestalling an STFW response - that last one still itches - I will
point out that I have indeed seen the huge raft of bug reports
concerning menu key (and other gui) behaviour. Intreguingly, the sense
of the reports is that gnome users and developers prefer the context
menu to pop up under the mouse... presumably there is a big discussion
about this archived someplace? A great many people don't want it to
produce a menu at all.

I also tried stuff like xev - the output pressing the menu key, then
rt-click (on terminal) is:

<code>
KeyPress event, serial 32, synthetic NO, window 0x3400001,
    root 0x1a5, subw 0x0, time 2785518484, (-149,207), root:(534,254),
    state 0x0, keycode 117 (keysym 0xff67, Menu), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x3400001,
    root 0x1a5, subw 0x0, time 2785518588, (-149,207), root:(534,254),
    state 0x0, keycode 117 (keysym 0xff67, Menu), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 32, synthetic NO, window 0x3400001,
    mode NotifyNormal, detail NotifyNonlinear

PropertyNotify event, serial 32, synthetic NO, window 0x3400001,
    atom 0x16e (_NET_WINDOW_DECOR), time 2785525903, state
PropertyNewValue

PropertyNotify event, serial 32, synthetic NO, window 0x3400001,
    atom 0x16f (_COMPIZ_WM_WINDOW_BLUR_DECOR), time 2785525903, state
PropertyNewValue
</code>
... I didn't really expect the actual click to show up explicitly like
the keypress/release.