a life of coding

Wednesday, January 07, 2009

Firefox: An Acceptable Cross Platform GUI Toolkit

A recent Hacker News submission asked what an "acceptable" cross-platform GUI toolkit would be. It discusses common complaints about the existing toolkits GTK+, Qt, Tk, and wxWidgets. It suggests creating a new toolkit with the qualities of being written in C, keeping it simple, LGPL licensing, easily skinnable for different OS's, binding for scripting languages, and be "simple and easy to use".

Good news! I know of an existing GUI toolkit that fits this bill. Its written and extensible in C/C++, has liberal licensing, is very skinnable, has bindings for JavaScript, Python, Java, Perl, and Ruby, and lots of existing open source code that you can learn from. It even has a large, mixed platform install base, so you know that the bugs are minimal. Its based on an object brokering system called XPCOM, and an application framework called Mozilla, but often goes by the name Firefox. Given the popularity of web applications in the startup community, Firefox seems like an obvious option for desktop apps. Yet it hasn't caught on, and I'm not sure why.

I recently worked on a desktop application for my day job. Given their limited interface goals and a game-oriented 3d engine, they had decided to write the interface directly in OpenGL. It was difficult to design interfaces like that, so I did a prototype integration with wxPython. That worked well enough to start real product development, during which I realized that wxPython had many of the "cross-platform toolkit" woes like needless internal complexity, difficulty in writing new components, and general ugliness.

I spent some time contemplating how people wrote successful cross platform desktop applications, and the two things that struck me were (a) there aren't many, (b) except Firefox, (c) and this might underly the popularity of web applications. So I did a new prototype using Firefox with a XUL user interface. What I found was that Firefox worked out great as a standalone application with modular code design, but it was difficult to write good interfaces in XUL. XUL seems to be well tested only as far as the functionality in Firefox is concerned. We switched to Ext-JS, started pretending to be web app devs, and got down to implementing features.

Writing a desktop app based on XULRunner has some interesting side-effects. For one, it makes retargeting your code as a web application or Firefox plugin really easy. It also lets you develop using a variety of hacker friendly languages. Like programming in lisp, it changes your perspective on how applications should be developed, and makes questions like "which UI toolkit is the best?" seem fundamentally flawed. In an age when Apple is rewriting their apps to run in a browser (and still look and feel like desktop apps), isn't writing a code against a desktop UI toolkit fighting the tide?

12 Comments:

  • "Firefox seems like an obvious option for desktop apps. Yet it hasn't caught on, and I'm not sure why."

    Because we've never seen it work really well. Quick: how many Mozilla-based desktop applications can you name? There's Miro, and ... uh, does Chatzilla count? They feel sluggish, and have highly inconsistent UIs (both with the platform they're running on, and to themselves on other platforms).

    True, I don't know if this has to do with Mozilla or not. Maybe Chatzilla is just really inefficiently implemented, and Miro guys went out of their way to have a completely different UI on every platform. I don't know.

    But writing an app is itself a risk. I don't want other layers of my software stack to be a risk. I want to build on things I know will work. Things like GTK+ fit that bill, but Mozilla (so far) does not.

    For that matter, I've seen web apps that feel more like desktop apps than Mozilla-based desktop apps. I'm not surprised that a lot more people are writing web apps.

    For us to take Mozilla seriously as a desktop platform, we'd need to see some example of a first-rate app using it, other than Firefox. As one of my mentors used to say, "it's not portable until you've actually ported it a couple times".

    By Anonymous Anonymous, At 1/7/09 2:18 PM  

  • > Quick: how many Mozilla-based desktop applications can you name?

    There's Komodo Edit/IDE. They're not exactly fast, but good enough.

    By Anonymous Anonymous, At 1/7/09 2:26 PM  

  • Have a look at celtx

    www.celtx.com

    By Anonymous Mark, At 1/7/09 2:34 PM  

  • Here's a good list:

    https://developer.mozilla.org/En/List_of_Mozilla-Based_Applications

    By Blogger blizzard, At 1/7/09 3:10 PM  

  • SongBird

    By OpenID dmr83457, At 1/7/09 3:12 PM  

  • There's also the Flickr Uploadr. And there are server-side XULRunner apps, too, such as the server-side uploader from my company, Wesabe.

    XULRunner isn't well promoted or supported, and Mozilla keeps giving iffy messages about whether they like it or not. I sometimes get the sense that it's somebody's pet side project, and if that person were to leave, development would stop.

    I dunno. It works really well for us, and I'd be happy to see more apps use it. I agree with all of the strengths listed above -- I'd just say that the effort to get going is pretty high, and people don't know about it.

    Marc Hedlund, Wesabe

    By Anonymous Marc Hedlund, At 1/7/09 3:45 PM  

  • How much does it take for you application to launch?

    How big is the stuff you need to distribute to users for a painless install?

    How responsive is the application?

    How much boilerplate code do you need to write to have a minimal Hello World window with a quit button/

    How much does it take to compile the minimal hello world example above?

    By Anonymous Anonymous, At 1/7/09 5:25 PM  

  • .Net/Mono/Silverlight/WPF _or something like it_ is a much better solution because not only is it cross platform, but it's _cross language_ so you get all your "hacker" languages like Python and Ruby as well as the mainstream languages like C++ and C#.

    Not only that, but components written in one language can be used from another language, in the same project, because they all share the same runtime.

    That is the future. You're not going to get any of that with XUL.

    By Anonymous Anonymous, At 1/7/09 6:07 PM  

  • Java + SWT works for me! Uses Native components for most of it's work and builds from there.

    Check out some of the awesome apps that use SWT under the hood at the bottom of this page: http://www.eclipse.org/swt/community.php

    Easy to distribute, runs great, D&D, Tray Icons, Native widgets, decent abstracted event model.

    By Blogger Eric Zimmerman, At 1/7/09 6:42 PM  

  • Did you consider adobe AIR?

    By Blogger Josh, At 1/7/09 9:18 PM  

  • What about 3D ?

    By Anonymous Anonymous, At 1/8/09 10:25 AM  

  • @anonymous
    You are able to use Python, C++, Java, etc. when using the Mozilla platform. It is true that they will be running different runtimes and integrating them is sometimes troublesome, but how many times do you really want to write an application in more than a few languages at once (the Mozilla way seems to rely heavily on Javascript as a standard extension language, for example).

    And as for talking about the way of the future: some of us have to write applications now. Do you consider those things ready now? Can we get access to an existing C++ library we depend on now, or would it touch the Silverlight security model too badly? We can access that library using SWIG, CPython, and PyXPCOM, so the Mozilla platform works for us and is cross-platform right now (yes, the underlying C++ library is cross-platform).

    I see as much innovation (maybe more) in the Mozilla camp as in the MS/Mono Silverlight/Moonlight camp. They are going in different directions. If the .NET/Silverlight camp is going your direction, take it. Just be aware that not everyone has to go in that direction.

    By Blogger Jon Morgan, At 1/8/09 10:34 PM  

Post a Comment



<$I18N$LinksToThisPost>:

Create a Link

<< Home