Re: Debian menus policy
Erik Steffl wrote:
> as far as difference between clicking and dragging (raised in another
> post): you can find many situations where click and drag results in very
> different action:
>
> ms win: right click on desktop brings up menu, right drag selects a
> region (icons within rectangle). note that it's exactly the same
> behaviour window maker would get with proposed left click = menu.
I don't use WindowMaker, so I can't comment on exactly what it does or
how it would be affected.
However, note that in MS Windows, a right-click doesn't bring up just
_any_ menu, but specifically, a properties menu for some object or set
of objects. So right-click and right-drag are really doing almost the
same thing; the only difference is that a right-click gives you the
properties menu for the object under the mouse pointer, whereas a
right-drag gives you a menu for a set of objects contained within the
rectangle defined by the drag.
> other, more loosely related, examples are e.g. items in container
> (window) = click or double click usually selects/activates/changes
> state, drag usually moves them.
The operation in that case is that the mouse-down selects the object,
and then the drag moves it. It's a simple continuation. This is quite
different from popping up an arbitrary system-defined menu (such as the
Debian menu) on the click, but selecting a rectangle of objects on a
drag -- two operations which have nothing whatsoever to do with each
other.
> some WMs: click on borders/title does rise/lower, drag does
> resize/move.
I've seen that. It's awful UI design, unless you have to click on a
_button_ to do the rise/lower.
> note that click when there is active selection generally cancels
> selection, instead of doing normal click operation.
It depends what's under the mouse when you click. If there is an object
there, then usually selection is transferred to that object. Only if
there is no object under the mouse does a click simply cancel the
selection. And having a simple, obvious method like that to say "no
object should be selected" is good. That's what the left click ought to
do when there is nothing (i.e. only the root window) under it, in an
environment that puts icons on the desktop.
> left click bringing up the main menu (debian menu or menu that
> includes debian menu) is most common standard already and it would not
> hurt most of the WMs if added.
Don't just think of the window managers. Think also of file managers that
use the root window, e.g. gmc, nautilus.
> 9wm: left click = nothing (right click = win ops menu + xterm) (no way
> out!)
> afterstep: left click = debian menu
> blackbox: right click = debian menu (left click = nothing)
> ctwm: left click = debian menu (WM menu missing!)
> enlightenment: middle click = debian menu (left click = E menu)
> fvwm: left click = debian menu
> gwm: left click = nothing (right click some menu) (no debian menu)
> icewm: right click debian menu (left click windowlist) (missing menu
> items!)
> kde: left click = app menu (debian menus mixed in) (no way out!)
> sawfish: middle click = debian menu (left click nothing?)
> scwm: dies
> twm: left click = debian menu (WM menu missing!)
> vtwm: left click = debian menu (WM menu missing!)
> window maker: right click = debian menu (left click = select)
> XFwm/XFce: no debian menu (left click = some menu)(no way out!)
> aewm: no menu at all (no way out!)
> lwm: no menu at all (no way out!)
> qvwm: win95 like toolbar, start menu = debian menu (left click =
> nothing)
> uwm: left click = uwm minimal menu (right click = debian menu) (WM menu
> missing!)
> wm2: left click = 'new' menu (no way out!)
Notice that the window managers that ignore the root window left click
are usually ones that are either very minimalist (aewm, lwm), or
specifically designed to work with Gnome (Sawfish). Either way, the
intent is that completely managing the root window is not within the
scope of those window managers; you're expected to have some other
software that handles those events, such as (again) gmc or nautilus.
Craig
Reply to: