Rich Internet for Everyone (RICHIE) Network: United XAML - XUL Alliance - XUL News - XUL Forum - The Richmond Post - RichCon 2005
The Richmond Post Logo
Chronicle of the Xul Revolution
« SwiXml Titan Interview (Kate Rhodes of Caterpillar fame) - Part II | Main | XML UI Language Sample Pack Live; 15+ XUL Formats Side-By-Side »
XUL Titan Interview: George Staikos (of XUL for Qt/KDE fame) - Part II
posted by Gerald Bauer on June 18, 2004

Welcome back to episode II of the XUL Titan Interview with KaXul/Uxul mastermind George Staikos.

Q: What's the state of scripting? Can you build mini KaXul/Uxul applications today using lets say JavaScript and some XML? Any plans of supporting alternative scripting languages such as Python?

George Staikos: You can, definitely. The JavaScript engine is complete since it uses KJS which is regularily used as the script engine in KHTML and Safari. The KJS embedding engine in KDE has been used to write impressively sophisticated JS+Qt applications already, and there's no reason why this can't be done with XUL too. Honestly I don't think I've pushed the envelope from the application side yet. As for other scripting languages, I have no intentions of ever doing that since I use KJSEmbed rather exclusively. My goal with that project was twofold: proof-of-concept, and interoperability. The "higher" goal of a real XML+scripting platform needs to go through standards and design first, in my opinion.

Q: Can you tell us how popular KaXul/Uxul is? (e.g. Are there any applications/projects using KaXul/Uxul already? What's the interest in the KDE community? etc.)

George Staikos: It's really just a proof-of-concept. The only user of it so far, that I know of, is a KDevelop plugin.

Q: Who else is behind KaXul/Uxul? Do you work on your own? How much time do you spend on KaXul/Uxul development? How can someone get involved in KaXul/Uxul?

George Staikos: I did KaXul design entirely on my own, but I received help from:

(I hope I didn't forget anyone)

I haven't worked on KaXul in about 8-9 months now. I've been consumed with other projects and I haven't generated enough interest in it to justify continuing it yet. If anyone is interested in working on it, I would love some help.

Q: What do you think about Mozilla XUL? How does it differ from KaXul/Uxul? Do you envison KaXul/Uxul to run Mozilla XUL apps or just share some XML tags?

George Staikos: The whole purpose of KaXul is to run Mozilla XUL apps as they are. I dream of more, but I have no intention of ever putting it into KaXul. The one big difference, which is a big bonus but also a bit of a problem, is that KaXul uses native widgets while Mozilla's XUL is effectively a renderer. With KaXul, your app looks and feels just like other apps on your desktop, and it's very fast and responsive. This is one of the things I don't like about Mozilla's XUL. It's always been slow. I can even launch Internet Explorer via Wine faster than I can launch Mozilla on the same machine and the menus respond much quicker, which is an indication that there are real problems lurking. Perhaps they're not all due to XUL, but I suspect it has much to do with it.

Q: What do you think of SuperKaramba that lets you build eye candy for the KDE desktop using just XML and Python?

George Staikos: I haven't tried it, but I've only heard good things about it.

Q: Do you know or can you highlight any other projects in the KDE world that let you build UIs using XML? Have you looked into libglade? Is there an alternative in the KDE world? How does the KaXul/Uxul approach differ from libglade?

George Staikos: Most KDE UIs are built using XML! Qt Designer is the most common form of UI building for KDE and Qt apps, and it outputs the same XML files that KaXul converts XUL files to. I don't think it's much different than libglade at all, though I haven't really used libglade.

The key to KaXul is that it can convert to Qt Designer files without worrying about the script bindings. Qt has an object model that allows for runtime introspection in C++. By creating some "XUL to Qt" function call/property translation tables, the scripting engine can automatically lookup and call the functions it needs at runtime. This is an extremely powerful feature for a compiled application, and it's what made KaXul so easy to implement.

Q: What's next for KaXul/Uxul? Any plans for a visual designer?

George Staikos: No, I don't have intentions of doing that. My understanding is that there are some good ones out there already, and I don't see a reason to create another.

Thanks George Staikos.

Links:

SourceForge Logo 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