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

[Elijah Newren <newren gmail com>]

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:

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.

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


Elijah