Chronicle of the Xul Revolution
|
|
|
Chronicle of the Xul Revolution |
Welcome back to episode two of the XUL Titan Interview with Jazilla prodigy Mathew McBride.
Q: Can you tell us how Jazilla's XUL engine - jzXUL - differs today from its jXUL origins?
Mathew McBride: It actually doesn't differ a lot in terms of code. The CSS engine has
been discarded, and replaced with the same common engine as the HTML
engine, but hasn't been enabled yet because Batik's CSS parser chokes
on special Mozilla properties (like "@namespace"). Since jXUL was oriented
at the older versions of XUL, some work has been done to make it
Mozilla XUL compatible.
Q: What's the state of scripting? Can you build mini applications today using just JavaScript and XUL? Can you point out some examples? Do you have any plans of supporting alternative scripting languages such as Python (Jython) or Groovy, for example?
Mathew McBride: Like Mozilla, JavaScript is used for scripting.
There isn't a lot implemented in terms of DOM compatiblity though, with
only document.getElementById() and some functions like
set/getAttribute() implemented, which is just enough to handle events
and manipulate the behavior of some elements. XPCOM and its standard
interfaces aren't implemented either. Since LiveConnect is enabled,
it's possible to use native Java classes too. Using LiveConnect, it's easy
to port a frontend of an existing Java application to jzXUL.
I have no plans for supporting any alternative scripting languages, but
anyone is welcome to write and maintain interfaces to other scripting
languages.
Q: Can you tell us how popular Jazilla is? (e.g. How many downloads? Are there any applications/projects using Jazilla/jzXUL already? What's the interest in the Java community? etc.)
Mathew McBride: I've had a lot of emails asking about the capabilities of Jazilla, but there aren't any applications using Jazilla/jzXUL yet. I don't have statistics for June and the recent Milestone 4 release (my webhost appears to have stopped generating statistics for now), but for May, the Jazilla website saw 56,000+ hits, and 3,700 unique visits. SourceForge.net shows Jazilla being downloaded anywhere from 10 to 30 times per day.
Q: Who else is behind Jazilla? Do you work on your own? How much time do you spend on Jazilla development? How can someone get involved in Jazilla?
Mathew McBride: I'm currently the only person working on Jazilla. I usually spend two weekends or more a month working on Jazilla, but I do tend to spend a lot more time if I can. While the best way to get involved is being a coder and bugfixing/implementing features, testing on different JRE's is needed too.
Q: What do you think about Mozilla XUL? How does it differ from Jazilla XUL? Do you envison Jazilla to run Mozilla XUL apps or just share some XUL tags?
Mathew McBride: I would like to see Jazilla running Mozilla XUL apps with minimal code writing on the XUL side (with rewriting of only custom XPCOM components etc. needed). Most of the improvements to Jazilla have come from trying to get Mozilla the suite running on Jazilla, and writing applications like the XUL Challenge samples, where I have made an effort to have the XUL markup produce the same result in Mozilla and Jazilla where possible.
Q: What's next for Jazilla?
Mathew McBride: More of an embedding and application development platform approach, instead of trying to make Jazilla an end-user product. The entire codebase is also been relicensed under the same MPL/GPL/LGPL license as Mozilla so we can share code around the XUL and HTML parts.
Thanks Mathew McBride.
Links:
Welcome back to episode two of the XUL Titan Interview with Mozilla XUL author extraordinaire Nigel McFarlane.
Q: Can you tell us how HTML and XUL fit together? Does XUL compete with HTML? Does XUL complement HTML? Does XUL require HTML at all?
Nigel McFarlane: In Mozilla's XUL, HTML and XUL are supported by a single set of CSS style properties. The application of those properties allows HTML and XUL tags to intermix. XUL uses a particular subset of the available properties, while HTML uses a different subset. So they are naturally complimentary.
Q: What's your take on scripting? Do you want to see alternative scripting languages such as Python, Perl or Ruby pushed more? Or do you want to stick to JavaScript only?
Nigel McFarlane: Until we get a sophisticated standalone JavaScript development environment, like Perl has, few people are going to realise just how powerful and clean JavaScript is. I don't see an urgency for Perl-in-the-browser. I do see an urgency for connections between existing scripting environments and Mozilla-powered XUL. No doubt that's coming.
Q: What's your take on namespaces? Do you think mere
mortals can handle strings such as
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"?
Nigel McFarlane: I'm on the record in Mozilla's Bugzilla as saying that both the historic and a new namespace identifier are needed. I'm overdue to push that point a little, I suppose. There is some logic associated with standards to deal with first.
Q: What's your take on RDF? Do you think mere mortals can handle trivial RDF files?
Nigel McFarlane: I think the RDF syntax is obscure, and the RDF working group seems to agree. I think people can handle anything if they're just given a break and a gentle introduction, which I've tried to provide.
Predicate-oriented languages have always been in a harder basket, though. No syntax change or alternate standard will stop that from being the case. Once you have the basics, the syntax isn't really an issue though. When I was learning RDF, most of the material on it was pretty crummy, so it's no surprise that it has a bad reputation.
Q: What's your take on XUL's widget set? Do you see a need for more widgets and more powerful and extensible tags?
Nigel McFarlane: I see a need for a place where innovative widgets and tags can be shown off. Working on it ...
If you study the way Mozilla works enough, it becomes apparent that there's no need to worry about a "default widget set". There's a lot of hot air in that debate, and not much substance.
Q: What's your take on XUL's tag verbosity? For example, can you envision a more light-weight alternative tree tagset?
Nigel McFarlane: I suppose trees have the same problems as tables - they're inherently more complex than simpler structures. There are some attempts at simpler syntax. I think that by the time you get to use a tree, though, your application is going to have lots of issues far more pressing than brevity of syntax.
Q: What's your take on the new WHAT-WG initiative started by Opera and Mozilla? Do you want to see a XUL Basic spec? Or do you want to see some XUL tags getting folded into HTML 5?
Nigel McFarlane: I think that anything that wants to stay alive has to grow, so the WHAT-WG has to be a positive force for the Web and HTML. I don't see a technical conflict between XUL and new HTML, and we have the W3C's standards that are now well-supported when conservative uses are required. I don't mind if tags from one standard bleed into the other, either. I suppose it could be made a mess, but I don't see that happening. I do think that working groups, whether formal or otherwise, have little control over their internal dynamics, so there's always an element of wait-and-see.
Q: Can you envision a light-weight XUL version without the Mozilla machinery (that is, without RDF, XPCOM, XBL, and so on)?
Nigel McFarlane: I can, but not as well as Brendan Eich or Chris Hofmann can. I'd say the issue of bundling XUL into various-sized chunks is a complex one. Such things aren't good ideas per se, they are only good ideas in terms of a bigger context.
I don't see much use for a wafer-thin XUL layer though. An XUL document is just a beginning and no more. The infrastructure that connects to it is just as important.
Q: What are your future plans for Mozilla XUL?
Nigel McFarlane: Well, I'm not the XUL module owner in the Mozilla community, so I'm not responsible for driving the technology forward. I do occassionally contribute to the engineering process, though. I write quite a lot (prolifically even) on Mozilla and on XUL and other topics.
I have various small projects forming up in the Mozilla space, but nothing to announce at this point.
Thanks Nigel McFarlane.
Links and Selected Articles:
Welcome back to episode two of the Thinlet XUL Titan Interview with Andrzej Bialecki of Luke (Lucene Index Toolbox) fame.
Q: What's your take on adding styling support to Thinlet? Have you tried out Eugene Klein's Skinlet addon?
Andrzej Bialecki: Yes, and I like it very much. I think the original look and feel of Thinlet by Robert Bajzat is very nice, and very functional - but I'm just a techie, and I prefer functional over baroque ;-) However, that's not the case with some users (and customers) - they often want the application to blend with their corporate look and feel, or to blend with their OS of choice.
So, I'm definitely for adding styling, although not as a core feature but as an extension. I believe the core Thinlet should stay clean and lean, but it should also provide well-defined "extension hooks" to implement e.g. your own layout policies or DTD extensions, or widgets, or - as is the case with Skinlet - your own decoration for every widget.
Q: Do you have a favorite scripting language for the Java runtime? Do you want to see scripting pushed more in Thinlet or do you want to keep the code Java only? Have you tried out Norbert Barbosa's Scriptable Thinlet addon?
Andrzej Bialecki: I don't have a favorite (yet - I'm waiting for Groovy to mature :-). I've been using BeanShell, Jython, and Rhino JavaScript on different occasions, and the choice depends mostly on the scope of tasks and the audience. I can do just fine with BeanShell, thank you - but I can't expect the same from someone who is mostly experienced with Web design, and has no experience with programming in Java; JavaScript seems like a more natural choice in that case.
I think the scriptable Thinlet is a great add-on - IMHO, suitable for rapid prototyping, and perhaps by people not so fluent in Java. But as I said before, I think it should be kept outside the core, as an add-on - and the core Thinlet should be patched to support also such type of extensions.
Q: What's your take on creating an OO wrapper for Thinlet?
Andrzej Bialecki: I don't think it's needed. OO for the sake of OO is pointless, especially if there is already a well-working model in place. The public API could be cleaner in some places, and some extensions are also required, but as it is now it serves its function very well, and it provides a good level of encapsulation and abstraction.
Now, if you ask me whether Thinlet requires refactoring - that's another issue; I believe it does. Current code is too convoluted to be effectively maintained and developed by more than two - three "gurus", and in my opinion this prevents more people from contributing to the project. The internal API is sometimes quite obscure, quite a few methods produce side-effects in global variables with unclear semantics, the code uses literal Strings for attribute names all over, there are "magic numbers" for adjusting layout and insets, etc... So, a cleanup of the internal API and data models, as well as adding some clearly defined extension points would definitely help.
Q: What do you think is still missing badly in Thinlet?
Andrzej Bialecki: In addition to what I mentioned above - a rudimentary model for some of the more complex widgets - namely, for the lists, tables and trees. Now, don't take me wrong - I'm not advocating the same level of complexity as in Swing. However, if you need to work with large or dynamic datasets, currently you have to code the data-to-widget management yourself - because it's not practical e.g. to load a list of 100,000 items in one shot, is it (I tried it a couple of times by mistake - my advise: don't do it :-)
Ability to mix-in any AWT Components with Thinlet widgets would be a fantastic feature - but I understand that it is technically quite difficult, perhaps impossible.
Ability to nest arbitrary components would be very useful, too - e.g. to put checkboxes in table cells, or to put panels with arbitrary content in list items. This is probably not as complicated as it seems, but the event handling code would have to be reworked... Some time ago I had a mostly working implementation of that feature, but I finally admitted a defeat after puzzling over the event handling methods...
While in a dreaming mode... a rudimentary cell editor for list/table/tree items would be very useful as well.
Q: What's next for Luke?
Andrzej Bialecki: Plugins. With the latest release I added a plugin framework, which allows others to write external components for working with Lucene indexes. This could be e.g. plugins for phonetic search, plugins to create indexes, for writing your own Similarity implementations using some scripting language - you name it. This is a sort of "escape hatch" for me as well - now not only I can add functionality to Luke, others are welcome too, and they have some sort of framework to build upon and to ease the pain of directly diving into the main code...
By the way, I think that's one of the major challenges for every Open Source project - to provide a sufficiently open and understandable framework (both in a programmatic sense, and in the way people collaborate in the project), so that others may join you in the development. I've seen lone riders, who burnt out after a year or so, and their pet projects have been abandoned, I even experienced such burnout myself - so, providing a good framework, good documentation, and a helpful hand means for me less burden in the future and more chances for the project to succeed - and to surpass my vision.
Q: Do you have any future plans for Thinlet?
Andrzej Bialecki: If time permits... I am somewhat discouraged now from working on the core Thinlet, because of its complexity - I implemented two widgets (sidebar, and "link" button), and I know I simply have too little time nowadays to sit whole nights tracking some obscure code paths... But I would like to stay involved, at the least helping to manage the CVS and the release process, and hopefully working on some well-defined extensions.
I'm convinced that the future of the project depends not only on how many users it gains, but also how many active developers and contributors it can attract - that's why I keep advocating for the openness in the development process, and for simplifying the core logic. All of us know how it is to be a newbie, and I wouldn't want to see Thinlet fall into neglect because it's perceived as too complicated to understand or extend.
Thanks Andrzej Bialecki.
Links:
Welcome back to episode two of the XUI Titan Interview with XUI and Carousel mastermind Luan O'Carroll.
Q: Can you point out how the XUI styling differs from classic CSS styling?
Luan O'Carroll: One of our objectives in building XUI was to keep things simple. We use Java and XML and that's pretty much it. We chose to use an XML syntax for styles for reasons of consistency.
Q: Do you have a favourite scripting language for the Java runtime? Any plans for adding support for scripting to XUI?
Luan O'Carroll: From the small exposure I have had to Jazzy I would say it is very impressive and has lots of nice features so that will probably be the choice.
There are no immediate plans for adding scripting to XUI and we don't see any great need for one. Having said that, we realize many people like to use scripting so even if I'm not a fan we will probably provide the option of using scripting at some stage, it's just not at the top of the to-do list yet. Of course if somebody would like to help we'd welcome contributions.
Q: Do you have any plans of adding web-style form submission tags to XUI? What's your recommended approach for data-binding for XUI?
Luan O'Carroll: Definitely, we are actively working on ways of making it even easier to do 'simple' business processing. We want to end up with a situation where the non-programmer can grab something like a schema and visually build and deploy working forms. I expect that the toolkit needed to enable such an approach will include standard web style actions like form submission.
XUI includes extensive data binding features and there are commercial extensions to the data binding for specific application areas (e.g. Forms, Surveys, Catalogues). Data bindings can be declared along with the UI or they can be configured dynamically. How the bindings are used is really quite application specific. In general though I would recommend keeping the UI and the data declarations as separate as possible as it makes it easier to do things like changing defaults/initial values, reuse of forms and localization.
Carousel, a commercial add-on from Xoetrope extends the data bindings to allow transfer of data from client to server in such a way that the application developer can pretty much ignore the location of the data. Once some routing information has been specified the toolkit will take care of everything else.
Q: XUI already supports two UI toolkits, that is, AWT and Swing. Can you tell us if and how the mark-up differs when you either choose AWT or Swing?
Luan O'Carroll: There is a core set of components where the mark-up is identical. The core is based on AWT and JDK 1.1.x (so as to support the MS, Jeode and Creme VMs). Switching toolkits is simply a matter of changing the start-up class, and normally no changes are needed to accommodate a switch to Swing.
There are a few attributes that will be ignored when switching from Swing to AWT but generally they have little or no impact. You can switch from AWT to Swing without problem but things get more complicated if you switch from Swing to AWT and specific Swing features not available in AWT are employed.
Q: Any plans of supporting even more UI toolkits such as SWT, wx4j or Gnome-Java, for example? Or do you plan to stick to the AWT and Swing duo?
Luan O'Carroll: The current priority is to make it easier to program Swing and AWT, but we may add support for the LCDUI. A number of users are looking at adding support for additional toolkits and devices but nothing is firm yet.
Q: Can you tell us how popular XUI is? Can you highlight some applications using XUI?
Luan O'Carroll: Since the final release of XUI 1.0.3 we have seen a significant increase in the number of downloads. In the last month we have been in the top 5% on SourceForge.
We have built several commercial applications using XUI in several areas, including:
Q: Can you tell us how XUI differs from alternative XML UI toolkits for Java such as Luxor, Thinlet, Vexi or SwiXml, for example?
Luan O'Carroll: XUI differs in a number of ways. Most obviously it relies on Java instead of JavaScript for programming purposes. XUI also differs in its scope as it provides extensive dynamic data binding support and XUI provides support for applications throughout their lifecycle instead of just during instantiation.
Q: What do you think about W3C XForms? How does it differ from XUI?
Luan O'Carroll: I think there are some nice features but overall its too complicated and doesn't go far enough in separating programming concerns. XUI doesn't have to deal with the legacy that XForms addresses so we have perhaps had more flexibility in terms of design.
Q: What's next for XUI?
Luan O'Carroll: Ease of use is the big thing on the agenda, both for the Java developer and the XML user. The objective is to make it possible to build applications with the minimum of coding.
Thanks Luan O'Carroll.
Links:
Welcome back to the XUL Titan Interview series. Today let's welcome Jazilla prodigy Mathew McBride.
Q: Can you tell us a little bit about youself?
Mathew McBride: I'm probably one of the youngest people around in the XUL world. I live in Australia, and I'm currently doing year 8 in high school. I've learnt almost all my skills in the IT area by myself.
Q: How did you stumble onto Mozilla's XUL?
Mathew McBride: I first stumbled onto Mozilla around Milestone 17 (if I remember correctly) in 2000. When Netscape 6 came out I was interested in seeing how its interface was themed and how the whole thing worked.
Q: How did you get started on Jazilla?
Mathew McBride: Back in 2002, I was involved in the flight simulation scene quite a bit.
I decided to write a GPL'ed application and server backend in order to
automate processing of data in Virtual Airlines. I needed a HTML
renderer for parts of the project, and I didn't know JTextPane exisited at the time. Some googling turned up Jazilla, which was a long defunct
project at the time. I spent a few days looking at the codebase and
took over the project soon after.
Q: Can you tell us a little bit about Jazilla's history?
Mathew McBride: Back in 1998, Netscape was rewriting the entire communicator suite in Java, in an effort called "Javagator" (and "Xena" by some people). The effort, sadly ended up dying in the corporate warfare that was Netscape at the time.
When Netscape released the Communicator 5 source code (which is what we now call Mozilla), a group of eager Java hackers started "Jazilla", an effort to port the (ugly) C and C++ Mozilla code to Java. The project continued on for the next two years, producing two Milestones, but dying off in 2000. (See the Wired story for some history)
I had a look at Jazilla in August 2002 and decided this would be a perfect project to work on. I soon took over leadership of the project and rescued it from the dead.
In December that year, I started playing around with jXUL as it was
very easy to hack on, and was already close to Mozilla's XUL spec. I had the
<browser> tag implemented with JTextPane,
and later NetBrowser (a fork of Jazilla's old rendering code which was somewhat cleaner than the code
at the time the project died), which lead to Jazilla ("NextGen" - to
seperate it from the older Netscape 4.x like releases) Milestone 1 last
year.
Q: Can you briefly sketch out the Jazilla architecture and its building blocks?
Mathew McBride: Jazilla uses the W3C DOM and Xerces to parse XML into a DOM tree. Based on the elements on the DOM tree, a Java class set up to handle a particular element. These construct the equivalent Swing widgets which are displayed. Event handling is done via Javascript and Mozilla.org's Rhino JavaScript engine, and CSS is used to style widgets.
Q: Can you tell us some challenges you faced building Jazilla using Java and Swing?
Mathew McBride: There are some parts of the Mozilla XUL spec which I've already thrown into the "too hard for now" basket.
Implementing Mozilla's <splitter/>
tag has proved to be hard (Swing's direct equivalent - JSplitter didn't support collapsing and JSplitPane is hard to use when we are constructing everything in real time with no
indication of what the engine will have to process next).
Also, XUL Observers and Broadcasters are proving hard to implement, even though they are somewhat rarely used in the Mozilla suite.
Q: Can you tell us what Jazilla can do today? What works and what needs to be done?
Mathew McBride: In addition to my efforts to get Mozilla's browser suite working with minimal code rewriting, Jazilla can be used to create basic applications. The immediate use would be in the embedded devices area, even though desktop applications are possible and can be done, but needs more work in order to deliver more functionality.
In the future I hope to improve the XUL engine even more, and XPCOM components. Allowing SVG and HTML via namespaces in XUL is a to-do item.
Q: Can you tell us if it's possible to use Jazilla's XUL engine - jzXUL - for building "classic" standalone Java Swing applications? Do you have a separate distribution? What are the dependencies for jzXUL?
Mathew McBride: It's possible to build standalone Swing applications with jzXUL, and there aren't many external dependencies either (the CSS part of Apache Batik, Mozilla.org Rhino, A DOM parser like Xerces are as far as it goes). A seperate distribution (with all external libraries in the box, but without Mozilla chrome) will come about sometime in the future. I've recommended recently to people who want to construct XUL applications use the XUL challenge kit, as that has all Mozilla "chrome" (XUL files) removed.
Q: Can you tell us how you handle the mapping from XUL tags/attributes to Swing classses/properties? Do you use reflection? Do you use hand-coded glue code?
Mathew McBride: Mapping from XUL elements is currently done with hand-coded glue code in every element class. In the future construction of element classes will be done in a simular way to the HTML engine, by reflection.
Thanks Mathew McBride. Check back next week for the second part of the XUL Titan interview with Mathew discussing how jzXUL differs from its jXUL origins, what's the state-of-scripting in Jazilla, what the future holds for Jazilla, and much much more.
Links:
I have all kinds of grand visions for what I'd like to do [to fixup Mozilla XUL]. I've posted many of them or hints about them over the last year or so. Remote XUL, improved templates, a canvas tag, and so forth. In some cases, I started an implementation only to be blocked by some non-implementation related issue. I actually started implementing something so that chrome URLs could be mapped onto http URLs but I stopped after it seemed unlikely that it would ever make it into Mozilla. I started working on some features for XUL templates, but Axel said that "creating template enhancements [is probably not] the right thing to do at the moment", so I didn't continue. I did get to the point where I posted a patch about the canvas tag, but then other developers seemed to take over and the patch disappeared into the Pit of Forgotten Patches. When Alex Vincent created a serverpost tag, no one seemed to want to accept it so it never got any where.
- Neil Deakin
Source: Neil's Place
The XAML4J Swing demo shows how you can use XAML4J to build the UI for a Swing Java program using XML.
Why would you want to do this? If you have ever written a large
Swing application, you will probably agree that coding a GUI in Java
can be a tedious task. XAML4J allows you to define the View (in an MVC
approach) in XML and bind it to a Model and Controller written in
Java. Or you can define actions (Controller) directly in XAML4J by
using the <action> tag.
XAML4J is also a great way for a designer to prototype a UI and avoid the learning curve of Java. In fact, a designer could develop a full-featured application using a rich set of functions and beans exposed via XAML4J tags.
To run the swing demo, go to directory xaml4j/swing and type "maven demo:swing" (View the demo script ). You should see a window open with some swing components. You can test the actions by selecting a menu item or pressing the button. The actions in this demo simply output a message to the console. A more practical action could be to invoke a bean, call a script that opens another window, etc.
If you look at the XAML4J code for this demo , you will see that building a UI is pretty simple. For example, a menu bar is simply:
<menuBar>
<menu text="File">
<menuItem>
<action name="New">
... some action ...
</action>
</menuItem>
</menu>
... more menus/menu items
</menuBar>
As you can see, nested elements are automatically added to parent
components (unlike Java, where you have to call parent.add(child) ).
Welcome back to the XUL Titan Interview series. Today let's welcome Mozilla XUL author extraordinaire Nigel McFarlane.
Q: Can you tell us a little bit about youself?
Nigel McFarlane: I'm a technologist and communicator with a programming and science background. I've worked mostly in highly technical areas like telecommunications and databases and in the structural aspects of application architectures.
Q: How did you stumble onto Mozilla's XUL?
Nigel McFarlane: I've been writing about Web browsers since 1996 or so. Mozilla's XUL has been on my watch list for a long time. It was clear that in Netscape Communicator 4.x that something was going on in the GUI area. At that stage we could only use object analysis tools to peek inside the product's structure. Once the source code was released to the public, the internals slowly became more clear.
Q: How did you get started on writing a book about Mozilla's XUL?
Nigel McFarlane: It helps if you've written a book before - that way you have some idea of the process and the landscape. I'd been through the process at least 3 times already. Basically, I just decided to take it on as a project. I knew it was a very big project, but challenges suit me.
Q: Can you tell us what topics your Rapid Application Development with Mozilla book covers?
Nigel McFarlane: Well, it provides a tutorial, conceptual overview and introductory reference to a large number of Mozilla technologies, chiefly XUL but also running through JavaScript, RDF, XBL, XPCOM and XPInstall, as well as some interesting subparts of XUL like templates.
Of the various XML UI dialects, Mozilla's XUL stands out for its maturity, robustness and deep integration with runtime objects. So the book covers a lot more ground than just a list of tags.
Q: Can you tell us some challenges you faced building the NoteTaker example for your Mozilla RAD book?
Nigel McFarlane: The existing material on XUL and other technologies was either patchy or non-existent when I started. I had already stared at the source code a fair bit, but I found that a lot more staring was required. Once I had that much straight in my head, the NoteTaker example was just a routine piece of implementation work.
Q: Can you tell us some challenges you faced writing about the Net's best kept secret (that is, XUL)?
Nigel McFarlane: For books, there's the little matter of convincing a publisher that you're not crazy. Other than that I'd say that invective from Microsoft evangelists is the only minor negative I've noted so far.
I'd say a challenge with XUL at the moment is the huge ideological split between your writings and the writings of core Mozilla people. The kind of partisan bickering and rhetoric that goes on provides no-one with any real credibility and makes everyone seem smaller. Plenty of opportunities are lost that way, too. I can't see any benefit in it.
Q: Can you tell us what tools you use to build your XUL apps? Can you recommend some tools that help in building XUL apps?
Nigel McFarlane: I'm an advocate for thinking and planning, but that's just my style. The Mozilla DOM Inspector, the Mozilla JavaScript console and a text editor are enough for me. I don't personally like interactive debuggers, but I do like other tools. I'm still looking for a validating XML editor that has a form factor that I can live with.
Q: What's the hook? Why would anyone use XUL over lets say classic toolkits such as Gtk+, Qt or Tk?
Nigel McFarlane: XUL supports fast, iterative development of GUIs, with easy modification after application completion. That's a very important combination for GUIs, because GUIs are very subject to change. You don't want a technology that locks the GUI down so that it can't be budged.
That argument knocks out Gtk+ and Qt in their raw form. The problem Tcl/Tk has always had is that it's a bit isolated and unusual. The Web development paradigm that applies to XUL brings a number of well-understood standards to the party (XML, CSS, ECMAScript, HTTP, etc). It's a more familiar environment for learning in.
Q: Can you tell us how someone interested in XUL can get started? What books, articles or online resources do you recommend?
Nigel McFarlane: Well, I shamelessly recommend my own book. Fortunately, so too do the majority of Mozilla readers that answered a poll on Mozilla books at www.mozillazine.org.
CSS and JavaScript are the most important non-XUL technologies to absorb. Basic web development is the easiest path to XUL. Or you could try a little XML plus objects first.
If I need to learn something new and unusual, then lurking on a newgroup, mailing list or forum works for me. Participation, even if only as audience is a fairly painless way to learn anything.
On the technical side, I recommend newcomers just take a look in the chrome directory that is part of any Mozilla install. There's a world to explore in there if you have a simple tool like WinZip or unzip or file-roller handy.
Q: Can you highlight some applications out in the wild using XUL?
Nigel McFarlane: Well, Komodo's ActiveState is the best known, next to the Mozilla Browser, Firefox and the other Mozilla Foundation projects. Also there's the hundreds of Extensions and Add-on for the core Mozilla products. And the in-progress NVu HTML editor.
None of those are "traditional" applications though, whatever that means.
Several people have shared with me their fancy application screenshots, but everyone's a bit coy about keeping their technology lead quiet at this stage. No doubt that will change as soon as the first horse bolts out the gate.
Thanks Nigel McFarlane. Check back next week for the second part of the XUL Titan interview with Nigel discussing the state-of-scripting for Mozilla XUL, how XUL and HTML fit together, if and how mere mortals can deal with RDF, what's Nigel's take on the WHAT-WG initiative, and much much more.
Links and Selected Articles:
|
|
Please send comments on our web pages to our public xul-talk mailinglist or to a member of our web team. | Copyright © 2003, 2004, 2005 Open XUL Alliance |