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?
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?
If anything, this project might represent a breath of fresh air when it comes to the problem of platform differences between javascript/layout engines - you only have to worry about one. Granted, there might be bugs between different versions of said engine, but that's a problem that already exists in the native code space.
I'm going to go out on a limb and suggest that Alex and I have more experience developing desktop systems than you do. So I thank you kindly for your suggestion that it's not easy, but I'm pretty sure we already know that.
Also, your thoughts on gnome vs. kde are irrelevant to this discussion. Pyro exists because we believe *neither* of them represents the future.
Put it this way - it's just as secure as using a webapp you currently use. gmail? google maps? flickr? youtube? all of these include either javascript or flash which runs things client side, and they're made that much richer from it.
If you trust gmail, you go to gmail.com and use their webapp. In a pyro-world, it might be something like "you trust gmail, you download their javascript + html app and run it." In principle it's the same. The only difference is whether it downloads the js/html from the site or loads it out of an extension directory on your drive.
I'm not sure I understand your first paragraph well enough to answer.. maybe you should go read the article? Pyro has nothing to do with browser windows you look at webpages with. those will still show up as they normally do, with navigation controls.
Your second paragraph makes me think you didn't read it either.. "compositing" is mentioned quite clearly in the "How does Pyro work?" section:
Bringing all these Web technologies together with the newest generation of Linux display technology, called window compositing, allows Pyro to integrate native applications as an intrinsic part of the overall Web Desktop, seamlessly merging the two.
IE + win32 is pretty different from what we're doing. That combination was considered bad by the general public for a number of reasons, some of which are:
1. Anti-competitive behavior. Which was a stupid, *stupid* argument to make. I don't want some judge ruling on what my code can or can't do, and neither should you.
2. IE had (and has) an awful track record with security. Firefox has a great track record, I think you'd agree?
3. ActiveDesktop was created during the "push-technology" era, and so was mostly used as a way for content providers to stick things on your desktops. Netscape actually had a very similar product (pointcast, I think?) around the same time, which AD was created in response to. Thankfully pretty much everyone has decided that push = bad.
pyro isn't about push technology, and its goal isn't to provide a place for CNN or ESPN to put headlines. It's about looking at what users are doing and seeing that more and more things are being run in the browser, and in the future even more will be. why not afford these web applications the same sort of status on the desktop that native apps enjoy today? Why should there be any difference at all?
maybe you should make sure you're right before posting? And I doubt you thought of doing it the way we're doing it:)
If you're already running firefox for a browser, and choose not to run anything but native apps (which is likely the case now, since we haven't really explored how to even do the js+html apps), you shouldn't see much difference in memory usage. Our code is pretty small, and we've been careful about client-side memory usage.
Much of the firefox memory usage complaints center around objects that live on past page loads. There aren't any page loads in pyro (other than loading start.xul, anyway).
Slashdot Mirror
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?
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" 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?
If anything, this project might represent a breath of fresh air when it comes to the problem of platform differences between javascript/layout engines - you only have to worry about one. Granted, there might be bugs between different versions of said engine, but that's a problem that already exists in the native code space.
I'm going to go out on a limb and suggest that Alex and I have more experience developing desktop systems than you do. So I thank you kindly for your suggestion that it's not easy, but I'm pretty sure we already know that.
Also, your thoughts on gnome vs. kde are irrelevant to this discussion. Pyro exists because we believe *neither* of them represents the future.
Put it this way - it's just as secure as using a webapp you currently use. gmail? google maps? flickr? youtube? all of these include either javascript or flash which runs things client side, and they're made that much richer from it.
If you trust gmail, you go to gmail.com and use their webapp. In a pyro-world, it might be something like "you trust gmail, you download their javascript + html app and run it." In principle it's the same. The only difference is whether it downloads the js/html from the site or loads it out of an extension directory on your drive.
the pyro expose code is adapted somewhat from compiz's (it uses compiz's code to compute the destination x/y/w/h of the windows.)
the compiz code is MIT licensed, and the pyro adaptation is MPL'ed.
I'm not sure I understand your first paragraph well enough to answer.. maybe you should go read the article? Pyro has nothing to do with browser windows you look at webpages with. those will still show up as they normally do, with navigation controls.
Your second paragraph makes me think you didn't read it either.. "compositing" is mentioned quite clearly in the "How does Pyro work?" section:
IE + win32 is pretty different from what we're doing. That combination was considered bad by the general public for a number of reasons, some of which are:
1. Anti-competitive behavior. Which was a stupid, *stupid* argument to make. I don't want some judge ruling on what my code can or can't do, and neither should you.
2. IE had (and has) an awful track record with security. Firefox has a great track record, I think you'd agree?
3. ActiveDesktop was created during the "push-technology" era, and so was mostly used as a way for content providers to stick things on your desktops. Netscape actually had a very similar product (pointcast, I think?) around the same time, which AD was created in response to. Thankfully pretty much everyone has decided that push = bad.
pyro isn't about push technology, and its goal isn't to provide a place for CNN or ESPN to put headlines. It's about looking at what users are doing and seeing that more and more things are being run in the browser, and in the future even more will be. why not afford these web applications the same sort of status on the desktop that native apps enjoy today? Why should there be any difference at all?