Chronicle of the Xul Revolution
|
|
|
Chronicle of the Xul Revolution |
Welcome back to the Thinlet XUL Titan Interview series. Today let's welcome Andrzej Bialecki of Luke fame.
Q: Can you tell us a little bit about yourself?
Andrzej Bialecki: I work for a Swedish company as an analyst and system architect, and at the same time I do quite a bit of coding (as is the case in many small companies). We deliver solutions in the area of system integration, information retrieval, so called business intelligence and knowledge management.
Now, enough buzzwords - I'm a Polish native, currently living back in Poland (after a couple of years spent in Sweden), together with my family - wife, son and daughter. There's probably a formula describing how being married and with two kids affects the amount of time you can spend hacking the code - I can't recall the specifics, but it's at least exponential in order... ;-) But I do like hacking the code, and I still have a lot of satisfaction from just plain coding, and making the programs do what I want.
Nowadays I work mostly with Java, quite often using MDA tools (e.g. Together) for generating prototype implementations from UML models. I'm quite well versed in the Unix environment (including kernel hacking) - a couple of years ago I started a successful Open Source project named PicoBSD (an embedded version of FreeBSD) - so I'm quite familiar with how the things work in Open Source projects, and whenever I can I advocate the benefits of this model to my boss - not always an easy task... ;-)
Q: How did you stumble onto Thinlet?
Andrzej Bialecki: I was looking for an alternative to Swing for one of the projects. Having experienced the pain of hand-coding a Swing UI for another application I just couldn't believe there was no other way to create UIs other than implementing dozens of models, listeners, and to litter your code with anonymous classes. There had to be another way (at least for me - I'm a programmer at heart, and programmers are lazy :-) ).
When I stumbled across the Thinlet Demo applet I knew that was it. The applet had an elegant and slim design, it contained all the widgets I needed at that time, and the XML descriptors were clean and intuitive - what more could I ask for? So, for me the main attraction of Thinlet was not the fact that it works in JDK 1.1, or Personal Java - it was the ease of prototyping, and re-using majority of the prototype code in the final application. A big time-saver.
Q: Have you tried out any alternative XML UI toolkits for Java before settling on Thinlet?
Andrzej Bialecki: More or less - I never went past test applications with a couple of them, before deciding on Thinlet. At the time I was under a deadline, so I couldn't spend too much time for research. I had the least trouble to wrap my mind around the way Thinlet worked - so it was enough at the time not to bother too much with alternatives. Now I would probably be more tempted to choose SwiXML, which IMHO strikes the right balance between the complexity (but also robustness) of Swing and the user-friendliness of the XUL paradigm.
Q: How did you get started on Luke?
Andrzej Bialecki: I was working on a suite of applications for business information retrieval, which under the hood used Lucene extensively. If you want to know how to produce all kinds of corrupted Lucene indices, just ask me *laugh*... Finally, I came to conclusion (again, motivated by my laziness ;-) that it's time to put an end to writing short test programs each time I want to do something with a Lucene index. So, the idea of a swiss-army knife-like tool for Lucene was born. And the choice of Thinlets for UI was quite natural - I already coded dozens of screens in Thinlet by that time, and I realized that I can prototype the GUI very quickly, and with minimal amount of unnecessary cruft - again, unlike with Swing...
Q: Can you tell us some challenges you faced building Luke using Thinlet?
Andrzej Bialecki: There were really two big challenges, or deficiences in Thinlet, which caused me some grief. One was the lack of resizable and sortable tables - I had to figure out the best compromise for the column widths, and frankly nobody liked that compromise. Fortunately, in the latest (CVS) version of Thinlet this problem is fixed.
The other problem, which still remains unsolved, is the lack of truly modal dialogs. The logic flow becomes quite twisted if you can't pop up a dialog and just block the flow while waiting for some user input. It reminds me of the cognitive shock I experienced when trying to write my first XSL stylesheet, or my first SAX event handler - suddenly you need to switch from the linear flow to event-driven flow in the middle of a method, and it makes for a pretty convoluted code... I hope this issue will be addressed soon.
Q: Can you tell us what Luke can do today? What works and what needs to be done?
Andrzej Bialecki: Well, as far as I know Luke can do almost anything that you can possibly do with an existing Lucene index - browsing the content, searching, deleting, optimizing, etc. It doesn't do much to _create_ indexes - that's perhaps a task better left for plugins that Luke now supports - but I believe it covers all functionality related to using existing indices - really, I just went through the Lucene API and hooked up most of the methods to the UI.
Of course, it was not so straightforward :-) - Luke also provides some functionality that is not directly available in Lucene (e.g. the top most frequent terms), or at least not without some non-obvious coding. Example: in the latest release Luke can reconstruct the original document contents using just the inverted term lists (i.e. even if the original text is not stored as such in the index). Lucene doesn't provide any functionality to "edit" the documents in the index, but Luke can emulate this function by first reconstructing the document, providing a simple text editor, and then inserting the edited copy back into the index.
Q: Was Luke your first Thinlet? Can you highlight some of your other apps built using Thinlet?
Andrzej Bialecki: No, it was rather a by-product of my work on a suite of commercial applications I mentioned before. That suite ended up having something around 100 different screens and dialogs, most of them implemented using Thinlet, with some parts using Swing where the Thinlet widgets were not sufficient. I don't think I could've delivered such a complex system on time if not for the Thinlets...
Thanks Andrzej Bialecki. Check back next week for the second part of the Thinlet XUL Titan interview with Andrzej discussing scripting choices for Thinlet, styling using Skinlet, what's next for Luke and much much more.
Links:
Welcome back to the Luxor XUL Titan Interview series. Today let's welcome Vladimir Kvassov.
Q: Can you tell us a little bit about yourself?
Vladimir Kvassov: The last two and a half years I worked for Rostov-Clearing JSC (development of banking and banking-related software) as a software developer and team leader. Since June 2004 I have been working on projects for GlaxoSmithKline based on the Eclipse platform. Areas of my professional interest are Java and Java-related technologies, but I have experience in C++, C# and PL/SQL.
Q: How did you stumble onto the Luxor XUL toolkit? Have you tried out any alternative XML UI language alternatives before settling on Luxor?
Vladimir Kvassov: Two years ago I faced the task of selecting GUI tools/libraries for the next generation of banking applications. One idea was to use XML to describe UIs. I checked out some projects and Luxor was the best solution at that moment.
One of the alternatives I've tried was XML Talk. Actually, my first pilot project was based on XML Talk... But lots of problems came up because of the strange architecture, the lack of documentation, and the lack of support. There were some problems with documentation when we started using Luxor, but the Luxor team was always friendly and ready to answer questions.
Q: Can you tell us some challenges you faced using Luxor for your banking applications and accounting applications?
Vladimir Kvassov: We had some problems with the default xul loader. It was inconvenient that all xul files should be in one "special" folder, especially when you have loads of xul files in many subprojects. So, we made our own xul loader, which gets list of xul's from all installed subsystems.
Q: Can you tell us more about your widget plugins and how your new widget architecture makes data exchange easier?
Vladimir Kvassov: We needed a common data exchange architecture for all widgets we use.
But the standard Swing widgets don't include a common interface for data
exchange.
As Luxor offers the possibility for creating widgets, we created our
own widgets that use a interface with two simple methods:
getVal() and setVal(Object o). This decision helped us to provide
automatic processing of DB-to-GUI, GUI-to-DB data transfers.
Q: Do you have a favorite scripting language for the Java runtime? Do you want to see scripting pushed more in Luxor?
Vladimir Kvassov: My favorite scripting language is OGNL. We used BSH for a while, but BSH is much slower than OGNL. OGNL is well documented, quite fast and easy to use.
Q: Can you tell us how OGNL fits into Luxor and how OGNL can speed up Luxor development?
Vladimir Kvassov: The use of scripting languages in Luxor can help you add some simple functionality directly in the xul file. But from another point of view, xul file is not the best place for Java code.
Q: Can you tell us some of your ideas how to make Luxor development easier?
Vladimir Kvassov: IDE tools always make development easier :) Xul is quite simple, but to make it all work you need some code behind that is now tedious to set up because you always repeat the same steps over and over again.
Q: What do you think is still missing in Luxor?
Vladimir Kvassov: Tools like Luxor should be cross-GUI-platform tools allowing developers to switch between Swing and SWT, for example, easily. Luxor should not just be a "markup language", but a real platform for client-side solutions.
There is a Luxor SWT project available, but it's a
completely separate project.
It's not good. It's better to have luxor-core,
luxor-swing and luxor-swt.
Q: Do you have any ideas on how Luxor fits into the Eclipse world? Do you see a need for an XML UI language for Eclipse, for example?
Vladimir Kvassov: Plugins for Eclipse IDE can make using Luxor easier and can encourage more developers to use Luxor. But in this case a fully functional SWT version will be very usefull.
Q: Do you have any future plans for Luxor?
Vladimir Kvassov: I plan to improve the custom widget project I've contributed to Luxor. Add more widget, add in-xul defined validation. Also, I'm eager to participate in creating client-side solution based on Luxor which I've mentioned above, because it looks like an excellent idea. But I'm not sure if I'll have enough time.
Thanks Vladimir Kvassov.
Links:
It's perfectly clear to me why the XUL community has failed. First, the idea that there is anything to claim victory over regarding the "pure" XUL concept is a fallacy. Let's look at XUL from the perspective of the typical programmer. Where is the form designer to compete with Visual Studio? Where is support for MFC? Where is the support for COM? Where is the support for plug-in's? And that's just the questions from the perspective of a Window's developer. I'm sure the Mac developer has very similar questions. As a developer myself, I wouldn't have wanted to touch XUL with a 10 foot pole, lacking these essential requirements.
- Marc Clifton
Source: xul-talk Mailinglist
Welcome back to the XUI Titan Interview series. Today let's welcome XUI and Carousel mastermind Luan O'Carroll.
Q: Can you tell us a little bit about yourself?
Luan O'Carroll: I'm an Engineer and software developer now working almost exclusively with Java and XML. In the past I've worked on UIs and visualization, right on down to the device driver and hardware level. I am involved in several Open Source projects, but the bread and butter work is generally in commercial applications for Engineering and Financial companies.
I am married and now live and work in Dublin, Ireland.
Q: How did you get started on XUI? Have you tried out any alternative XML UI language alternatives before?
Luan O'Carroll: Originally XUI started out at Xoetrope as a way of making it easier to build Java applications. In the past we had seen many applications built using IDEs and visual designers where the code was treated in a throwaway fashion. We wanted to cleanup the mess usually involved in constructing UI to help avoid the spaghetti like mess that results after a few maintenance cycles and hacking by junior programmers.
We looked at some of the XUL technologies but were put-off by their reliance on JavaScript. We felt that JavaScript was one of the primary culprits for the complexity (of web applications) that we were trying to avoid.
XUI started out using XML for data binding and only then did it add XML for the UI. We were a little surprised at how successful this was and our focus has since shifted more towards XML. The combination of XML and Java works quite nicely in that the programmer can decide what mix best suits an application and can fall back to Java for things that may be difficult to achieve in XML alone.
Q: Can you tell us some challenges you faced building XUI using Java?
Luan O'Carroll: Java has been a fantastic platform for development so I have no complaints there. One of the greatest challenges has been trying to provide full coverage of the APIs and widget sets while trying to maintain a compact core.
We have tried to make it easy to add components and use them via XML or Java and get an application that is as good as if it had been hand coded. We have had quite a bit of success in doing this and of course one of the advantages of using Java is that it's very easy to add custom coding to extend the application.
Another challenge we faced was getting people started. While XUI gets easier to use all the time, some are reluctant to abandon their visual tools in favour of XML. To solve this challenge we created our own visual editor. This has both greatly expanded the scope of the project and greatly increased the range of tasks we can automate and simplify.
Q: Can you tell us how you handle the mapping from XML tags/attributes to Swing classes/properties? Do you use reflection? Do you use hand-coded glue code?
Luan O'Carroll: Well, that depends on the component type. For built-in components we have constructed some wrappers and interfaces that are used to set the attributes. XUI also makes extensive use of factories for construction of components and each factory has the opportunity of handling the attributes directly or delegating to specific components. Reflection then takes over where this leaves off or where no wrappers for the component exist.
Q: What's the hook? Why would anyone use XUI over say good old Java Swing coding?
Luan O'Carroll: XUI greatly simplifies applications, a lot of the UI construction code and the plumbing code needed to connect event handling and data can be handled declaratively in XML. In the MVC architecture promoted by XUI each of the MVC components is cleanly separated from one another making it easy to maintain both the individual components and the application as a whole. Any business logic that is required is much cleaner than is typical of a Java application as much of the work needed to update the UI is handled by the XUI framework. As a result a system constructed with XUI will be smaller, less verbose and easier to maintain than a traditional hand coded application.
Thanks Luan O'Carroll. Check back next week for the second part of the XUI Titan interview with Luan O'Carroll discussing scripting, web-style form submission tags, databinding, stylesheets, how XUI differs from XForms, what the future holds for XUI and much much more.
Links:
Welcome back to episode II of the XUL Titan Interview with Sulu mastermind Son To.
Q: What's your take on CSS support to Sulu?
Son To: I think CSS is a great idea. Sulu does have basic support for it.
Q: Can you tell us why you choose Python as Sulu's scripting language? Any plans for adding support for alternative scripting languages to Sulu (e.g. Beanshell, Groovy, Javascript)?
Son To: Why Python? Because it's an elegant language and because I know it well. JavaScript is an ugly language... Because Mozilla only has good support for JavaScript I had to create SuZilla to avoid writing business logic in JavaScript. I am thinking of using BSF so that other languages can be added, but I don't know too much about BSF.
Q: Any plans of supporting different UI toolkits such as SWT, wx4j or Gnome-Java, for example? Or do you plan to stick to Swing?
Son To: SWT definitely will be supported.
Q: Can you highlight some applications using Sulu?
Son To:
Q: Can you tell us how Sulu differs from alternative XUL toolkits for Java such as Luxor, Thinlet, Vexi or SwiXml, for example?
Son To: I did do some research before starting my own project... I did look at Thinlet and Luxor. The main reason I didn't use Luxor or Thinlet for my POS system is because these toolkits were not faithful to the Mozilla AOM viz The XML content tree is the GUI and manipulating the content tree is equivalent to manipulating the GUI.
Another difference is Sulu strives to be 100% Mozilla XUL compatible. The reason for this goal is that Mozilla is widely deployed and Mozilla XUL is well documented. The less documentation I have to write the better.
jXUL was the closest to my needs, but the code needed major refactoring so it is easier starting from scratch. I also looked at Jazilla which is based on jXUL, but the code sucks (no disrespect to the author intended, I'm critizing the code not the person who wrote it).
Q: What do you think about Mozilla XUL? How does it differ from Sulu? Do you envision Sulu to run Mozilla XUL apps out-of-the-box?
Son To: Sulu will not run Mozilla XUL apps out-of-the-box because Mozilla XUL app depends heavily on XPCOM. Since Sulu is written in Java, there is no need for XPCOM. Java already has a component model: JavaBean. XPCOM is a neat hack for C++'s lack of a component model. It maybe possible to embed the XPCOM runtime into Sulu with JNI, but it's something I don't plan to do in the near future. A lot of xpcom objects are just implementation of functionlity that is already available in the JDK or other java libraries so I see no point in having sulu applications use xpcom objects... but I think it would be cool to do if only for fun.
Q: What's next for Sulu and Suzilla?
Son To: 100% Mozilla XUL compatibility, a good tutorial and user documentation. Good documentation is extremely important. I put off annoucing the project because I was too lazy to write documentation. I still don't have good documentation but gotta start somewhere...
An Eclipse plugin written in Mozilla XUL for building XUL GUI, but before this happens the SWT implementation is needed because there might be problems mixing Swing components and SWT components.
There's a JINI project called serviceUI that uses Factory pattern to allow JINI clients to dynamically create UI for JINI services. Instead of JINI clients downloading a GUI factory from a JINI service, the JINI service can publish a URL of where to get the XUL to render the GUI. SuZilla can be a good substitute for serviceUI.
Thanks Son To.
Links:
We are past the world of generating static snapshots of display and blasting them down to a client.
My not-to-hidden agenda here is simple - dynamic applications should be dynamic on the client. The server should send data - either through web services, database access, or any other wire protocol - and the client should consume that data and generate UI. The model of a server trying to generate the correct display for a client is just broken.
I'm a bit confused by the concern that Microsoft is somehow trying to threaten or take over the web with the introduction of a markup language to program Windows applications. XAML is a new programming model for the next release of Windows, code named "Longhorn". That's it.
- Chris Anderson (Avalon Core Developer, Avalon Architect Team Member)
Thanks to everybody for casting your vote. Now on to the award ceremony and the winner is...
| |||
| Mozquito DENG |  30% | 59 | |
| x-port FormsPlayer | 24% | 48 | |
| Chibacon Chiba | 19% | 37 | |
| Helsinki University of Technology X-Smiles | 11% | 21 | |
| Orbeon Open XML Framework | 5% | 10 | |
| Novell XForms Player (Beta) | 3% | 5 | |
| IBM XML Forms Package (Beta) | 2% | 4 | |
| Oracle Mobile XForms Player (Beta) | 2% | 3 | |
| Ripcord Technology nForms | 2% | 3 | |
| Other (Please Comment) | 5% | 10 | |
| 200 votes total | |||
In the end, we cannot doubt that Microsoft sees their XAML as THE XAML. Creating defacto standards is an important part of Microsoft's strategy. Your product competes -- and right now, you definitely have the first-mover advantage in a way. I guess the question a developer would need to ask themselves is if they're willing to use a particular technology that eventually will be competing head-to-head with a microsoft technology -- on their court, on their platform. Personally, knowing that MS has any plans to do XAML will keep my enterprise development off of XAML-like alternatives. I suppose that's just the power of vaporware.
- Chris Sells (Microsoft Windows 2007/Longhorn Website Editor)
If anyone is interested in how different XML UI language (XUL) formats used by Luxor, Jazilla, xWidglets, XMLFace, Ultrid, MyXaml, Beryl and so on stack up I invite you to check out the XUL Grand Coding Challenge 2004 sample pack that includes more than a dozen XML UI language format samples.
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 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:
Welcome back to episode II of the Thinlet and SwiXml Titan Interview with Kate Rhodes of Caterpillar fame.
Q: How did you stumble onto SwiXml?
Kate Rhodes: I was checking out Theodore to see if I could make my Thinlet life any easier and started poking around on Wolf's site where I encountered SwiXml. I'd like to say that after that there was no turning back but Thinlet is still really great when you need to whip out a quick and simplistic gui app that you know you'll never need to significantly extend. I'd been using SwiXml for a while when I wrote ServerWatcher.
Q: Can you tell us why you decided to rewrite Caterpillar using SwiXml?
Kate Rhodes: I didn't want Caterpillar to be hobbled by the limitations of Thinlet's widgets. At one point in time I had seriously explored taking the rendering bit out of Thinlet and reworking all the widgets as objects but there wasn't really "a rendering bit" to break out and all the widgets weren't anything more than entries in the aforementioned multidimensional array. It would have been such a ridiculous amount of work it just wasn't worth it to me. So, that eliminated Thinlet. I already knew my way around SwiXml by that point, JellySwing was just too much, and I don't know anything about any of the other XUL toolkits for Java. Plus I was really happy with SwiXml. I loved its separation of GUI and functionality. Sometimes it would be easier if I could add in a little more functionality in the XML like Thinlet's argument passing but that's a slippery slope. And keeping it all in the Java code makes things more maintainable down the road.
As far as being hobbled by Thinlet goes, I wanted to render the HTML from the feed entries and there's no way that would have happened in Thinlet. I also wanted Listeners and that wasn't going to happen either. I needed ComboBoxes and Lists that had custom objects in them instead of just Strings because I hate having to do string comparisons and lookup tables to figure out what Object I'm supposed to be working with. And, lastly I needed complex cell renderers to control the colors of items in the main list of entries.
Q: Can you tell us some challenges you faced building Caterpillar 2.0 using SwiXml?
Kate Rhodes: SwiXml keeps everything pretty simple so there weren't many challenges involving it. The only one that comes to mind is the handling of accelerator keys. Macs use the command key and everything else uses the control key. I ended up having to write two XML files, one for mac and one for everything else. I wish that SwiXml would handle that problem for me, and I even went so far as to write a proof of concept class to convert control modifiers to command if you were on the Mac but the problem with that is that it is only reliable when you're working on simple accelerators like "control A" and there isn't really a good way to handle the border cases. I threw out the test spike and just went with the two files approach. There were a variety of other challenges in writing Caterpillar but that was the only SwiXml-related issue I can think of, which is great.
Q: Do you have a favorite scripting language for the Java runtime? Do you want to see scripting pushed more in SwiXml or do you want to keep the code Java only?
Kate Rhodes: I don't, actually. Not too long ago, I came across an excellent breakdown of the annoying syntactical issues in Groovy that basically boiled down to the fact that there are lots of great pieces in it, but existing pieces aren't considered when adding new pieces. This leads to many potential instances of syntactically correct code that just wouldn't work. I wish I could find that blog entry again. I haven't really explored BeanShell or any of the other offerings. So far, though, I haven't really encountered the need for one in my Java work.
Actually, I'm really in agreement with Wolf's goal of keeping scripting out of SwiXml. If someone wants scriptable XML Swing stuff, Jelly Swing is ready and waiting. But, one of SwiXml's greatest strengths is its simplicity. It's almost excessively simple to the point where no one widget can really fail. If you think SwiXml is barfing on your JComboBox but not on your Jframe, it's not. It either works, or it doesn't. When it doesn't, it's because of a misconfiguration. But, even more important than keeping SwiXml simple and reliable is the fact that keeping scripting out of SwiXml helps to enforce the MVC paradigm. Working on applications that fail to enforce that have caused me more headaches than I can count.
Q: What's your take on adding CSS support to SwiXml for styling using rules?
Kate Rhodes: I think it's worth discussing. I can definitely see some benefits to doing it. However, I haven't explored any of the potential downsides to doing it so I can't really say if it's a good idea or not.
Q: What do you think is still missing badly in SwiXml?
Kate Rhodes: I wouldn't actually say that anything is missing badly from SwiXml. It's at the point where the things that most people want to see implemented are things that would be nice but the lack of which isn't really hampering anyone. The two big ones I'd like to see implemented are delegates and the population of things like Lists, ComboBoxes, and Tables from within the XML. There's a posting about delegates and how we plan on implementing them.
The population of objects like Lists has always been an issue with me. It's not terribly high in other people's lists of desired features, but after coming from Thinlet and having it be so easy, to SwiXml where I have to render then lookup my List then give it content, the SwiXml method feels like work to me. Now, if we did implement something like that in SwiXml, the trick would be to do it in such a way that it's wasn't just a bunch of Strings like Thinlet but a list of objects. So, there's the question of how best to implement that.
Q: Can you tell us how SwiXml differs from Thinlet? In a SwiXml world is there still a place for Thinlet?
Kate Rhodes: I think I've covered most of the major differences already. Under the covers, they are worlds apart from each other. As for there being a place for Thinlet I think there definitely is. Thinlet is perfect for simple little apps where you can confidently predict a lack of significant future expansion or where file size is critical. A good example is the Thinlet based database gui tool that is distributed with HSQLDB. Doing that with Swing objects could get big and make it something you'd want to distribute separately but because it was done in Thinlet it's a non-issue to add it in to the main jar.
Q: What's next for Caterpillar?
Kate Rhodes: Coming up next is Bayesian filtering of new entries. As new entries are discovered, they will be compared to entries you've liked and disliked. If the system is really confident you'll like an entry, it will highlight it for you. I've got it running in my sandbox now and it's pretty cool. The problem is, oddly, the lack of spam. People hate spam so they have good reason to hit the spam button in their mail clients. But the thing about news feeds is that they are all good entries. Some of it may not be interesting, but that doesn't make it bad and without that “bad” connotation, people aren't as likely to down-vote something. So you end up with a database full of up-votes, which eventually causes too many things to be highlighted. So, I’ll have to do some automated down-voting and hope that the assumptions work out.
Q: Do you have any future plans for SwiXml?
Kate Rhodes: The SwiXml book I'm writing is the biggest upcoming plan. I'm really looking forward to finishing that and hopefully bring some attention to the project. In terms of code I hope to find some time in the near future to implement delegates.
Thanks Kate Rhodes.
Links:
Welcome back to the XUL Titan Interview series. Today let's welcome Sulu mastermind Son To.
Q: Can you tell us a little bit about yourself?
Son To: I grew up in Philadelphia, PA and still currently live there. I've been programming computers since the age of 10 in a dozen different languages. I graduated from the University of Pennsylvania's Wharton School in 2000. I'm currently an independent contractor working mostly with Java related technologies. I also teach c#, java, python, linux classes. I've been an avid linux user since my high school years (circa 1994). In a previous life, I was also a unix sysadmin.
I've been a Java programmer since 1995 and use it primarily for work, but I make an effort to learn a new language each year because although all languages are isomorphic in the sense that they're all turing complete, each languages has a unique way of solving a given problem in different way. This year my new language is Prolog ... it has help me understand semantic web RDF.
Q: How did you stumble onto XUL?
Son To: I stumbled upon XUL via Mozilla around 1999. I was really excited about XUL when I heard of it because I like the simplicity of html for quickly creating GUI forms, but dislike the contortions one has to go through to create a desktop like GUI.
I think the Mozilla Application Object Model (AOM) is very elegant. Mozilla views the application GUI as a tree. Manipulating that tree manipulates the GUI.
I think XML is abused by falling into the "Golden Hammer" antipattern which says if all you have is a hammer everything looks like a nail. Look at apache jelly for example. Executable XML is a bad idea.
However, Mozilla's use of XML to represent a GUI is a good idea. Since XML can be represented as a tree structure, it is great for representing a GUI because the relationships between the components in a GUI can be represented well with a tree. Since DOM is a standard way of representing and manipulating the XML tree, it provides a uniform and simple way to manipulate a GUI. Since the GUI can be respresented as a DOM XML tree, programmers can use XPath to navigate the GUI. Mozilla doesn't have support for XPath yet, but Sulu does.
In writing swing GUI, often times I would have a component within containers within containers within containers so its easier to layout but navigating the object model to get to that component can be a real pain. This can now be done easily and elegantly with XPath.
Q: How did you get started on Sulu?
Son To: Around 2001, I prototyped a POS (Point Of Sale) system using Mozilla XUL. The Mozilla XUL gui connected to the backend using jabber instant messaging. Writing socket code in C++/javascript to connect to jabber server was a real pain. Then I discovered PyXPCOM which allowed me to write the same code faster and more elegantly in python. However PyXPCOM would break with a new Mozilla release and getting it to work is a black art.
The Mozilla blackwood project promised Java support on par with JavaScript, but that never happened and the project seem to have died.
I wanted Mozilla XUL, but I did not want to write business logic code in C++ or JavaScript. So in septermber 2003, I decided to write an Mozilla XUL rendering engine that will allow writing business logic in java and python.
Q: Can you tell us some challenges you faced building Sulu using Java and Swing?
Son To:
The implementation strategy I choose was to create org.jdom.Element
Adapter (aka Wrapper) for Swing components.
Look at net.openbx.sulu.swing.XulSwingAdapter.
The idea behind this use of the Adapter pattern is that a client
manipulates a Swing component using the org.jdom.Element API.
Manipulating an org.jdom.Element
will result in manipulation of the corresponding
Swing component. This technique worked well when there's a one to one mapping
between Mozilla XUL tags and Swing components for example <button> and
JButton.
Not all xul tags map one to one to Swing components, for example
<splitter>
and JSplitPane.
Mozilla treats the <splitter>
as a component just like <button>
but JSplitPane is not just a component, it's also a container.
Q: Can you tell us how you handle the mapping from XML tags/attributes to Swing classses/properties? Do you use reflection? Do you use hand-coded glue code?
Son To: The mapping from xul tags to XulSwingAdapter classes
is hardcoded in
net.openbx.sulu.swing.XulSwingAdapterFactory although the mapping
should be refactored into a property file.
Q: Can you tell us what Sulu can do today? What works and what needs to be done?
Son To:
You can write fairly complex GUI, but since there isn't a one to one
mapping from Mozilla XUL to Swing components, not all tags are
compatible with Mozilla... for example <table> ...
Mozilla XUL doesn't have a
<table> tag.
To make it compatible with Mozilla, instead of delegating to swing
components, sulu will have to render its own components using Java2D
for example.
The goal is 100% Mozilla xul compatibility, but Sulu isn't there yet. There's lot to be done like RDF.
Thanks Son To. Check back next week for the second part of the XUL Titan interview with Son To discussing why Son chose Python for scripting, what's the state of CSS support, how Sulu differs from alternative XUL toolkits for Java, what the future holds for Sulu and much much more.
Links:
In the new Thinlet and SwiXml Titan Interview series I will interview the movers and shakers of the Thinlet and SwiXml world. To kick off the series let's all welcome Kate Rhodes.
Q: Can you tell us a little bit about yourself?
Kate Rhodes: I'm a self-taught programmer, independent software developer, serial entrepreneur, and an occasional musician with a Japanese nickname. I love to learn new things, solve new problems, and write open source applications.
My most recent projects are Caterpillar and Aspirin. I helped with some research and writing for Professional Java Tools for Extreme Programming and I'm working on a new book about Swing development with SwiXml.
Q: How did you stumble onto the Thinlet XUL toolkit?
Kate Rhodes: I was reading someone's blog and there was this entry talking about this really cool tool that converted XML to a GUI. It went on about how small and fast it was. I went to the Thinlet site then googled for more info and came across a whole slew of blog entries from java developers who were similarly enthusiastic about it. I think most of them were more interested in the idea itself and hadn't actually used it but I thought it was worth checking out so I downloaded it and started playing around.
Q: How did you get started on Caterpillar?
Kate Rhodes: Well, there are a lot of great blogs out there and actually going to the pages of all the ones I like to keep an eye on was just not feasible. I had been using Radio's aggregator a while before but I'd stopped using Radio. All of the other aggregators out there are essentially e-mail clients that check feeds instead of mail servers. Either that or they're web based. The web-based ones never had enough information on a page and the e-mail clones always had too much. It drove me nuts. I know people love some of these clients but they never satisfied me. I wanted something that didn't require me to visually parse folders and figure out for myself which feeds had new entries and which didn't. Neither did I want something that took up the screen real estate that my browser window did. I wanted something simple and small that could just run in the background, be mostly covered by other windows and yet still allow me to glance over at it and see if there's something new.
When it came to actually writing it, I wasn't about to deal with the horrors of traditional Swing coding and the WYSIWYG Swing creation apps like NetBeans always annoyed me because they had huge blocks of code that I couldn't touch. God forbid someone without NetBeans should try and edit it. If you did, you'd loose the ability to ever edit it in the WYSIWYG again. So I used Thinlet.
Q: Can you tell us some challenges you faced building Caterpillar 1.0 using Thinlet?
Kate Rhodes: At the time, Thinlet was one nine-thousand-line core class and another class that extended java.awt.Frame. It wasn't even remotely object oriented. You couldn't add a listener to anything, dialog boxes could not move beyond the bounds of the initial window, stuff like that. The biggest problem of course was the lack of object orientation. At Thinlet's core was an undocumented multidimensional array that contained all the properties of all the widgets you'd rendered from your xml. So, there was no hope of ever adding a Listener to something, or extending one of the widgets, or anything like that. You got the features that were provided and absolutely nothing more. I hear it's a little better under the covers now but I haven't really checked.
But it wasn't all that bad. Thinlet is, and was, an excellent toolkit. It’s really simple to use, it has almost all the widgets you could ever want, and as long as you didn't need anything complex in your UI you'd probably never be concerned about it's limitations.
Q: Was Caterpillar your first Thinlet app? Can you highlight some of your other apps built using Thinlet?
Kate Rhodes: I think Caterpillar was my first Thinlet app. I've also written a simple ServerWatcher app that watches a keeps an eye on your web servers to let you know if they're down or not. While at Virage, I also wrote an app that allowed developers to execute a variety of commands against an XML gateway to a search engine. It ended up being very useful and I started adding more and more features until it eventually started to become a little unmanageable with Thinlet. By that time I'd encountered SwiXml so I rewrote it with that.
Thanks Kate Rhodes. Check back next week for the second part of the XUL Titan interview with Kate Rhodes discussing why Kate rewrote Caterpillar using SwiXml and how SwiXml differs from Thinlet, what's her take on adding scripting or CSS-like styling to SwiXml, future plans for SwiXml and much much more.
Links:
Welcome back to the XUL Titan Interview series. Today let's welcome KaXul/Uxul mastermind George Staikos.
Q: Can you tell us a little bit about youself?
George Staikos: I'm a professional and hobbyist software developer in Toronto, Canada. I have been involved with Linux and open source software for over 10 years now, and have contributed to many different projects, most prominently KDE. I also do consulting and develop software commercially, especially Linux and Qt/KDE related (http://www.staikos.net).
Q: How did you stumble onto Mozilla's XUL? How did you get started on KaXul/Uxul?
George Staikos: It's hard not to run into XUL. :-) Actually I have done plenty of work on Konqueror, the KDE browser. Some of my areas of focus include the SSL layer and Netscape plugin support. With Mozilla, we have a new component model and plugin model and this has caused some problems for Konqueror. We don't fully support the new model in Mozilla (XPCOM and associated technologies). One thing that was relatively straightforward to implement in Konqueror was support for the sidebar modules that Mozilla has. I implemented support for HTML sidebar entries, but soon discovered that many of the sidebar plugins are written in XUL. I picked one (the Google plugin actually), and had a look to see how hard it would be to make it work. What I saw made me think of exactly something I already had available to me - Qt Designer files. Designer is a GUI tool for building user interfaces. The files are stored as XML and converted to C++ at compile time, or interpreted at runtime. This was a perfect match. So, I started to write a tool to convert the XUL XML files to Qt Designer files. It only took a few hours and I already had much of the UI displaying, which was very encouraging. The next step was interaction - the Javascript bindings. This was very convenient because Rich Moore had already written runtime Javascript bindings for Qt, called KJSEmbed. It took another 20 minutes to hook this in, and a bit of hacking to get the bindings to look like XUL's, and I had a functional demo, which I called Uxul ("usual" - meaning "it's usually this easy to make powerful KDE applications"). I split off the engine into a library and called it KaXul. ("casual", or, what I really meant "KDE's Advanced XUL").
Q: Can you tell us some challenges you faced building KaXul/Uxul?
George Staikos: The amazing thing about what has been done so far is that there was no challenge. It was all trivial! The real challenges were tackled in writing Qt Designer, KJS, KJSEmbed, and KHTML. I just glued everything together. There is much more glue to go, unfortunately, and there are some challenges ahead. I have not integrated CSS or RDF, not all the widgets are implemented, and there is still work to do on the script bindings. We already have an RDF and CSS implementation so that should be fairly easy to integrate, but some of the widgets may be quite complex. With KaXul, native Qt widgets are used, as opposed to the rendering that Mozilla does. This poses a bit of a problem since Mozilla can do all kinds of painting tricks that may not be supported in Qt yet. The benefit, however, is that KaXul is -fast-.
Q: Can you tell us what KaXul/Uxul can do today? What works and what needs to be done?
George Staikos: I have shown some demos of various working applets, and actually most of the important widgets are implemented. A simple form based applet should mostly work, but most of the styling and more complicated widgets and data manipulation may still not work.
Q: Can you use KaXul/Uxul as a Konqueror browser plugin?
George Staikos: Shortly after I split the code into the library/application design, Zack Rusin wrote a KPart which loads and executes XUL inline. KParts are effectively Konqueror plugins, so yes, it's quite possible. However KaXul is far from complete, so it is not particularly useful as a plugin yet, in my opinion. One real benefit we have seen is that there is now support in KDevelop for writing XUL apps, and KaXul, via the KPart, is used as a preview/thumbnail tool.
Thanks George Staikos. Check back next week for the second part of the XUL Titan interview with George Staikos discussing the state-of-scripting, SuperKaramba, XML for UIs in the KDE world, the future of KaXul/Uxul and much much more.
Links:
To help the Thinlet community grow I've kicked off a new mailinglist over at Yahoo! Groups chartered for questions, tips & tricks, announcements and more about the Thinlet XUL toolkit that lets you build Java UIs using XML.
I invite you to sign up and help the discussion get going. Postings so far include:
|
|
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 |