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

[Luke Schierer <lschiere users sf net>]

On Wed, May 25, 2005 at 03:26:18PM -0600, Elijah Newren wrote:
> On 5/25/05, Luke Schierer <lschiere users sf net> wrote:
> 
> <snip>
> 
> > 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.
> 
> How exactly would that help?  If all we did for the urgent hint was
> make the taskbar bold, then, considering that is what we do when a new
> window doesn't get focus, the users would still be losing windows
> according to your experience.  Right?  So, the bug is that our
> implementation of DEMAND_ATTENTION is suboptimal.

yes and no.  We set urgency when we deam the window needs attention.
this is a subset of possible new windows.  *ideally* then urgency
would be slightly different, *more* prominent from DEMAND_ATTENTION,
which happens for all windows.  I'm on thin ice here, as *my*
understanding of the specs involved is *certainly* suboptional.
hence I didn't write much of that list, I just copied and pasted it
from the relevent irc discussions and the follow-up thread in our
mailing list.

> 
> > > 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?
> 
> Personally, I don't think either of those bugs should be filed against
> gaim and I'm pretty sure that gaim really need not do anything (other
> than perhaps actually filing bugs that we might see with details about
> what's wrong/right).  Warren's comments in bug 157270 show that he
> doesn't understand the situation in general, but specifically didn't
> realize that it is possible to notify people that a window has been
> opened without focusing it and sticking it on top.  The bug isn't that
> we need to revert behavior; it's that we need to implement a decent
> way of notifying people about new windows so that they'll notice it.

Warren views, as do I, the new behavior, pop under, to be worse than
the old behavior, stealing focus.  *ideally* neither would happen.
But that would require that you be able to create windows at the top
level without giving them focus.  for some reason, that was deamed to
"demonstrate a lack of understanding of the specification." or
perhaps that part was simply "misinformed."  Either way, 

* 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.

still seems to document the ideal behavior for a new window that does not
get focus.  Of course, if you did this, then you wouldn't need
DEMANDS_ATTENTION, as I understand it, but that is a side point.

luke


> 
> 
> Hope this helps,
> Elijah
>