I have updated my master copy of these ideas at
to reflect the ideas I have seen presented in this thread. If no
further objections, clarifications, or enhancements are made by
tomorrow morning (EDT), I will pass this on to Warren as per his
request (which started this thread).
On Mon, May 16, 2005 at 02:46:37PM -0400, Etan Reisner wrote:
> On Wed, 11 May 2005, 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
> > * 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.
> I agree. If, however, people feel that there should be a way for an
> application to request focus on mapping that's fine. Such a
> specification should be written such that it is an opt-in concept, not
> an opt-out one (or one that requires all applications to follow for it
> to work). For example, given our experience with metacity (and the focus
> stealing prevention spec) the fact that gaim does not do anything to
> accomodate the spec used to cause all of our windows to be on top and
> focused, and now causes all our windows to be popped up underneath other
> This is really an unacceptable way to design a new specification,
> especially when dealing with something as old as X and which has legacy
> applications which one wants to continue to have act correctly. If the
> purpose of this spec is to only make windows that really want focus on
> map to get it than require that *those applications* set the property
> to some agreed upon value or set of values, and that anything which
> does not is going to be treated in a wm consistent and non-annoying
> fashion (i.e. not given focus on map, but also not hidden and therefore
> requiring further specification to function usefully).
> > * 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.
> I mostly agree with this, however I can certainly imagine the case where
> a wm which supports absolute Z-levels would want to group windows by
> class, instance, or other criteria and as such I can certainly accept
> the idea that a wm would have a policy which doesn't put windows on the
> top level at all times. When the wm put a window in a non-obvious place
> it should then indicate this to the user somehow. (This by the way is
> where I think the _NET_WM_STATE_DEMANDS_ATTENTION stuff has merit, to be
> the property of a window that the wm sets when, according to policy, a
> window was not given the visibility it, or the user, might otherwise
> have been expecting.)
> > * Applications which currently have focus should be able to determine 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.
> I agree 100%. Since I do not know of any currently existing method to
> have an application indicate this to the wm there is certainly room for
> a specification to clarify how this should be done. I do not however
> think that _NET_WM_USER_TIME in it's current overloaded and (to my mind)
> poorly designed state is viable for this. I would suggest something
> along the lines of a _NET_WM_[GET_|TAKE_|REQUEST_]FOCUS property.
> > * 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. Changes to individual applications at a source code
> > level should not be necessary for this behavior.
> I likewise agree 100%. I think that this is again a place where the
> _NET_WM_STATE_DEMANDS_ATTENTION property has merit, it should be used to
> indicate that a window was created or requested focus and was not given
> it to comply with the window managers policies on focus and as such
> attention should be paid to it shortly. (As an example, my window
> manager has a small activity notification bar which appears at the top
> left of the screen when a window is created on a desktop other than the
> one you are currently viewing. It also uses this activity notification
> bar to indicate when a window has set the Urgency hint.
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> Gaim-devel mailing list