Re: No focus on map hint
- From: Lubos Lunak <l lunak suse cz>
- To: wm-spec-list gnome org
- Subject: Re: No focus on map hint
- Date: Fri, 28 Mar 2003 19:19:48 +0100
On Monday 17 of March 2003 19:50, Lubos Lunak wrote:
> On Monday 17 of March 2003 17:29, Havoc Pennington wrote:
> > On Mon, Mar 17, 2003 at 10:05:27AM +0100, Lubos Lunak wrote:
> > > Because startup notification right now doesn't have any data providing
> > > the timestamp (ID is some unique random unspecified string). But since
> > > this mechanism for not focusing newly mapped windows is very similar to
> > > startup notification, perhaps this mechanism should become part of it
> > > rather than part of the WM spec?
> > Could certainly add the timestamp to the list of properties on a
> > startup notification launch, also.
> But that would mean there would be two way of specifying the timestamp,
> either the app would set the property (IM not wanting its window to get
> focused), or the WM would set it from the startup notification info. I
> think it would be better to have only one way (and I think apps creating
> new startup notification sequence for newly mapped window isn't the
Ok, I thought about this a bit more, and I think it should be done just like
the start-on-desktop feature of startup notification. There will be
_NET_WM_MAP_TIMESTAMP just like there is _NET_WM_DESKTOP. Startup
notification will have TIMESTAMP just like it has DESKTOP. If the app will
want to use a timestamp, it will set the property before mapping the window.
If the timestamp will come from starting up the application, it will be part
of the startup notification info. There will be no environment variable for
setting the timestamp. The window manager will prefer the timestamp property
over the startup notification info. Applications will remember latest
timestamp from KeyPress/KeyRelease/MousePress/MouseRelease events, and set it
on newly mapped windows (they'll set it only after first such event).
This is because
- the env.var. for the timestamp would cause trouble with apps that wouldn't
unset it, e.g. after starting xterm, apps started from it would have old
timestamp. Since startup notification is sooner or later terminated, it
doesn't have this problem (or it's at least very minimal).
- on the other hand, I suppose using startup notification for just "don't give
this window initially focus" is a bit too complicated
- it works for me already with start-on-desktop in KDE :) , but if you have a
better idea, let's hear it
I.e. the property definition would be like this, based on initial proposal by
Rob (I added only the part about clients):
--- wm-spec.sgml 2003-03-02 23:16:40.000000000 -0800
+++ wm-spec.sgml.no_focus 2003-03-14 09:20:07.000000000 -0800
@@ -1205,6 +1205,33 @@ _NET_WM_HANDLED_ICONS
for iconified windows.
+Read by the window manager when the window is mapped. If the property
+is set to a non-zero value TIME, the application is declaring that the
+window was mapped due to a user action at server timestamp TIME. If
+set to a zero value the window was mapped for some other reason
+(i.e. not caused by the user directly).
+Rationale: This property allows a Window Manager to alter the focus,
+stacking, and/or placement behavior of windows when they are first
+mapped depending on whether the new window was created by a user
+action or is a "pop-up" window activated by a timer or some other
+Clients should keep the last timestamp from events KeyPress, KeyRelease,
+ButtonPress and ButtonRelease and set this timestamp in this property on
+every new toplevel window before mapping it. They should start setting the
+property only after first receiving a KeyPress, KeyRelease, ButtonPress or
+ButtonRelease event, they shouldn't set it before receiving first input
<title>Window Manager Protocols</title>
and I suggest adding this to the startup notification doc:
--- startup-notification.txt.sav 2002-10-23 20:05:14.000000000 +0200
+++ startup-notification.txt 2003-03-28 19:08:57.000000000 +0100
@@ -233,6 +233,15 @@ The following keys may be provided optio
property set on window that's being mapped.
This desktop is relative to the screen provided by
the SCREEN key.
+ X server timestamp of the user action that caused this
+ launch. For example window manager that doesn't allow
+ stealing of focus by newly mapped windows while the user
+ works in an application can use this timestamp for windows
+ that have matching _NET_STARTUP_ID property if they don't
+ have any _NET_WM_MAP_TIMESTAMP property set.
> That would mean setting the timestamp would be different from the desktop.
> Hmms. I think I'll have to think about this a bit more.
> > > BTW, I can't see the startup notification spec anywhere at
> > > www.freedesktop.org, could you put the newest version there?
> > I've been meaning to, it's just never been moved to the web site.
> > It's in CVS under startup-notification/doc/
So you don't mind if I add it to the web site ? :)
SuSE CR, s.r.o. e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
] [Thread Prev