Re: _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS & urgency
- From: Elijah Newren <newren gmail com>
- To: Bill Haneman <Bill Haneman sun com>
- Cc: Luke Schierer <lschiere users sourceforge net>, wm-spec-list gnome org, Havoc Pennington <hp redhat com>
- Subject: Re: _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS & urgency
- Date: Mon, 30 May 2005 09:40:52 -0600
Hi Bill,
On 5/30/05, Bill Haneman <Bill Haneman sun com> wrote:
> Elijah Newren wrote:
> >This may be reasonable policy choices for some WMs to choose, but I'm
> >unconvinced that it's optimal behavior for all WMs--and in fact, I'm
> >unconvinced that it's correct behavior from a usability point of view
> >for "mainstream" WMs. (Reasons: (1) Users should be able to ignore
> >apps that are urgent or demanding attention if they so choose and
> >continue working on what they are doing; I do that often. Raising the
> >window so that it occludes what the user was doing harms
> >this--especially raising a window every time it thinks it becomes
> >Urgent. (2) Having your keystrokes go to a window you can't see is
> >confusing for the user.)
> >
> Your reason #2 is invalid in this context, since I _expressly_ was
> referring to "raise", not "focus". Having keystrokes go somewhere
> unexpected is definitely wrong, I think we all agree that this is the
> primary evil to avoid. (See my initial comment).
It was valid, you just misunderstood it. I knew you were referring to
"raise" and not "focus", and so was I. The keystrokes continue going
to window that the user expected to receive them--the confusing part
for the user is that they can't see that window anymore. People don't
like interacting with things that they can't see or that are even
partially obscured (with one glaring caveat that I know of: a number
of people have learned some efficiency advantages in a
do-not-raise-on-unmodified-click environment when heavily overlapping
windows; they (err, um "we") are somewhat of a niche exception
though).
> >Because of this, there's no way this is
> >going to be required in the spec.
> >
> Because of "what?". I am not sure what you are saying here.
Because of the fact that it is not obvious that new windows should be
raised above other windows to all people, there's no reason to put
such a policy requirement in the spec. The spec avoids policy where
possible in order to allow the various WMs to choose their own. For
example, the spec doesn't mandate that windows gain focus by clicking
on them as opposed to moving the mouse into the window.
> My point is that we should NOT confuse the arguments about "focus on
> new" with those regarding "raise on new/urgent", they are quite
> different things.
Agreed, but if you re-read my response, I did treat them
differently--it's just that I have reasons to want NEITHER of them to
be done for certain new windows. And if I don't want it, I'm sure
there are others. Thus, I think that those who want new windows
raised, even if not focused, should talk to the developers of the
window manager they use. (And note that Metacity happens to do that
in the case of modal windows, though that's the only place I think it
makes sense currently)
Cheers,
Elijah
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]