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:

• Luke @ http://www.getopt.org/luke
• Concord Consulting Group/My Work Base @ http://www.myworkbase.com
• Thinlet @ http://www.thinlet.com