The web is a pretty important medium to me. It is a medium that I spend all day, every day using, and it is a medium that I create content and media for. This content and media comes in the form of writing and specific web tailored content such as web pages and scripts. Like many other developers, have spent many a moment with gritted teeth trying to get my pages working in every browser. I have grown to learn the ways of the web, and this medium never fails to throw something new at me.
Despite the fact that we have languages such as PHP, Python, Perl, ASP and Javascript to make our web applications more dynamic, there is no doubt that the web is very much a limited medium to work with. This limitation is not from the processing angle; these languages give me the kind of processing available in system languages. No, the web is more limited in the realm of the user interface.
Within the web you have the fundamental GUI controls such as text boxes, buttons, checkboxes, radio buttons etc., but the user interface is distinctly limited. If you look at the full range of user interface controls typically associated with a graphical interface, many of these controls are missing from the web browser. Examples of this include tabbed pages, icon panes, context sensitive/pull down menus, toolbars, drag and drop and paint device widgets for handling document centric applications.
I know that many of you reading this will claim that a number of these user interface elements are indeed possible within a web environment. Yes, I agree that you can create JavaScript menu’s, you can emulate drag and drop with DHTML and with enough coding you can create similar UI elements within the browser. Although possible, much of this is a hack. These elements are not supported out of the box at an API level but are simply being re-implemented within the application. This means that if you want to do anything more experimental within the web browser environment, you need to re-implement many of these user interface elements that are not supported within HTML. This in itself limits the platform for creating more dynamic applications that require more complex user interaction. As an example, if I wanted to create a word processor, handling the main document area of the word processor would take some pretty serious UI coding. Much of this would be handling events and implementing methods to respond to these events. Although this would be required when writing a similar application with a typical GUI toolkit such as Qt/GTK, the issue with the web is first coding these special emulated complex widgets and then actually making your funky UI work in all browsers. This is a nightmare with this level of complexity in UI design, so what do we do?
I am a firm believer that web applications need to be tuned to the platform and context that they are being developed for. A website selling inflatable sheep needs to be accessible in all browsers and for all platforms; it is a public resource and should handle the different platforms that the public use. With regards to custom applications for specific clients/environments however, we can focus on a single browser platform; this is common within intranet application development. This is where Mozilla is pushing the potential for Mozilla dependent web applications with its XML User Interface Language (XUL) framework.
I have been playing with XUL recently and I have been really motivated with the potential for building truly interactive system type web applications. You only need to take a look at the Amazon application that is bandied around by pro-XUL hackers to see an example of what is possible with it. This framework not only brings the web browser out of the dark ages in terms of the potential for interaction, but the Mozilla developers made the right choice and picked XML as the language for specifying user interfaces. This choice not only makes user interfaces extremely easy to construct (with the benefits of XML DTD validation to boot), but the fact that the interface code is in XML also opens up a whole world of potential for further processing of this interface code. There is no reason why someone could not write a thin compatibility layer to convert XUL interface code to a fake table/div/image based interface for none-XUL browsers.
The exciting thing about XUL is not XML though. The truly inspiring aspect of XUL is the potential to standardise on Mozilla as a platform for developing complex applications. Many years ago I used to ramble on to bleary eyed people how I believed that the application space will move from the system to the web. At this time the web was beginning to take off and it seemed logical that everything should move into this area. People seemed to love the fact that they could check their email from the office/home/PDA/fridge with web based email, so why not push things forward with document centric applications?
With the on-going roller-coaster of Open Source software we also have a great potential for web based ports. Who is to say that at some point in the future an OpenOffice.org XUL based port is possible? How about a XUL based GIMP or Quanta? Admittedly, XUL still has some more advanced user interface widgets missing at the moment, but the fact that so much has been made available in the current versions of Mozilla, we can see the potential for this framework.
Application developers are going to need to consider how much user interface code is hooked into application logic. This is of particular importance if cross platform support is one of the goals of an application, and particularly if this cross platform support should be native and not byte-code running on a virtual machine. The problem we have here is that the operation of a button works pretty much the same for a user in a Qt/GTK/Windows/Mac OS X/QNX application, but the implementation of this button for the developer varies between these different GUI interfaces. This is an area where XUL again has some real potential for developers. If a developer was to write all UI elements in XUL XML instead of native code within the application logic, the XML could be converted to this native toolkit code using a compatibility layer. This technique of using an XML layer is used to a point in other systems (such as with Qt Designer when creating Qt interfaces), but the key point is that XUL should be the standardised XML language for handling these interfaces. This could dramatically open up the potential for a new breed of web based applications that could be cross platform and cross browser based if the W3C were to adopt XUL as an official recommendation.
I know that some of this is a pipe dream at the moment, and some parts of this vision are not quite there yet. There are also some issues with how system level processing works differently to web based processing. The point I am drilling here though is that XUL is great opportunity to strike a balance between different platform dependent applications.
The Mozilla project is proving to be capable of not only creating a strong and impressive suite of applications, but is also using the combined intellect of the development community to harness the potential for not only Mozilla based development, but development in general.
What do you think? Does Mozilla give us this potential or is this really just a pipe dream? Scribe your thoughts below…
Open XUL Alliance - Creating A Rich Internet For Everyone
Hello,
You might wonna check out the Open XUL Alliance site @ http://xul.sourceforge.net that lists many alternative open source XUL motors/runtimes/browsers/players such as SwiXML, Ibex (formerly XWT), Luxor, Thinlet, and so on.
Also if you want to connect up with fellow XUL coders or designer sign up for the International XUL Meetup Day. More @ http://xul.meetup.com
- Gerald
Why not a wxWidgets backend for Mozilla?
Both OpenOffice and Mozilla maintain their own cross-platform toolkits, and both are required to write and maintain a lot of code interfacing with the underlying native toolkits. This eventually leads to inertia when implementing new, more powerful, components because you need to implement it for all major platforms.
But wxWidgets already solves the problem in regards to advanced widgets. It has GTK/Carbon/Win32/X11/etc. backends, with Cocoa and embedded ports well underway, and a recently started Qt port. Most major controls are implemented, meaning that people can create pretty complex interfaces with it. Therefore, if XUL was wxWidgets internally, they'd simply have to wrap the wxWidgets class to immediately get new native controls on all major platforms. And every port would be like 'Camino', with a native LNF for that platform.
This is just a pipe dream but I'd love to see the Mozilla folks take a serious look at it. It would cause some bumps in the short term, but eventually lead to the removal of tons of code from the Mozilla tree and distribute GUI code maintenance among the two projects. This would allow the Mozilla folks to spend more time working on new stuff rather than maintaining the old code.
XUL is not a generic term
People should note that what Gerald Bauer means by "XUL" is not what the Mozilla community means by it. Despite requests to stop, he continues to engage in activity designed to confuse people about what it means, in contravention of the Mozilla Foundation's de facto trademark on XUL, and to present his "Open XUL Alliance" as some sort of umbrella body.
If you want to find the real XUL community, head over to XULPlanet.
XUL is not a generic term
Hmmm, so what is the difference?
Why not a wxWidgets backend for Mozilla?
Go read Mozilla's designer rational why the haven't used ANY of the available toolkits and created their own. Quite simply: because it had to handle thousands of widgets, where widgets are also tiny elements of a HTML page (checkboxes, buttons, etc).
wxWindows doesn't solve this problem, or any other.
It surely won't "allow the mozilla folks to spend more time working on new stuff rather than maintaining the old code". In reverse, it will have them working on the vast task of changing their UI code to use it, for no gain.
Add on top of it the dependency hell: on wxWindows, on GTK on Unices, MFC on Windows, etc...
Why not a wxWidgets backend for Mozilla?
Have you really checked the Mozilla source? GFX and Widgets (the guts of the GUI drawing code) do have platform-native implementations for about 6-7 different platforms. In fact, I know this very well because I've embedded Mozilla on Windows, Mac, and Linux, and I've had to deal with underlying "platform issues" on each of them. In other words, they've already been dealing with "dependency hell" for quite some time.
These platform native implementations are actually the code I'm referring to moving to wxWidgets. Then they have one "port" to support, not 6-7. As for your first statement about why they decided against it, I'm not sure precisely what you mean (or the original authors, as I don't have the link), but I suspect the point you're referencing is that they couldn't use *native* controls because they would need extra flexibility. (Like rendering using CSS, etc.) But of course they can use wxDC to draw their controls whenever they don't want to use the native controls, just as they use native DC equivalents now.
There may be reasons they can't use wxWidgets, of course, but they aren't the ones you've described. That one extra dependency on wxWidgets would reduce the code they need to maintain by tens of thousands of lines.
More native widgets coming to XUL.
Check out Brendan Eich's recent slidwhoe on Mozilla futures. There is mention of more native widgets among other goodies (go python!).
http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/title.html
(down arrow to step thgrough the slides.)
XUL is not a generic term
Gerald Bauer always uses the term to describe any XML-based user interface markup language, e.g. XAML, etc.
XUL/XUI/XAML are generic terms not trademarks
Hello,
anyone who's interested in the gory details about the XUL/XUI/XAML hairsplitting debate. I invite you to check out the MozillaZine article @ http://www.mozillazine.org/talkback.html?article=4584 or the Richmond Post online poll plus comments @ http://xul.sourceforge.net/post/2004/01/poll_is_xml_ui_language_trademarkable.html
Peace.
Lots of discussions over GNOME and Mozilla collaborations
In the last couple days, there are a lot of discussions over the future of Mozilla and its collaboration with GNOME, what it means to developers, and to meet the challenge of Windows Longhorn:
http://usefulinc.com/edd/blog/contents/2004/03/03-gnomeui/read
http://www.mozillazine.org/articles/article4584.html
http://www.gnomedesktop.org/article.php?sid=1734
One of the problems for developing in Mozilla and XUL is good documentation is hard to come by. Speaking of which, Nigel McFarlane's book: Rapid Application Development with Mozilla, is now available as PDF download from Bruce Peren's Open Source Series at InformIT's host homepage:
http://phptr.com/Perens
Hopefully more docs like his will be available so that we can attract more XUL developers. Btw, please support the author and buy the book if you find it to be useful.