Re: launch feedback status update

[Lubos Lunak <l lunak suse cz>]

From: Soeren Sandmann <sandmann daimi au dk>
> Havoc Pennington <hp redhat com> writes:
[snip]
> >  - 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.

 Yes. I don't like the _NET_LAUNCH_GEOMETRY_* stuff either.

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

 I've heard rumours about some new X extension for cursors. That might help 
with KDE's busy cursor too.

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

 In KDE implementation this is rather a legacy thing, as the previous 
implementation was based on it IIRC. However, I guess this would be needed 
for _NET_LAUNCH_CANCEL.

> >  _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?
[snip] 
> 
> > 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.

 Ping is probably better than pulse. But I'd rather not make that <short time> 
that short - why? Apps providing the visual launch feedback can simply do 
whatever they want and if they feel like there's nothing going on, they can 
ping once to check the status, and possibly end the indication.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/