Elijah Newren wrote:


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.

Yep.  Sorry I misunderstood you the first time I read this.

 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
Yep. I think this is a preference that users who have lived through the "focus stealing" behavior and moved on to a "don't steal" behavior may express more often than users who've never experienced multiple WM behaviors.
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.
Right. I think we're in agreement. I guess I think exposing a user pref here allowing "raise on URGENT" or even "raise new" makes at least as much sense as exposing the option for "focus follows mouse", maybe even more. But, before someone else points it out, that's a topic for another list ;-)

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)

wm-spec-list mailing list
wm-spec-list gnome org

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