DESKTOP_STARTUP_TIMESTAMP proposal (application-startup-notification-forwarding)

[Elijah P Newren <newren math utah edu>]

Hi,

There are a number of apps (e.g. mozilla, konqueror, gnome-terminal)
which, when launched, request a previously running instance to open a
new window instead of mapping a window themselves.  In these cases,
focus-stealing-prevention is failing because the previously running
instance does not have the TIMESTAMP that the new instance was launched
with in order to set the _NET_WM_USER_TIME for the window that it [the
older instance] opens.  In order to fix this situation, I have a simple
proposal (attached as a diff to startup-notification/doc/startup-
notification.txt) that will allow the newer instance to forward the
value of its TIMESTAMP to the older instance.

A brief explanation of the idea and rationale for this method:
  1) Basic idea: The previous method of sending a TIMESTAMP message is
     retained; an environment variable called DESKTOP_STARTUP_TIMESTAMP
     which is set to the same value as TIMESTAMP is added.
  2) The current spec isn't sufficient because the TIMESTAMP can't
     currently be obtained by the launched application (because it is
     sent in X messages before the app is launched).
  3) Having the launch timestamp in an environment variable makes it
     easy to access for those applications which need it; it is also
     similar to the DESKTOP_STARTUP_ID method we already use.
  4) This requires minimal changes to startup-notification launchers and
     launchees; most apps will be able to ignore the new environment
     variable altogether (other than perhaps unsetting it) since they do
     not need the extra information provided.
  5) This method is backward compatible with previous startup
     notification launchers, thus allowing launchees to easily tell
     whether the launcher supports this newer spec or not.

Thoughts, comments, suggestions?

I have a set of proof-of-concept patches demonstrating the use of this
proposal to make gnome-terminal (I haven't yet patched any other apps)
forward the startup-notification timestamp.  These patches are at
http://bugzilla.gnome.org/show_bug.cgi?id=151245.  (Note that the
patches, um, suffer from some coding style issues, as pointed out by
Havoc.  So I'll need to add a startup_notification_timestamp_set flag)

-- 
Elijah Newren
http://www.math.utah.edu/~newren

Index: startup-notification.txt
===================================================================
RCS file: /cvs/startup-notification/startup-notification/doc/startup-notification.txt,v
retrieving revision 1.7
diff -u -r1.7 startup-notification.txt
--- startup-notification.txt	16 Dec 2003 18:29:01 -0000	1.7
+++ startup-notification.txt	30 Aug 2004 16:24:33 -0000
@@ -297,19 +297,22 @@
 ===
 
 To communicate the startup sequence information from a launcher
-process to a launchee process, when possible an environment variable
-should be used:
+process to a launchee process, when possible a pair of environment
+variables should be used:
 
  DESKTOP_STARTUP_ID
    value of the "ID" field in the "new" message
 
-It is suggested to unset this environment variable in the launchee
-as soon as it's read, to avoid possible reuse by some process started
-later by launchee.
-Mechanisms other than the environment variable may be used as well, as
-long as they are reliable. The environment variable is only used when
+ DESKTOP_STARTUP_TIMESTAMP
+   value of the "TIMESTAMP" field in a "new" or "changed" message
+
+It is suggested to unset these environment variables in the launchee
+as soon as they are read, to avoid possible reuse by some process
+started later by launchee.
+Mechanisms other than the environment variables may be used as well, as
+long as they are reliable. The environment variables are only used when
 the launchee code is in a process started by the launcher code; if
-they are in the same process the environment variable may not be
+they are in the same process the environment variables may not be
 relevant.
 
 Desktop entry spec extensions