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

Re: Debian menus policy



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

  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.

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

  it doesn't seem like it's received very well... IMO a little bit of
consistency (not too much) wouldn't hurt but well, it's just IMO.

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

  why not? what happens depends on the state of environment, you cannot
get around that...

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

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

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

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

  now when you start some of these gnome apps it bring with itself bunch
of irrelevant (from user viewpoint) stuff - some even start gnome panel
(and probably something else). now the panel has logout button which is
not logout but it's simply 'quit gnome panel' button.

  in other words - divide and define NICE ELEGANT SIMPLE interfaces.
instead of what gnome did is having a mess of somewhat distinct smaller
messes. and they call it code reuse (that's what I've read few month ago
(6? 9?), maybe they changed opinion in the meantime). by 'they' I mean
more or less Miguel.

	erik



Reply to: