Re: No focus on map hint

[Rob Adams <robadams ucla edu>]

Windows that don't want focus at all can indicate that already in
another hint.  This hint is really just for pop-up windows to say "I'm
not that important that I should steal focus".

Here is a patch the encorporates I think the current consensus on how
this hint ought to work:

--- wm-spec.sgml	2003-03-02 23:16:40.000000000 -0800
+++ wm-spec.sgml.no_focus	2003-03-14 16:27:00.000000000 -0800
@@ -1205,6 +1205,42 @@ _NET_WM_HANDLED_ICONS
 	for iconified windows. 
 	</para>
     </sect2>
+	<sect2><title>_NET_WM_MAP_TIMESTAMP</title>
+	<programlisting><![CDATA[
+_NET_WM_MAP_TIMESTAMP CARDINAL/32
+]]></programlisting>
+	<para>
+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).  Is the propertly is not set,
+the Window Manager should assume that the client required normal
+mapping semantics.
+	</para>
+	<para>
+When launching an application, the DESKTOP_LAUNCH_TIMESTAMP
+environment variable MAY be set to the timestamp of the user action
+causing the launch. Applications may choose to honor this environment
+variable by setting _NET_WM_MAP_TIMESTAMP to its
+contents. Applications SHOULD unset the environment variable after
+using it, to avoid transmitting it to their child processes.
+	</para>
+	<para>
+Application wishing to have normal mapping semantics, but for which it
+is not practical to determine a time stamp for the user action that
+caused the window to be created (either because not
+DESKTOP_LAUNCH_TIMESTAMP is set or some other reason), MUST NOT set
+this property.
+	</para>
+	<para>
+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
+event.
+	</para>
+    </sect2>
 </sect1>
 <sect1>
 	<title>Window Manager Protocols</title>


On Fri, 2003-03-14 at 16:24, Ben Jansens wrote:
> On Fri, Mar 14, 2003 at 06:01:07PM -0500, Havoc Pennington wrote:
> > On Fri, Mar 14, 2003 at 10:33:25PM +0100, Matthias Clasen wrote:
> > > On Fri, 2003-03-14 at 17:35, Havoc Pennington wrote:
> > > > You have to be able to "focus" all windows in the WM, whatever the
> > > > input hint is set to. Otherwise you can't keyboard navigate some apps
> > > > (e.g. xclock).
> > > 
> > > There isn't much to keynav around in xclock...
> > 
> > There is though. How do you close/move/resize the window without
> > focusing it? Most window managers require you to focus the window,
> > then use other keybindings to invoke the close/move/resize operation.
> 
> With the mouse? When an app doesnt request keyboard input, its going to be
> something that sits out of the way, like.. xclock, which you don't want to
> end up alt-tabbing to. That would just get in the way.
> 
> > > > Aside from keynav, it just looks like a bug to users if they click a
> > > > window and it doesn't become active, or they open xclock and it isn't
> > > > initially focused.
> > > 
> > > But isn't this exactly what the proposal is about ? A way to avoid
> > > giving focus to newly mapped windows ? 
> > 
> > But xclock *should* be focused. It sets the input hint just to mean
> > "I'm not going to do anything with key events," which is different
> > from "I should not be focused on map" or "I should not be focused
> > ever"
> 
> This all is just one interpretation/implementation of the ICCCM. And I
> disagree with it strongly.
> 
> Adding hints to the WM Spec for this type of thing (using environment
> variables!? will we disallow running applications on other boxes next?)
> makes me want to scream "bloat!".
> 
> Ben