Chronicle of the Xul Revolution
|
|
|
Chronicle of the Xul Revolution |
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:
A reason why I'm hesitant to select SwiXml for projects, is that SwiXml depends on one person, Wolf Paulus. What if he abandons the project? He seems to have many things going on, is SwiXml well maintained?
Posted by: Carter at June 29, 2004 08:11 PM|
|
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 |