Re: [Usability] A (rather long) list of GNOME usability issues

[Elijah Newren <newren gmail com>]

On 10/17/05, Tuomas Kuosmanen <tigert novell com> wrote:
> On Fri, 2005-10-14 at 22:31 +0100, Alan Horkan wrote:
> > (Not) Raising Windows (on DND)
> >
> >   no idea
>
> This might actually be a good thing - we'd need to ponder this a bit of
> course to make sure we dont miss some other issue this might cause, but
> in general it does not sound like a bad behaviour to me at the first
> glance. You can still raise windows just by clicking.

Yes, the behavior is fine.  It can more carefully be specified as
  - Raise on notification from the app that button press didn't start
    a DND
  - Raise on button release if we didn't on do so on button press
    *and* the app specifies that the DND operation never exceeded the
    DND threshold
  - Otherwise, don't raise
The technical problem is that the application needs to notify the
Window Manager what has occurred or could occur for various button
actions (and, also must notify it that button release events have even
occurred since the WM does not get them)

> Another thing I have been pondering about lately is the "passthru" click
> to raise windows - some wm's used to have this as an option years ago -
> and I think Mac OS X does this too. What I mean is that if you click to
> raise a window, that click does not do anything in the program itself.
> This is most evident with the Gimp for example - you have several
> windows open, and you click to raise one of them. Oops, better not have
> a drawing tool selected to do that..
>
> Then again, these two make an interesting problem together when a user
> has click to focus..! Argh. Ideas? Can we capture a "click" but let
> "user drags folder from window" go through? Is this at all possible?

Incidentally, although most any usability engineer (as well as a fair
number of just-keep-it-sane window manager developers) will tell you
that sloppy and mouse focus modes are crack due to the fact that there
is a fair amount of added complexity and unfortunate corner cases
introduced by such methods, I'm pretty sure this issue you point out
with click-to-focus is precisely the reason for which many use sloppy
and mouse focus modes anyway (even though they likely may not realize
that this is the reason).  Fixing this for click-to-focus doesn't
sound sane to me unless we first get something like Valle
mentioned--some kind of visual hinting that widgets won't be usable
until the window is focused.

Cheers,
Elijah