Forgot your password?
typodupeerror

Comment: Re:WPF Support (Score 5, Informative) 570

by toshok (#26745725) Attached to: The Case For Supporting and Using Mono

Until Mono gets WPF support there isn't going to be much cross-compatibility. Any Windows .NET developer with any sense is writing in WPF already. WinForms is dead.

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.

But Mono seems quite content to ignore WPF for now. One can't help but think it was part of that Novell/Microsoft deal.

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

The subset of WPF in Moonlight is useless for non-web development. It's great way for MS to pretend their Flash-killer format is multi-platform though.

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?

Comment: Re:slashdotted after the first comment (Score 1) 198

by toshok (#19959131) Attached to: New Linux Desktop Environment Built on Firefox

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?

Theory is gray, but the golden tree of life is green. -- Goethe

Working...