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

[Lubos Lunak <l lunak suse cz>]

On Tuesday 07 September 2004 02:22, Elijah Newren wrote:
> Hi,
>
> First, a disclaimer:  I'm still struggling to learn things about how X
> works and how the startup notification spec works.  In fact, I had to
> ask Havoc to explain to me in detail what you meant when you gave the
> brief idea of this proposal in
> http://mail.gnome.org/archives/desktop-devel-list/2004-August/msg00165.html
> (at that time, he didn't see how your method would allow launchee's to
> know if the launcher supported the new ID format or not, so he
> suggested the DESKTOP_STARTUP_TIMESTAMP).  So, if I say anything
> really stupid below, please feel free to clue me in:

 Don't worry. That happens from time to time with X, even to the author of the 
spec ;).

>
> On Mon, 6 Sep 2004 20:47:29 +0200, Lubos Lunak <l lunak suse cz> wrote:
> >  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.
>
> With the format we currently use, I don't believe we can reliably
> recover the timestamp because the portions of the ID before the
> timestamp could possibly involve integers.  Your solution does appear
> to fix this, except that you need to specify that in
> "<unique>_TIME<timestamp>" the <unique> part can not contain _TIME;
> otherwise I think things could break.  This would also require doing
> sanity checks in the launching code to make sure that the startup_id
> chosen is sane and decide what to do if the id has to be modified.

 If you do reverse search for _TIME in the id, I think there shouldn't be a 
problem. The only two existing implementations so far I'm aware of are the 
KDE and GNOME ones, and neither of them includes _TIME anywhere in the id 
that could confuse the code. Possible new implementations should already 
include the properly formed id. So I don't expect this to be a problem in 
practice.

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

 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.

 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?

-- 
 Lubos Lunak
 KDE Developer