Re: Debian menus policy
Craig Dickson wrote:
>
> 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.
no, no NO!
there is a difference between clicking on the root window and clicking
on the window or icon or other object on root window. generally, when
talking about clicking on the root window (or on desktop, which is
another commonly used term for the same thing) it means clicking
somewhere where there is NOTHING else, not icon, not icon manager, not
any other object (maybe you feel this was unnecessary stating of obvious
but read on)
so you saying it brings up the menu associated with given object makes
no sense since there is no object in case of clicking on root window
(well, you could say that root window is object in itself, however it
never gets selected in any meaningful/visible way). and in ms windows
you get desktop menu when right clicking the desktop and object menu
when right clicking the icon and object menu (trimmed to common
functions) when more then one object are selected by dragging.
that's (almost) exactly the same behaviour as I was suggesting for
left button in window maker.
left click on root menu is NOT used in window maker. left click on
icon is used, left button dragging is used but not left click (and
there's enough examples of using click and drag for different
functionality without any confusion).
(well, left click is used to cnacel selection, but that does not have
to interfere, just like in other examples, if there is selection, it's
cancelled, if there's no selection menu is brought up - that's fairly
common)
> > 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.
why is it bad? I want it that way (I wouldn't use WM that cannot be
configured to work that way). why should I look for a button?
everything's a button when I want to send window back. I click and it
goes back. how else can you manage a desktop with multiple windows that
(significantly) overlap? always bring up a window list? annoying. using
a permanently visible winow list (as part of panel like gnome or kde)?
waste of space. having no windows that can be completely covered by
other windows? too restrictive...
I'm not saying it's good for everybody, but it's fairly effective way
to mange windows.
note that it makes no sense at all to have a button to raise window
(it would be most probably covered in significant number of cases when
you'd want to use it)
> > 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.
nautilus: it manages desktop if you tell it to manage desktop. if it
manages the desktop then IMO it could bind left click to debian menu
(which is currently not accessible as far as I can see - not a good
thing, IMO). I guess nautilus kinda relies on gnome panel (for app menu)
which is another reason to dislike gnome (not that kde is any better).
this microsoftish thinking of having everything interrelated has IMO no
place in linux.
> > 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
there should be nothing specifically designed to work with gnome. the
only place for 'specifically designed for' is ms win.
> 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.
yes, some of them have it (='minimalness') as a feature, in that case,
well, they would not bring up the menu when user left-clicks on the root
window. I still think that the WMs that do not provide 'normal'
environment (and mainly way out to another WM) should be marked in menu
as one way street or something like that. I mean it's a reasonable
requirement for a WM to be easily replacable (without restarting X) by
another one, with all the windows intact (maybe not on the same virtual
screens, that's kinda inconvenient but not a horrible tragedy).
erik
Reply to: