Re: launch feedback status update

[Soeren Sandmann <sandmann daimi au dk>]

Havoc Pennington <hp redhat com> writes:

> Here is what's happening in the wide world of launch feedback.

Looks good in general. I have some comments, though.

> Before anyone asks, I'm postponing GEP on this until the protocol is
> more sorted out.

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?
 
>  - as close to 100% reliable operation as possible. 
>    "If everything implements the spec properly, then everything 
>     will work properly."

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.

>  - have a single program provide launch indication for the whole
>    desktop, regardless of who is launching it; this provides
>    consistency

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)

>    If a launcher wants to draw its own feedback on top of an icon, it
>    should not set this property.  However drawing one's own feedback
>    is discouraged since it's nicer if all apps have the same feedback
>    animation.

For this to work, the launch feedback application would have to know
_what_ to draw unless it draws the same always for all icons. For the
reasons I state above about the "single feedback" program, I don't
think drawing your own feedback should be discouraged.

>    That is, if displaying an animation on the launch icon, if the user
>    moves the window containing the launch icon, the animation should
>    also move.

This is going to look ugly if the animation is being drawed by another
process.

>  - _NET_LAUNCH_PID  CARDINAL/32

[...]

>    process, and the PID isn't known until after forking. However once 
>    set this property should not be modified.

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?

>  _NET_LAUNCH_PULSE

[...]

>    Launchees are encouraged to re-send _NET_LAUNCH_PULSE at regular
>    intervals, indicating that progress continues. This property should
>    be set before and during showing a splash screen, for example. See
>    implementation notes for more details.

I think it would be better to use a ping mechanism, but if this can't
be done, then it seems to me that applications will have to send this
PULSE message at small intervals to make sure they'll work with any
launch feedback program. In other words, "regular intervals" will have
to be a small fixed interval to come "as close to 100% reliable
operation as possible"

Given this, why not make this fixed interval explicit?

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

> One possible solution to the "stuck cursor" problem seen with
> current launch feedback solutions:

[...]

> A less-complicated and quite possibly better solution would be to 
> just time out the launch after some interval.

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. Feedback should then be stopped when the window was
destroyed or after a timeout. (The timeout would only be used if the
launchee somehow stayed alive but forgot to destroy its window).

This window could also be used to implement the ping protocol (send
pings to this window, send responses to the launcher window).

> If displaying an animated busy cursor, the feedback should "spin" the
> cursor when _NET_LAUNCH_PULSE is received. Launchees are encouraged to

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.


Søren