Re: launch feedback status update



There isn't much to figure out. xalf already does it. It just does it
with evil preload hacks, instead of patching X. A patch to X would
just merge a cleaned-up version of xalf into the actual code, so that
the preload wouldn't be needed anymore. Once the bugs are ironed out
of xalf, it works quite well. In fact, there are only two real issues
left now, and they have to do with su-type programs, and things which
screw with LD_PRELOAD in a wrapper shell script, which just iterates
the evilness of preloading. Though, if we could get an X patch, and
RH/YDL/etc... provided it in their packages for now, it wouldn't be
hard to get it into the actual X tree, and have nice launch feedback.
Presumably, you could also do something at the toolkit level, like
KDE does, to provide nice icons (1-bit alpha png icons, and animations),
instead of the default X cursors. But then again, it would also be
nice to be able to just override the default ugly X cursors with nice
ones anyway. :)

On Sat, 2002-09-21 at 12:20, Havoc Pennington wrote:
> Rodney Dawes <dobey free fr> writes:
> > Instead of creating more hacks at the toolkit/etc... levels, can we
> > do it right and just get a patch to X, so that it will work for ALL
> > apps, even those that don't use this "liblf" or something to notify
> > that something is happening?
> 
> That isn't possible IMO. Look at how the two proposed protocols work.
> Xlib doesn't have sufficiently high-level information about what's
> going on. Try to write down the details of how it would work on the
> Xlib level and either you'll figure out how to make it work there
> (good), or see why it won't work.
> 
> The "launchee" part of the protocols is microscopic, <1K of compiled
> code, we should be able to get it into apps. For apps that don't
> support it, we can use the window-class-based legacy support feature.
> 
> Havoc
-- 
Rodney Dawes <dobey free fr>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]