Quick on the heels of our previous post on this matter, and Iain’s explanation of how it can be done in an external process and spawned on a keypress, malept points out Skippy, a program to do just that. However, it appears to be unmaintained. Does anyone fancy picking up the reins? Possibly there should be some Metacity-specific tweaks, like being able to un-Skippy by pressing the same key you used to launch it.
I think the existence of Skippy is good enough reason to close the bug. If anyone wants an Exposé-like effect, they should be able to install Skippy and tell Metacity about it without much effort. Perhaps some distros might even ship them together. If we had an FAQ, this should go in the FAQ. Maybe I’ll write an FAQ.
(Yes, the same principle can in theory be used to get the rotating cube effect. No, I don’t want to write it. But since it can be an external program, there’s absolutely nothing stopping someone else writing it and then I’ll post about it here!)
Photo © Taylor James, cc-by-nc-nd.
Except that it will never achieve a similar level of integration to the user (the “feeling”, not the technical merits) :)
And it either means we have to wait each time after pressing it (due to launch blocking on IO, which is a no-no as Expose is only useful if it’s quicker than alt+tabbing to the window) or we get to run yet another daemonized process.
BTW, gave skippy a try (both regular and XD)- the regular one died on start with X11 BadAccess.
The XD version… well… there is a clear difference between doing this: http://www.youtube.com/watch?v=rpTT6sj6Xmo and having to wait 2 to 4 seconds every time I press a key for everything to get covered with a large, static, over-transparent “thing”. It feels sluggish and totally out of place.
Which is why someone should take over maintainership of skippy-xd to improve it. (All I ask is that it doesn’t turn into a GL/clutter-based project – clutter and my video card do not get along.)
Now that you mention it, how does the current compositor work? It runs fine on an old Intel i915 laptop, unbearably slow on my work Intel i965G (but everything runs unbearably slow on this card so it’s normal) and makes my current laptop hit the top fan speeds under 10 seconds with one core almost constantly maxed out at 100% (moving a window – 100%, alt+tab – 100% and a 3 second wait) – this is an nVidia 8600GM with binary drivers (playing games).
Should I file a bug or is it known behavior? The GL-based compositors work fine so I assume it’s some mysterious 2D X extension not being properly implemented or emulated on this card.
AIUI, metacity’s compositor uses just the X Composite extension, not GL. (Which must be why it’s the only compositor that actually works on a computer that I maintain that has an 11+ year old video card.) Nvidia’s binary drivers have historically had horrible problems with 2D rendering (i.e., the X composite/render extensions) – I know this from experience triaging Avant Window Navigator bugs relating to it. (FWIW, Nvidia’s series 180 drivers are much better than the 17x series in terms of 2D rendering.)
I do known it’s not GL-based, that’s why I asked which X APIs were used. I do use 180.18 driver already and Metacity compositor is not something you’d like to work with. And I doubt nVidia is going to do something about it as Metacity seems to be the only consumer of this API, too bad :)