(Note: I’m getting an early jump on the ‘08 election season by writing the following ludicrously long political rant, in response to some simple questions posed on the Pyro list…)
More than a Fullscreen Browser
It’s true that fullscreen web browsers interfaces have been done before. In the past this has been done to implement special-purpose kiosk-like systems, or computer-novice interfaces for custom hardware.
Pyro is different; our initial goal is to support existing native applications well. This is so people can start using Pyro today, or at least soon, without interrupting their existing workflow.
(It’s interesting to note that most new-drawing-systems have targeted existing apps as a secondary goal. I think this contributes to their generally slow uptake and eventual death.)
Already nautilus’ desktop, gnome panels, and most modern apps work fine… keyboard, mouse, menus, dnd, copy/paste, etc. Many of the bugs with other apps are due to the unfinished WM spec support in Pyro.
Bling?
A secondary goal for Pyro is some level of feature parity with the newest generation of window managers… Aero/Aqua/Compiz. This should help remove the initial concern of new users about stepping back 5 years in order to switch to a Web-enabled desktop. We’re not doing it necessarily just to add “cool” bling though, which has unproven usability in my eyes.
So far we’ve implemented things like Expose and live thumbnails all using the standard web tech that many, many people already know. HTML, CSS, JavaScript. We’ll continue to keep things as Weby as possible, with minimal API addition.
A good example of the lack of custom API and code size is Pyro’s picker.js, which implements the default Alt-tab window switcher.
Picker: Canvas and XWindows
Basically the only custom API call for the picker is nativewin.AddContentNode (via CompzillaWindowContent, in content.js). nativewin there is an XPCOM interface representing a native XWindow.
AddContentNode takes a regular DOM <canvas> element as it’s only argument, and binds it to an XPixmap containing the live-updating content of that specific XWindow. This XPixmap is available thanks to the COMPOSITE X extension.
This is pretty similar to how Compiz binds composited XWindow content to an OpenGL surface, which is then rendered into the fullscreen OpenGL window. In both cases, the Window content is kept entirely in the XServer, which means that the contents can be rendered quickly.
The AddContentNode call also attaches a bunch of DOM event listeners to the canvas element, so that DOM mouse/key events sent to the DOM element can be forwarded on to the Xwindow.
When the picker’s DOM keybinding event listener fires, it creates and binds a canvas element for each toplevel XWindow (really anything with a uiDlg CSS class) to a <div> defined in the desktop’s xul/html definition. These canvases are sized down to fit inside the div, which causes the content to be scaled automatically by Firefox.
The picker has DOM key press listeners to animate sliding the div containing all the canvases to one side or the other depending on the key pressed, and there’s another div on top of it with the CSS overflow attribute set to hide anything outside it’s bounding box.
When you let go the Ctrl/Alt key, the picker is released, and calls the DOM focus method on whichever uiDlg “window” is currently highlighted, which turns around and calls focus on it’s canvas child. The focus event listener callback attached to the canvas element in AddContentNode then fires, and sends an X FocusIn event to the window the canvas element was bound to.
Cute anecdote on Ubiquity
When Chris was writing the picker, he spent a long time getting the layout right, and was frustrated. This started to bum me out.
Maybe it was easier to do this sort of thing with Compiz/Beryl? Or with a more standard widget toolkit? Maybe we’re just wasting our time? You know, standard middle of the dev cycle self-doubt.
Chris’ response: “Pfft. I don’t know how to do anything with Compiz”. Chris finished and committed the picker that night.
The next day I was walking to the grocery store, and had a realization. No matter how hard it was for us two Gtk/X hackers to figure out that bit of code, in the end it got written in JavaScript. With basically no Pyro-specific API.
That meant it was accessible and understandable to several hundred thousand people the entire world over. That’s a feeling I haven’t had in the many years of Gtk/X programming I seem to find under my belt these days.
Extensions and Upgrading
Something really cool about building on Firefox is that extensions can use it’s overlay mechanism to alter the desktop-global xul/html definition. They can add features, or replace existing functionality completely. Pyro just has to do a good job of making the JS friendly to supporting various extension points, and this can improve version to version as needed.
Version upgrade is another great benefit. Firefox will check for, download, and install new versions of Pyro and associated extensions as it would for any other browser extension.
Not Rewriting the World
I certainly don’t have any plans to rewrite existing desktop components or apps. Chris hasn’t talked about it either. But Pyro should enable extension authors to implement whatever they want.
Weby Widgets
In the middle term it’d be nice to support some stock Dashboard or Sidebar-like Web Widgets, and making them integrate really nicely. This would align with the secondary goal mentioned above. Pyro’s Widgets would be actual HTML content, or even embedded Flash/Silverlight, not the pseudo-web stuff that Apple and Microsoft are pushing.
Done as a quick hack, you can already press Ctrl-F9 to toggle a translucent overlay covering the desktop, with an offset iframe in the middle pointing to pyrodesktop.org. If people find this useful, it’d be easy to add a preference for the URL, so it would load your Google homepage or netvibes.com or bugzilla or whatever.
There is already some energy being put into standardizing Web Widget embedding, for blogs and such, and Pyro should be able to leverage that directly. Additionally, given some mechanism for listing/running installed native apps, such a Widget container could allow adding e.g. gnome-calculator to the Widget UI, whatever that ends up being, just like an HTML-based Widget.
Weby Panel?
Btw, if such an native app listing API were exposed to extensions — perhaps wrapping an XDG menu spec in XPCOM — it’d take enterprising Web hackers one step closer to implementing a Panel/Dock app launcher in HTML. Since they’d have the embedding and linking capabilities of the Web easily at hand, they might seamlessly integrate Web-app launching as well. I think that would be pretty cool, and I’d love it if Pyro could grow into such an enabling platform.
Other Platforms?
I think having something like Pyro working on Windows or MacOS would be an incredible achievement for the Web, the Desktop, and technology everywhere. But for now we’re starting with the openest platform.
Eventually, I hope someone will poke at Vista and OSX’s compositing window managers, to see if applications could replace/misuse them.
Getting Ideological
Personally, I envision Pyro as a way to encourage Web developers to plant their roots on Linux with Firefox/Pyro, and bring much-needed innovation and excitement. I’m psyched to see what can happen when browser window borders disappear.
And if successful, Pyro would be the first platform that gives Webheads full first-class citizenship… No native/non-native double standards. No insulation inside a designated browser app or bookmarks menu. No trying to upsell to a native platform API. No trying to lock-in developers to specializing on proprietary skills.
-
@Ryan: In that case, you probably want Jackfield (http://kryogenix.org/code/jackfield/).
-
Stop what you’re doing.
Please, please, please, for the love of God and all that is good, stop it now.
The web sucks. I though everyone agreed on that?
The web was originally made for statically displaying text and images over slow connections with next to nothing in terms of layout. That’s what HTML1 did, that’s what browsers did. It worked. It wasn’t intensely useful, but it worked.
The more the web has been moved towards what it is now – the dynamicky, AJAXy, pornographic advertisement freakshow with random sound from banner ads popping up when you least want them – the more it has sucked… but I have yet to see an area where all this stuff succeeds in conveying information in a way which is substantially better than the original, trim Web did. All it does is force me to buy more RAM to check my e-mail and read the headlines… think about it: I am doing the exact same things online today that I was doing ten years ago, but suddenly it takes up all my system resources. I’ve got a 12″ Apple laptop which fits neatly in a backpack with ten times the clock speed and twenty times the RAM compared to the 40 lbs. desktop I used ten years ago – but whilst that desktop handled the old web perfectly, my iBook G4 struggles to keep up at times. And what am I getting out of it? Certainly not better or quicker access to more information.
So all this JavaScript dynamism really amounts to a glorified tag, an annoyance at best – in the cases where it doesn’t downright break functionality, such as GMail pissing all over the way a web browser usually works by breaking the forwards/backwards buttons. Ten years of muscle memory ruined, because some twit of a developer decided to try and make his web page behave like a desktop application. He failed, of course, it’s an impossible endeavour, but he succeeded in annoying me on a daily basis and adding 512M to my swap file. Hoorah for Web 2.0!
I don’t know if the problem with the web is the designers or the tools. I know that some of the most incompetent people I’ve met in my life have worked in web design, but the fact of the matter is, the more HTML1 has been extended the more the results have sucked. The only good addition to the web in recent years has been RSS feeds – a horrible technology, I’m told by those who’ve been on either end of programming for it, but a good addition to the web because it means spending less time on it.
I applaud you for making something new. The open source desktop these days is not, to me, terribly exciting – I can patch together something which works a bit like IRIX or Windows, but it’s a long way to the spatial drag’n'drop enlightenment of classic Mac OS or BeOS, and an even longer way to something new.
You’ve obviously approached the desktop in a new and exciting way, but there’s a problem: the Web sucks. It can do a half-baked desktop emulation a la GMail only by violating its own roots and basic principles of operation, or it can present interlinked documents containing text and images, with or with the 2007 versions of and . In either case I think the question shoudl be asked, is this the right tool for the job? IMHO the answer is a resounding no.
So please, stop what you’re doing. Not because it isn’ exciting, but because somebody just might run with it – and before you know it, you’ll have created a monster, much like Tim Lee did when he drafted HTML and said, ah, this will probably do.
Much love,
Niklas Nisbeth
Denmark -
You laugh? I come here to try and save the future and you laugh?
If I was the man I was five years ago I’d put a flame thrower to this place!
Seriously, though, good luck. I hope you carve something useful out of the shite you’re working with
Oh and, you’re blogging software ate my “”s… as in:
“So all this JavaScript dynamism really amounts to a glorified !BLINK!BLINK!BLINK! tag”
Hope my message still got through..
-
ARGH!
… see what I mean?
-
> blink
-
“with or with the 2007 versions of (blink) and (marquee)”
-
Well, but in order to create a truly useful desktop, something that people would want to use every day and something that would push developers away form proprietary/OS-locked APIs (Win32, Posix, Cocoa) you will have to build an enormous JavaScript bridge between Weby application code and OS-services. There is only so much you can do by sucking data from “the cloud”.
Building a useful and powerful JavaScript runtime will take LOTS of effort and security implications of this project are hard to underestimate.
But the world *does* need something like that: an OS-agnostic, lightweight runtime, accessible from the browser, do allow developers build more than just “pages”.
-
“But the world *does* need something like that: an OS-agnostic, lightweight runtime, accessible from the browser, do allow developers build more than just “pagesâ€.”
I disagree with the ‘accesible from the browser’ idea. It just creates more problems than it solves, security being one, like you say.. The world might need libraries, protocols, well-defined data formats to tackle tomorrow’s needs, but why do they have to be shoehorned into a type of app designed to portray static text fetched one page at a time over the world’s simplest networking protocol? That’s just web developers’ megalomania. IMHO!
Anyways, I suppose I should leave this place alone. G’luck, gentlemen!
-
Niklas, I agree with you. I’ve posted a few comments up on toshok’s blog (http://squeedlyspooch.com/blog/archives/002095.html) with my points about potential problems with Pyro.
That said, it is an interesting experiment.
-
Hey
I was surfing the web and i saw this site, pretty cool.
Currently im running and adult site:Reachton
k, just want to say hi
Can i link you from my site? im looking for quality content like yours. If no let me know if i can add u in exchange for a montly fee or something. -
Hey
I was surfing the web and i saw this site, pretty cool.
Currently im running and adult site:Reachton
k, just want to say hi
Can i link you from my site? im looking for quality content like yours. If no let me know if i can add u in exchange for a montly fee or something.
Comments are now closed.

14 comments