[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian menus policy



Erik Steffl wrote:

> Craig Dickson wrote:
>
> > 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.

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.

>   that's (almost) exactly the same behaviour as I was suggesting for
> left button in window maker.

What happens in Window Maker is not really my concern until you try to
make it a "standard" for all window managers to follow.

>   (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)

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.

> > >   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?
>
> [...]
>
>   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)

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).

>   there should be nothing specifically designed to work with gnome. the
> only place for 'specifically designed for' is ms win.

"specifically designed" simply in the sense that it supports Gnome's
standards (window hints, etc.) and doesn't duplicate Gnome
functionality. 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.

Craig



Reply to: