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

[Elijah Newren <newren gmail com>]

On Wed, 8 Sep 2004 11:06:36 +0200, Lubos Lunak <l lunak suse cz> wrote:

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

Oh, right.  /me bashes his head against the wall for missing something
so obvious

Okay, well there's another issue I see.  I may just be missing
something patently obvious again, but if I am, hopefully you and Rob
can clue me in quickly again.  This one is more involved for me to try
to explain, so bear with me.

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.

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

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

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


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