Re: No focus on map hint

[Lubos Lunak <l lunak suse cz>]

 Ok, a TODO item in my list is getting quite near the top, so let me ask 
differently: Any objections against commiting this?  >;)

On Friday 28 of March 2003 19:19, Lubos Lunak wrote:
> 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
> > winner).
>
>  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.
>         </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).
> +       </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>
> +       <para>
> +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
> +event.
> +       </para>
> +    </sect2>
>  </sect1>
>  <sect1>
>         <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.
> +
> +  TIMESTAMP
> +
> +          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.
>
>    DESCRIPTION
> *****
>
> >  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 ? :)

-- 
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/