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

[Luke Schierer <lschiere users sf net>]

On Wed, May 25, 2005 at 01:37:07PM -0700, Rob Adams wrote:
> The EWMH doesn't impose any policy.  Each window manager uses the
> information from the hints to direct focus policy.  Though I believe
> that all the window managers implementing this part of the spec have
> chosen similar policies.
> 
> Gaim was specifically considered in the formulation of the metacity
> policy.  Indeed, gaim is one of the primary reasons for the development
> of the specification: gaim popup conversations are a severe security
> risk.  What other application has the potential to so easily result in
> the accidental transmission of a password over the internet unencrypted?

perhaps none.  Still, it is interesting to note that for quite some
time, only metacity and windows users complain about gaim's creation
of new windows.  It is also significant to note that on windows at
least, the complaint is not limited to gaim, but to instant messaging
applications in general.  I mention this as significant because I,
biased though I am, do not consider any other instant messaging
program on linux to be particularly significant, and thus to have the
volume of complaints that gaim generates.  Thus gaim *seemingly*
stands alone, but only because it is the sole program in a class of
programs that gnome really sees.

> 
> My suggestion is that if you think that the notification for new gaim
> messages is insufficiently obvious, that you make suggestions for
> improving support for DEMANDS_ATTENTION in the wnck panel applets
> (Currently, the window is shown in bold in the window list).  Perhaps a
> notification icon could be used, or something similar.

gaim currently supports urgency from the ICCCM spec.  you all choose
not to implement that for some inexplicable reason (it *seems* to
boil down to one or two developers reading that spec in a way no one
who has implemented it reads it).  But I address this in my bulleted
points.  Did you read them?

I *know* from interacting with warren that this will result in many
many bug reports about loosing windows, not seeing password prompts,
new messages, so on.  I am perfectly willing to continue my age old
policy of saying "metacity is broken."  I've been saying that for
pretty much all of metacity's existence, it wouldn't hurt me or gaim
to continue doing so.  I thought that it would be appropriate though,
since you all *have* looked at this issue, to let you know that your
solution is less than optimal, and really won't change our responce
to this sort of bug.

My suggestions were outlined in the bulleted points.  Was I wrong in some way?  Is
there some point I made that you disagree with?

> 
> But, really, it all works perfectly for gaim as it is without any code
> changes, since gaim uses gtk+, which automatically supports the hint.

I disagree.  As gaim stands, windows get lost, unless you happen to
see them in the task bar.  We have to make changes to make it "work
perfectly,"  changes that would not be needed if you simply
implemented urgency.

> GAIM need not do anything with DEMANDS_ATTENTION -- this hint is managed
> by the window manager and an application need not concern itself with
> this hint.  The only case where an application needs to worry about any
> of this is when it launches new windows by communication out-of-process.

again, demonstratably false.  For example, see redhat bugs 157270 and
157271.  These bugs are going to stay around for quite some time if
gaim "need not do anything." And others will be marked duplicate of
them.  I predict there will be quite a few marked duplicate, do you
disagree?

luke

> 
> -Rob
> 
> On Wed, 2005-05-25 at 15:54 -0400, Luke Schierer wrote:
> > Hi,
> > I am one of the gaim developers, and am writing this list at the
> > prompting of Warren, our RedHat packager.
> > 
> > Warren notified us of the change to focus policy that gnome/metacity
> > has implemented, and I am happy to learn that efforts are finally
> > underway to address this significant issue.
> > 
> > We (gaim developers) were, however, dismayed to learn what direction
> > these efforts had taken.  Our reaction, detailed at great length in
> > #gaim on irc.freenode.net, has been compiled into
> > http://gaim.sourceforge.net/luke/windowstuff which I include here.
> > 
> > While specs are a wonderful thing, it is not good to attempt to
> > re-invent the entire interaction between window managers/other
> > aspects of a desktop environment and applications in place of the
> > existing ICCCM spec.
> > 
> > Hopefully you all will find some of our points/ideas/statements
> > useful, and will come up with something better than either the
> > existing behavior or the new, arguably worse behavior (short of
> > rewriting all existing legacy X applications that might create a
> > window).
> > 
> > Luke Schierer
> > Gaim Support
> > 
> > * 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.
> > 	* 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.  quoting Etan:
> > 		  "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 windows.
> > 
> > 		  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.
> > 	* 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.
> > * 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.
> > * 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.
> >   * _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.
> > 
> > _______________________________________________
> > wm-spec-list mailing list
> > wm-spec-list gnome org
> > http://mail.gnome.org/mailman/listinfo/wm-spec-list
> > 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>