On Thu, May 26, 2005 at 09:32:09AM -0400, Havoc Pennington wrote: > Hi, > > Not to pile on late, I want to be sure we keep focus on: > > http://bugzilla.gnome.org/show_bug.cgi?id=120439 > http://cvs.gnome.org/viewcvs/metacity/doc/how-to-get-focus-right.txt?view=markup > > On Wed, 2005-05-25 at 15:54 -0400, Luke Schierer wrote: > > * window focus should only be transfered from one window to another by the > > direct action of the user. > > * The WM does not know when a new window is user initiated or not. > > * The application that requests the new window does know > > What the app doesn't know is that there may have been *more recent* > focus transfers in other apps or in the WM itself. Basically > how-to-get-focus-right.txt is more complicated than this.
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. > > 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. > > > * In the case of new application launch, this yields a useful result: > > you can start several things > > in the background (or on login) and not have your focus jerked around > > as they start. > > You're assuming a "never focus new windows" policy here. I also take it > that metacity focusing new windows is why you think metacity was > historically broken (prior to "focus stealing prevention") and why you > think Windows is broken. I guess you're entitled to that view, but > really it is a desktop environment decision and not an app decision. > The specs are designed to allow the desktop environment to make either > decision it wants, or to delegate the decision to users. Yes, I think that always focusing new windows, while perhaps a choice the spec allows, is necessarily broken behavior. Really though, I mentioned windows only to introduce the reality that gaim is not the only application that has this "huge security risk" of typing in the wrong window, its common to most instant messangers. One assumption that I *am* making is nicely highlighted by the how-to-get-focus-right.txt though, I was not considering anything other than click to focus, because I have been consistently annoyed by the inconsistencies discussed in the "Addendum on sloppy and mouse focus." Still, I know other gaim developers use those focus models, so as I was not the sole author of the points list, merely the person who compiled it from points other developers raised, I do not think my bias heavily affects other focus modes beyond the compromises that Addendum already discusses. > > > * While it is acceptable to design a specification by which an > > application which does not currently > > have focus can request it either by creation of a new window, or for > > an existing window, such > > a specification should be an opt-in policy. > > Desktop environments are free to make this decision balancing the merits > of popping under too many things vs. stealing focus too often. It's a > desktop policy decision. The spec allows desktops to go either way and > so blaming the spec is wrong here. Redhat bug 157271 and gnome bug 305499 demonstrate fairly well why I think that the pop under policy is the wrong balance to strike, I think that in an attempt to fix the few cases where an application can end up with focus unexpectedly, too much effort has been made to protect the user. To the extent that this effort is spec mandated, it belongs on this list, to the extent that its a choice, it doubtlessly belongs in other forums. I chose this list because, not familiar with the gnome lists at all, I was pointed to it as being the appropriate place. (some of this is in response to other emails which say that this thread is off topic) Also, to the extent that 305499 is *fixable* and is, in fact, fixed, that is, to the extent that is possible to draw the users' attention to a window they cannot see, then this balance becomes more reasonable, but I think its still less than ideal. The transparency option was an intriguing one though, that would allow for a far more ideal balance. But that is *certainly* an implementation question, not a spec question. > > > * new windows should be created at the top level unless specifically > > requested otherwise by the starting > > application. Placement should reflect some overall policy of the WM, > > preferably a policy that the > > user understands and can predict. Remembering previous placement is a > > reasonable, but not required, > > part of said policy. > > * Window stacking and focus policy should be at least somewhat > > decoupled. > > * 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. > > These are desktop policy and quality-of-implementation issues, they > aren't in the spec on purpose. fair enough. I disagree some, it seems that the spec should ban choices that will never be good, but most window managers do a decent enough job with the existing specs and their own developer's intuition to guide them. 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. > > > * Applications which currently have focus should be able to hint if a > > window said application has > > created gets focus or not. It should be able to do so without changing > > the level at which the window > > is created (assuming the hint is followed). > > * While it may be valuable to specify or further specify how this > > should be done, _NET_WM_USER_TIME > > in it's current overloaded state does not seem to us to be a viable > > solution for this. We would > > suggest something like a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property. > > You can set _NET_WM_USER_TIME to 0 to indicate that the window > definitely should *not* be focused, if the window is not the result of > user interaction. > > Otherwise, you need to give a specific scenario where _NET_WM_USER_TIME > produces a result in conflict with the intended desktop environment > policy. We can then address that scenario. > > > * Applications which do not have focus should not be able to pull focus > > from another application in a > > way that the user cannot disable or modify. > > 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? luke > > > Changes to individual applications at a source code > > level should not be necessary for this behavior. > > * _NET_WM_STATE_DEMANDS_ATTENTION may have merit here if used to indicate > > that a window which requests > > focus was not given in so as to comply with the WM's policies on focus. > > * Window managers and and applications should both support both the ICCCM > > and fd.o specs > > * That being said, ICCCM has been a specification since 1993, and (for > > example) gnome should be > > supporting urgency before they get too upset about us not supporting > > _NET_WM_STATE_DEMANDS_ATTENTION. Further, we undertake to implement > > support for this after > > Gnome supports urgency. > > Urgency is completely trivial to add support for, far more trivial than > the difficulty of this argument on wm-spec-list, or you guys' previous > discussions. ;-) > > Applying the patch in > http://bugzilla.gnome.org/show_bug.cgi?id=120439 > is trivial too. > > So, someone should just code this up. > > Havoc > > > _______________________________________________ > wm-spec-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/wm-spec-list > _______________________________________________ wm-spec-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/wm-spec-list
