On Thu, 2005-05-26 at 10:40 -0400, Luke Schierer wrote: > > The application doesn't know if it has focus *right now* or not? > mmm. I think I see what you are saying. you are envisioning some > application that gets a mouse click on a menu item, and then takes > appreciable time to react to that click in a visible manner. >
Yes, for example. But another thing the app doesn't know is which focus settings the WM is using and what the expected behavior with those settings should be. (Of course, my personal view if writing an OS from scratch is that the whole "separate policy into the WM" thing is sort of wrong, we should hardcode one focus mode and set of focus behaviors and then apps would know what to expect, but even metacity hasn't gone that far since it has to live in a UNIX world. The WM specs certainly continue the ICCCM tradition of leaving policy to the WM. Mac and Windows don't do this though, they sanely hardcode a single behavior.) > > The reason we have to put policy in the desktop rather than apps is that > > good policy requires global knowledge of the open windows and > > desktop-wide settings. > > ... > Redhat bug 157271 and gnome bug 305499 demonstrate fairly well why I > think that the pop under policy is the wrong balance to strike Making the taskbar flash fixes it pretty well though, I think. As those bugs discuss, sure there are other things we could do, but the taskbar flash is going to work for most people. Another thing I'd hardcode if building an OS from scratch: you wouldn't be able to turn off the taskbar/dock/whatever, so apps would know what to expect ;-) and if someone decides to turn off the taskbar my view is that it's their problem - metacity assumes there's a taskbar in its UI design. > I'm reading that cvs page you linked to, and I'm still getting the > impression that Z-level and focus are in fact still coupled in > practice, though they are not inherently so by spec. In metacity yes, we try to maintain that the window on top is always focused - at least in click-to-focus mode. This is a deliberate implementation choice though and is not dictated by the spec. I think the taskbar flashing is better than raising an unfocused window that may then obscure the focus window and be confusing. > > This is unfortunately not fixable in X (the window manager can't > > override SetInputFocus, other than by "fighting" - immediately moving > > the focus somewhere else). > > So then the spec should say something about not abusing that ability, > no? Certainly the ICCCM has things to say about how applications > should behave, not just the window manager, couldn't the > freedesktop.org stuff do the same? It makes sense. I wouldn't be surprised if one of the specs already mentions this, but if they don't, we could remind people. Havoc _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
