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

[Lubos Lunak <l lunak suse cz>]

 Sorry for the delay. But /. now says SUSE9.2 is done, so it must be true, and 
I'll have enough time for this.

On Tuesday 14 of September 2004 21:56, Elijah Newren wrote:
> On Wed, 8 Sep 2004 11:06:36 +0200, Lubos Lunak <l lunak suse cz> wrote:
> According to the doc/startup-notification.txt file in the
> startup-notification module in freedesktop.org's cvs, the
> _NET_STARTUP_ID property is "The ID used for the startup sequence for
> the window. If set on a group leader window, applies to all
> application windows in that group that do not set their own
> _NET_STARTUP_ID."  It also states that DESKTOP_STARTUP_ID is the
> "value of the "ID" field in the "new" message".  The two things that I
> understand from that are (1) DESKTOP_STARTUP_ID and _NET_STARTUP_ID
> have the same value, and (2) _NET_STARTUP_ID typically (always?)
> applies to all windows of an application instance.
>
> So, here's the problem.  I assume that _NET_STARTUP_ID is an older
> standard than _NET_WM_USER_TIME.  So, there may be toolkits which
> support _NET_STARTUP_ID (and which set it by reading
> DESKTOP_STARTUP_ID), but which don't support _NET_WM_USER_TIME.
> Fairly recent versions of gtk+ are like this and there may be others.
> Applications using such toolkits will have no _NET_WM_USER_TIME set
> for their windows, but will effectively be gaining a
> startup-notification TIMESTAMP if your proposal is used--and not just
> for the first window of the application instance but for all of them.
> Unfortunately, the timestamp from the _NET_STARTUP_ID used will be
> wrong for all windows except the first and would likely result in
> windows not getting focus when they should.

 No, they won't. The timestamp should be used only as long as the startup 
notification is still active. As soon as the applications says it's done 
finishing, the ID becomes invalid. In fact I think your extra environment 
variable is more vulnerable to this kind of problem, because there's no such 
timeout or similar if an application doesn't unset it and it gets propagated.

 So, in case you don't see any other problem with this, I'll commit this 
change, ok ?

> > > >  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 don't fully understand this, but it sounds like we could end up with
> > > indefinite queueing.  Is there anything that prevents that?
> >
> >  I have timeout in clients that cleans up information about too old
> > startup sequences. It's needed anyway for cases like unexpected crashes
> > or so.
>
> Perhaps it should be explicitly mentioned in the spec that timeouts
> are allowed (and needed) for the clueless people like me that wouldn't
> find that obvious?

 Better now (attachment) ?

>
> > That said, after thinking about it it's possible I'm trying to twist the
> > spec to match my API. As I said above, the problem is that the launching
> > in KDE is usually done by a special daemon (because of kdeinit and other
> > reasons). So if an application wants to launch something, it gives the
> > command to the daemon, and the daemon takes care of finding the binary,
> > checking if there should be startup notification and so on. But the
> > application may want to include some of its data in the startup
> > notification, most notably the timestamp, but it could possibly also want
> > a special DESCRIPTION or whatever. And with the current spec, this
> > information can be only sent in "new:" message or after it, but not
> > before, which means it has to be the daemon sending it.
>
> Is it difficult to pass this information to the daemon?  I'm guessing
> that maybe it is since you proposed this change, but I'm just curious.

 It is perhaps not that difficult, but I'm lazy too ;). The problem is 
basically that currently the related API is like "launch_something( what, 
startup_id )". Now, say the application doing the launch wants to specify a 
different DESCRIPTION or any other field. Without this, the API would have to 
be "launch_something( what, startup_id, ... )", where the "..." part is some 
way of passing all the possible information to the launching code (probably 
something ugly like a stringlist in a specific format or similar). The 
application cannot send it after launch_something() returns, because that may 
be too late, and can't set it before, because maybe there shouldn't be 
actually any launch feedback, but "new:" would be necessary to send any data.

 Maybe it's not the best way of solving it. Maybe the app could send it with 
SILENT=1 and launch_something would undo that. Or whatever. BTW, while I can 
see the support for this in KDE, I can't actually find code using it, so I 
wonder if I actually have eventually used this. Still, there perhaps should 
be a way to do this.

>
> >  That's why I'd want "change:" messages remembered and applied even if
> > they come before "new:", because this way the application can create the
> > startup id, send whatever data it wants, without actually causing any
> > launch feedback, and then it passes the startup id to the daemon, which
> > decides if there actually will be any launch feedback and so on. This way
> > I can pass around only the startup id instead of all the possible data.
> >
> >  Does that make any sense?
>
> In the abstract, but I still don't know the details of how this part
> of the spec works--but that's more just because I don't fully
> understand the spec without this change than due to this specific
> change.  Particular things I'm wondering about this change have to do
> with me being lazy.  I.e., How much will Gnome applications/libraries
> (gnome-desktop?, nautilus?, gnome-panel?, metacity?, others?) be
> affected by this change and how much?

 Applications: Not at all, unless they use it. Even then a piece of cake.
 Libraries: Code collecting the messages would need to be extended to 
temporarily remember "change:" messages that don't have matching "new:".

 That's of course assuming we don't find a better way nor say it's not 
necessary.

> Would a modification of your 
> proposal from "should remember" to "may remember" for information sent
> before the first new message would cause any incompatibility problems?

 That'd mean loosing some sent data.

>
>
> Thanks for the patience with the newbie-ish questions,

 No problem. Specs are supposed to be complicated and not understandable, 
otherwise people wouldn't find them worth using ;)).

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

--- startup-notification.txt.sav	2003-12-16 19:28:00.000000000 +0100
+++ startup-notification.txt	2004-10-08 16:10:40.561634025 +0200
@@ -180,14 +180,25 @@ 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. "change:" messages without
+          a following "new:" message can be discarded after a reasonable
+          timeout (>= 1 minute). 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