Re: _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS & urgency

[Luke Schierer <lschiere users sf net>]

On Wed, May 25, 2005 at 04:34:57PM -0600, Elijah Newren wrote:
> On 5/25/05, Luke Schierer <lschiere users sf net> wrote:
> 
> If a modal window (of the application that previously had focus) is
> denied focus when it appears (e.g. an "unexpected error message"),
> then the usual reasoning of "let the user go on what they were doing
> and interacting with the window they were using" doesn't apply (the
> modal dialog would prevent any such interaction).  Hence, in that case
> the main window is defocused, and the modal dialog is placed on top.

modal windows are a pain.  Still, I think I have clarified this in my
other reply now.

> 
> Another example of decoupling is mouse/sloppy focus, where a window
> can get focus without being raised.
> 
> The only point I think this makes is that the criteria of "at least
> somewhat decoupled" is too vague to be useful.  You had a specific
> idea in mind for it, but the criteria you listed isn't detailed enough
> to support it.
> 
> > > >         * It is acceptable for a window manager's overall focus policy to include some concept of absolute
> > > >           Z-level and restrict an application to a single Z-level.  Such a policy, however, should include
> > > >           some method to notify the user that a new window has been created.
> > >
> > > Um, like DEMANDS_ATTENTION?  ;-)
> > 
> > a DEMANDS_ATTENTION that actually got the user's attention would
> > suffice here yes.
> 
> Yeah, I think we're reaching agreement (I hope) that this is the bug
> we need to addresss, or at least the first one.

yes.

> 
> >  The idea that bullet was attempting to address
> > however was window managers that restrict each application to a
> > single layer, and force you to raise or lower the layer.  *shrugs* as
> 
> I don't quite follow what you mean.  Also, do you mean each
> application, or each window?  (And for legacy apps, can the WM tell
> the difference?)

from ICCCM, each application *should* be setting a WM_CLASS (amoung
other things).  in short, yes, X can tell what windows are one
application, and thus the WM can.  Interestingly, iirc, gnome already
uses this, to collapse task bar items into single instances with a
menu showing each window for that app.

some applications utterly abuse this (WM_CLASS especially), but those
are bugs I'd file with such applications.  Similarly some window
managers depend on WM_CLASS (and related concepts) abuse (notably
WindowMaker), but that also is a bug for someone else.

Basically I'm thinking of things like ION or pwm.  there are window
managers out there that while I consider them entirely useless, some
people like them, they *do* provide logical rules for focus, and
something I intend to refine in our interaction in case this ever
comes up with anyone else, should reflect their existance. you
(gnome) can utterly ignore the Z level stuff, as I think we come to
sufficient agreement here:

there is a bug in gnome's implementation of DEMANDS_ATTENTION (it
doesn't actually alert users), fixing it would satisfy our ideas
on Z level and window placement level.

luke

> 
> > long as the user knows that's what is happening, such behavior would
> > be fine, *so long as the user was notified that there is reason to
> > switch layers*.  however, this is one respect that does not
> > particularly apply to metacity, as its placement is not nearly so
> > logical ;-)
> >
> > of course, having a writeup of how a window manager should behave
> > with points that do not particularly apply to metacity only makes
> > sense if we have users who don't use gnome (its a given that you
> > wouldn't bother for win32 users, who's going to get Microsoft to
> > listen? you *have* to work around its insufficiencies) ;-)
> 
> ;-)
> 
> 
> Cheers,
> Elijah
>