Re: Debian menus policy
Erik Steffl wrote:
> Craig Dickson wrote:
>
> > Yes, I meant that when you click on the empty desktop background you are
> > operating on the root window "object", or in the case of MS Windows, the
> > display itself. That is why right-clicking on the Windows desktop gives
> > you the properties menu for the display, which allows you to change the
> > desktop background, change the window frame theme, change video modes,
> > and so on. You certainly don't get a menu from which you can run apps,
> > comparable to the Debian menu.
>
> my argument was that it is not uncommon for click and drag to have
> different (unrelated) functionalities. in this case - right click brings
> up menu, right button drag selects icons (and brings up menu). I admit
> that it is not entirely unrelated (the menus are basically properties,
> even though quite different) but still one brings up the menu (of root
> window) the other one selects icons in region.
The point is that a properties menu appears in both cases; the only
difference is what objects are involved -- the desktop itself, or some
icons contained by the desktop.
> > Depends on whether you want that sort of modal behavior, where a click
> > when something was selected just causes the selection to go away, and
> > then you have to click again to make the menu pop up. I personally don't
> > care for that sort of design, where the click does two different things
> > depending on some other state.
>
> why not? what happens depends on the state of environment, you cannot
> get around that...
But in general, it's good to avoid modal behavior. If I click on an
object, the effect should be the same regardless of the state of other
objects, as much as possible. (It isn't always fully possible because of
natural relationships between objects, or the presence of some other
modal thing such as a dialog box. But if we're just talking about two
icons on a desktop, or one icon and a popped-up root window menu, why
shouldn't clicking on an icon always select it, regardless of whether it
also causes some other object to be unselected?)
> > I mis-stated it slightly. When you click on a window that is not on top,
> > it probably should come to the top; certainly if you click on its title
> > bar. That's quite normal behavior. I dislike clicking on the title bar
> > to push the top window down, though. I'd rather have a button for that,
> > because it's more obvious and you know that the button will be visible
> > if the window is on top (well, unless it's partially off-screen).
>
> OK, that makes sense, even though I find it harder to look for a
> button than to click anywhere (but buttons), it's also more consistent -
> the single click does raise/lower on title and frame (except when
> there's a button). or right click (and than you can make it raise lower
> completely everywhere in decorations). actually my favourite is to use
> the side button (4th button) on my logitech mouse to raise/lower
> anywhere in the window (I haven't found app that would use 4th button),
> dragging by any part of window or window decoration will move window and
> if win key is pressed it resizes the window. very fast and convenient...
> no need for target practicing on those little borders or title...
Yes, I wish X apps would get used to the idea that there are now mice
with more than three buttons (or more than five, if you map wheel
up/down to buttons 4 and 5). Xev shows events on all buttons, but the
apps seem to ignore them.
There are multiple valid ideas of "consistency" here. I personally like
the consistency of knowing that a left-click on a window's titlebar will
_always_ bring it to the top, even if it's already at the top (in which
case it doesn't really do anything). This is particularly useful if I
happen to be using a window theme in which the visual distinction
between focused and unfocused windows is overly subtle. (Yes, I'm a
click-to-focus, focus-always-raises person.)
> > Gnome provides a lot of desktop functionality (panel,
> > desktop icons via gmc or nautilus, applets) so a window manager designed
> > by a Gnome user would naturally tend not to duplicate those
> > capabilities. Whereas other window managers such as Window Maker,
> > Enlightenment, AfterStep, and so on, do provide those things.
>
> frankly I mostly find it tangled together. I don't mind them working
> together (that's actually good) but the way it's done doesn't make much
> sense.
>
> from the user point of view (not talking about corba and other
> services that are behind) it should be easy to use each of gnome 'core
> apps' together or in any combination. e.g. something like this:
>
> panel is ONLY panel
>
> window manager is window manager
>
> file manager is file manager (doesn't play with your root window and
> provides clear way to exit and I mean EXIT, not close all window (which
> might or might not be exit))
>
> root window is managed by either window manager or there's a separate
> application for that (IMO WM should do it).
I mostly agree with you on this. The root window is the tricky part,
because a file manager may want to put icons for filesystems and app
launching on it, and the window manager may want to put icons for
minimized apps on it. So they need to be able to cooperate somehow. Or
they both need to provide some alterate way of getting to those things
that doesn't involve the root window, and provide a user preference for
whether they should use the root window or not, and then the user can
decide which one he wants to manage it.
Personally, I'm not a fan of any desktop icons. I'd rather have apps
minimize to a tray, or just disappear (they're still reachable via the
window menu, anyway), or "minimize" by rolling up into their title bars.
I use a panel for app launchers. (I just wish the Gnome panel could be
made transparent.)
Craig
Reply to: