is XULRUNNER suitable as a replacement for other C++ desktop applications frameworks such as QT?

Question

XulRunner/Gecko seems to be really interesting for developing GUI-intensive applications (by using widely used technologies such as HTML / CSS / SVG / XUL / Javascript). But the underlaying C++ APIS (XPCOM, NECKO, ...) looks so old and complex. Moreover the general lack of documentation/developper tools is really frightening.

On the other hand, QT have a quite nice platform, and is well documented and supported. The UI part is really "traditional" though.

What are your experiences with XULRUNNER, specially compared to other C++ desktop applications frameworks such as QT/GTK/MFC...? What is missing? What is awesome?

Side question: If I wanted to migrate an existing MFC app to a cross platform C++ desktop application framework, would it be wise to use XULRUNNER instead of QT or GTK?

Answer 1

To be honest, I just don't agree there aren't many XULRunner apps out there... there are loads, these are just a few of the ones Mozilla knows of:

https://developer.mozilla.org/en/xulrunner_hall_of_fame

developer.mozilla.org/en/List_of_Mozilla-Based_Applications

This of course excludes Firefox and Thunderbird themselves!

Our own is listed there www.redbacksystems.com/liaison/

I have been developing in this platform since about 2003 and I love it, given the choice I would never program in any other platform now.

Why on earth would you want to write in QT or GTK when you can write in simple standards compliant JavaScript/ECMA including E4X, with exceptional CSS and XML support - including XBL (albeit 1.0), RDF, XML Templating, remote updating, plugin and extension support etc etc etc, and don't even start me on geo-location or native SQL support.

If you can't bootstrap a fairly complete XULRunner app within a few days, then you probably have something badly wrong. Any other coding effort will be required irrespective of your deployment platform.

For me, the Mozilla toolkit is the platform of choice bar none.

BTW, as I understand it Joost had specific challenges as they were writng/implementing their own video renderes and attempting to DRM content too.