Re: DESKTOP_STARTUP_TIMESTAMP proposal (application-startup-notification-forwarding)

[Lubos Lunak <l lunak suse cz>]

On Monday 30 August 2004 18:43, Elijah P Newren wrote:
> Hi,
>
> 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'd suggest including the timestamp directly in the ID, as I wanted to 
propose originally (being at conferences seems to cause certain delays in 
processing things :(  ). See the attachment. That would avoid the problem 
with handling yet another environment variable, otherwise it should be in 
practice the same. Additionally as far as I can see GNOME application already 
include the timestamp in the ID, just in a more difficult to parse form, so 
you could have small backwards-compatibility code.

 I'd also like to get in the modification of the 'change:'  behavior, see the 
other patch. I need it because KDE applications often use the KLauncher 
daemon to actually launch the applications. I'd have to change the code to 
forward all the information like user timestamp or description to the daemon, 
with this change the application can simply blindly send the information and 
only after that KLauncher will actually decide if there really will be launch 
feedback or not.

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

-- 
 Lubos Lunak
 KDE Developer

--- startup-notification.txt.sav	2004-09-06 19:40:31.000000000 +0200
+++ startup-notification.txt	2004-09-06 20:29:44.382636960 +0200
@@ -199,6 +199,10 @@ All messages must include these keys:
  
           uniquely identifies a startup sequence; should be some globally 
           unique string (for example, hostname+pid+current time).
+          The string should be in the form of <unique>_TIME<timestamp>,
+          where the timestamp is the X server timestamp of the user
+          action that caused the launch. See the TIMESTAMP key
+          for details.
 
 The following keys are required in a "new" message and may be included
 in either a "new" or a "changed" message:
@@ -244,6 +248,9 @@ The following keys may be provided optio
           have any _NET_WM_USER_TIME property set or if it's older.
           See the description of _NET_WM_USER_TIME in the WM spec
           for details.
+          
+          This key is obsoleted by including the timestamp directly
+          in the ID field.
 
   DESCRIPTION   
 

--- startup-notification.txt.sav	2004-09-06 19:40:31.000000000 +0200
+++ startup-notification.txt	2004-09-06 20:43:13.478635672 +0200
@@ -180,14 +180,23 @@ beginning of the message string, not the
           startup sequence).
           
 
-  change: message updating an existing startup sequence. If a client
-          has not seen a "new:" message for the same sequence, then
-          all "change:" messages should be ignored. i.e. a "change:" 
-          message should not be taken as a "new:" message.
+  change: message changing a startup sequence. Clients should update
+          information about the matching startup sequence to the newly
+          provides information. "change" messages contain
+          a subset of the keys allowed in a "new" message. Not all
+          attributes of the startup sequence are allowed to change
+          over time.
+          
+          "change:" messages not be taken as a "new:" message,
+          i.e. they should not cause any feedback or similar.
+          
+          If a client has not seen a "new:" message for the same sequence,
+          then it should remember the information for later use in case
+          a "new:" message comes later.  Rationale: The application
+          may want to send certain information like timestamp or description
+          first, before handling control to library code deciding
+          if there should be actually any feedback for the launch. 
 
-          "change" messages contain a subset of the keys allowed
-          in a "new" message. Not all attributes of the startup 
-          sequence are allowed to change over time.
 
   remove: message ending a startup sequence. Once this message
           has been seen for a given sequence, any further