Re: No focus on map hint II.

[Lubos Lunak <l lunak suse cz>]

On Thursday 15 of May 2003 15:38, Lubos Lunak wrote:
[snip]
>
>  First, the hint that started this all. The only thing I added when
> compared to the last proposal is that clients should also update the user
> time in the hint in the visible window, so that the WM is able to detect
> last user activity in the window if key events don't propagate up to the
> frame. I also think the name MAP_TIMESTAMP no longer fits, so I suggest
> _NET_WM_USER_TIME as the name of the property.
>
> The patch is attached as user_time.txt . I'd like this one to get in the
> spec. (I added the note about CARDINAL[] because I use it in code, and it
> would break code that would strictly request the property to contain only
> one CARDINAL value - any complaints about that?).

 Could somebody please say something about this specific part? Qt needs to be 
patches for this, and since it involves some kind of new API, it needs to get 
in before Qt-3.2 final, otherwise they probably won't accept it before 3.3.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
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/

--- wm-spec.sgml.sav	2003-01-03 21:31:14.000000000 +0100
+++ wm-spec.sgml	2003-05-15 14:42:30.000000000 +0200
@@ -1205,6 +1205,41 @@ _NET_WM_HANDLED_ICONS
 	for iconified windows. 
 	</para>
     </sect2>
+       <sect2><title>_NET_WM_USER_TIME</title>
+       <programlisting><![CDATA[
+_NET_WM_USER_TIME CARDINAL[]/32
+]]></programlisting>
+        <para>
+This property contains the XServer time at which last user activity in this
+window took place.
+        </para>
+        <para>
+Clients should keep the last timestamp from events KeyPress, 
+ButtonPress and ButtonRelease (not KeyRelease, as the client may possibly
+get events for modifier key releases for some global actions), 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,
+ButtonPress or ButtonRelease event, they shouldn't set it before receiving first input 
+event. If the client has the active window, it should also update this
+property on the window whenever there's user activity. The special value of zero
+on a newly mapped window means that the window shouldn't initially get focus
+after being mapped.
+        </para>
+        <para>
+Rationale: This property allows a Window Manager to alter the focus,
+stacking, and/or placement behavior of windows when they are
+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
+event.
+        </para>
+        <para>
+Note: The property is specified as CARDINAL[] in order to simplify implementation
+in toolkits - always only the first element should be read. The toolkit can always
+use PropModeAppend to set the property, which will set the property if it's not
+set yet, but won't overwrite any previous value set before in the application.
+In such case, the toolkit should remove the property after the window is withdrawn.
+        </para>
+    </sect2>
 </sect1>
 <sect1>
 	<title>Window Manager Protocols</title>