LCA: Two talks on the state of X [LWN.net]

LCA: Two talks on the state of X

Posted Feb 8, 2008 22:15 UTC (Fri) by tjc (subscriber, #137)
Parent article: LCA: Two talks on the state of X

A question that I've been asking for years: are there any plans to allow window managers to
intercept client requests to raise themselves?

I find it really obnoxious when Firefox, for example, is raised to the top of the stack over
whatever I happen to be working on just because a page finally loaded.  It would be really
nice if the window manger could intercept this request and do something a bit less rude, like
maybe place the window second from top.

(Log in to post comments)

LCA: Two talks on the state of X

Posted Feb 8, 2008 23:01 UTC (Fri) by tjc (subscriber, #137) [Link]

In this particular case it is a Firefox issue, but I guess the point I'm raising is that if
the window manager can't intercept an attempt to raise a window (or grab the focus), then
there will probably always be badly behaved apps that do this.  Relying on apps to do the
right thing seems futile.

LCA: Two talks on the state of X

Posted Feb 9, 2008 16:40 UTC (Sat) by rsidd (subscriber, #2582) [Link]

If it is a firefox issue, here's what you do (and what I do): Edit -> Preferences -> Content
-> Enable Javascript "advanced" button -> uncheck "Allow scripts to raise or lower windows".

LCA: Two talks on the state of X

Posted Feb 9, 2008 16:43 UTC (Sat) by rsidd (subscriber, #2582) [Link]

Got to add though: it would be very nice to see the window manager implement "raise windows only to top of stack of windows for that application". So the Firefox window will be the topmost firefox window and you will see it on top if you're already focussed on firefox, but not if you're focussed on an xterm or something else.

LCA: Two talks on the state of X

Posted Feb 9, 2008 20:30 UTC (Sat) by tjc (subscriber, #137) [Link]

> it would be very nice to see the window manager implement "raise windows only to top of
stack of windows for that application".

I think sawfish does something like this?

The Firefox problem seems to have been fixed, if only recently.  I booted to a new install of
Ubuntu 7.10, and Firefox 2.0.0.12 doesn't raise itself on page loads anymore.  It still maps
new windows over the top of the currently focused window, but it's a start anyway.

LCA: Two talks on the state of X

Posted Feb 9, 2008 1:19 UTC (Sat) by njs (guest, #40338) [Link]

> are there any plans to allow window managers to intercept client requests to raise
themselves?

Window managers have always had that capability -- in fact, the *only* thing a client can do
is ask the window manager to raise it; the window manager is the only app capable of actually
issuing the raise operation on the server.  You may want to take this up with the authors of
your window manager, or of firefox.

Focus-stealing is another issue -- any client can assign keyboard focus to any window at any
moment, and the most a window manager can do is notice that it has happened and set it back
again, possibly after some keystrokes have been lost.  It'd be nice if this could be disabled,
but it's not clear it can be, given the quirks of X's focus API.  (Modern apps use a very
small subset of X's traditional focus model, but then there are the legacy apps...)

LCA: Two talks on the state of X

Posted Feb 9, 2008 20:39 UTC (Sat) by tjc (subscriber, #137) [Link]

Thanks for the information.  It seems clear that I have been mistaking window raising for
focus stealing.

When a client steals the focus, is the window manager notified, or does it have to keep
polling to notice this?

LCA: Two talks on the state of X

Posted Feb 9, 2008 22:20 UTC (Sat) by njs (guest, #40338) [Link]

> When a client steals the focus, is the window manager notified, or does it have to keep
polling to notice this?

It is notified.

LCA: Two talks on the state of X

Posted Feb 14, 2008 13:51 UTC (Thu) by kaol (subscriber, #2346) [Link]

Firefox really doesn't raise itself, but it sends an extended window manager hint (EWMH for
short) and it's up to the window manager to decide what to do with the event.  There's nothing
to be intercepted there, but you should instead check your window manager's settings.

I use fvwm myself, where doing "DestroyFunc EWMHActivateWindowFunc" in the config file was
enough to make Firefox behave.  I did "DestroyFunc UrgencyFunc" too, for good measure. I can't
remember now if that had any further effect.

LCA: Two talks on the state of X

Posted Feb 14, 2008 18:46 UTC (Thu) by spitzak (guest, #4593) [Link]

Actually the "raise this window" is intercepted by the window manager. There is a method to
force the input focus to a window, but I don't think any modern programs use that, and no
program can rely on it, as many window managers change it on any mouse movement.

What I want to see is the reverse: I want the window manager to tell the program that it is
attempting to raise/resize/hide/etc the window and let the program do whatever it wants.

In particular the program can decide *not* to raise the window, or raise any child windows
above it. This would eliminate the big mess of transient-for type hints, and would finally
allow floating windows/palettes above more than one main window. And it would allow a program
to not raise itself when you just try to move the insertion cursor or hit a button, but still
raise itself when you click in the empty area.

Also if programs could directly resize the windows and draw immediately then it would
eliminate the still-horrible resize behavior of X. The composite extension does *not* fix
this. In addition programs could implement arbitrarily complex restrictions on the resize and
position.

LCA: Two talks on the state of X

Posted Feb 15, 2008 2:32 UTC (Fri) by RobertBrockway (guest, #48927) [Link]

Hi tjc.  That's beautifully put.

I don't know why it is taking so long for a very simple idea to get understood: "Interrupting
a user by shifting the window focus without their consent is a bad idea because it breaks' the
user's concentration".