This is pretty lame reasoning - new applications are only part of the reasoning behind deciding which apis to support. Supporting the huge number of *existing* applications is also important, and the vast majority of the desktop .net applications out there now use winforms.

More faulty reasoning - have you seen the WPF api? It's enormous. As one of the people with the most commits in WPF-land, I can assure you, it's not prioritized based on any deal. It's strictly a resource issue. Moonlight is just more bang for the buck. Much smaller api to implement, much quicker adoption than WPF. Makes good business sense. That said, WPF remains a spare time project for me (and others).

Again, not really true. Silverlight 2.0's api is more than capable of building apps for both webpages and desktop, and will become more so as WPF and Silverlight converge. It will take some extending on the mono side for desktop integration, but again, when the choice is using an existing technology and extending it slightly (as in Moonlight) or starting fresh on a GIANT api (as in WPF), which would you choose?

I'm not sure how much you know about a desktop/windows under X so I'll go from basics.

First off, I'm one of the pyro authors - no need for the remedial (and in some cases incorrect) X lesson :) And no need to explain to me what our aims are.

Compositing is the process whereby a window is rendered to an offscreen buffer in OpenGL so that processing can be applied to the image before display.

"Compositing" has nothing specifically to do with OpenGL.

The OpenGL compositing managers use the X server composite extension to map window contents (through the backing pixmaps the composite extension creates) to textures.

Pyro uses it to map window contents to canvas elements.

And you're still thinking in a desktop centric way. It's not our goal to just run webapps seamlessly alongside native apps. That's just a necessary step along the way to the ultimate goal, which is a entire desktop built from web technology. It's also a (imo brilliant) proof of concept - that the gecko layout engine (as well as javascript and css) are up to the task. If it can run a window manager, why not application $X?