Re: launch feedback status update

[Havoc Pennington <hp redhat com>]

Soeren Sandmann <sandmann daimi au dk> writes: 
> I thought GEP's were supposed to determine the requirements of
> enhancements? What's the point of a GEP if the solution is
> already finished?

Well, see foundation-list - it's a bit up in the air.

I think it's good to have a solid proposal for the GEP.
 
> You can't expect launchees to implement the spec properly. Everything
> should be robust against arbitrary weirdness from launchees, even if
> they claim to implement the spec.

It's fine to say that, but unless you actually have a plan that
achieves it (I can't think of one), I don't think it matters that
we've said it. ;-)
 
> But it also has problems: To do "sparkle" or icon animation feedback,
> the launch feedback program needs to overlay another client's window
> with a new window. This means the feedback can't be antialiased, and
> it will look ugly when the other client's window is moved (the
> "lagging" effect when X-windows from two different processes are moved
> at the same time)

Lubos also suggests dropping the GEOMETRY thing and have the launching
app do the sparkles; I agree with him and you.
 
> How can this be useful? If the launchee is a wrapper script, then this
> PID will not mean anything. How do you determine if the PID is meaning
> anything?

KStartupInfo will end feedback if it sees a window with the given PID
as _NET_WM_PID come up. Other than that, no it probably isn't useful.
 
> I think it would be better to use a ping mechanism, but if this can't
> be done

That's an interesting idea. 

> > The _NET_LAUNCH_INITIATE message should be sent _before_ launching the
> > launchee. Also, an XFlush() is needed before launching the launchee.
>                      ^^^^^^
> This would be an XSync(), right?

I'm not sure.
 
> Wouldn't it be possible to have the launchee create a new window,
> perhaps as a subwindow of the launch window? This new window could
> then be used to track when the launchee had finished
> launching.

This doesn't get you anywhere that I see, if you already have a ping
protocol, and it makes the launchee side more complex.
 
> This window could also be used to implement the ping protocol (send
> pings to this window, send responses to the launcher window).

Pings could just as easily go on the launch window, though.

> Why should it do that? It seems more reasonable to have a ping
> protocol and then every <short time> do a ping and update the
> animation. Or update the animation continously and just stop it if the
> launchee stops responding.

Yeah.

Havoc