On Wed, May 25, 2005 at 04:34:57PM -0600, Elijah Newren wrote: > On 5/25/05, Luke Schierer <[EMAIL PROTECTED]> 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 > _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
