The problem of Qt Jambi

I like desktop UI development. Especially I like architecture of Swing, but not so long ago I felt the power of Qt, thanx to Qt Jambi. Now I know that while Qt have some architecture problems it has superior Graphics, more usable widgets, and saves a lot of time on borders and pixels manipulations thanx to it's advanced widgets.

But Nokia decided to stop supporting Qt Jambi, and gave it away to "community". While there are some smart guys on Qt Jambi mailing lists - it is not community yet. And of course I thought about ways to help Jambi survive.

The problem is, I am Java developer, and Jambi was created for Java developers. Most of people on Jambi mailing list are Java developers. It is not very popular among C++ developers because they will not be able to use the result of their work. While Jambi generator is written in C++, and to be able to update Jambi according to Qt changes you should know C++.

Ok, let's assume I am learning C++, to help Qt Jambi to write Java apps using Qt. Well, not Qt itself but bindings of Qt to Java. Do you see the problem? Why should I use Jambi if I already know C++ and I can use Qt itself, without bindings and additional abstraction levels. Then, why should I help Jambi if I will not use it?...

As for me Jambi-like project will not survive without support of some company, and stopping Jambi support Trolltech/Nokia almost killed the project. Now it most likely some parts of Jambi will be salvaged, for example it's extremely cool generator. Maybe in some time I will learn C++ a bit better and will dive a bit inside of Generator sources, and maybe even write something similar in Java if I'll have nothing better to do...

Internationalization in UI toolkits

I have some experience with many different UI toolkits. The most with Swing, QtJambi, GWT, and some with SWT and Echo2. Some of them providing you with their own i18n techniques. Let's take a closer look...

Swing is the most comfortable tookit because it gives you full Java API, with source code, possibility to dive deep into it's internals and no external libraries or dependencies. And it gives you standard Java i18n engine: ResourceBundle. It's simple, powerful and effective. And it's customizable (if you know Java of course).

Qt Jambi gives you Qt's native internationalization engine. It works in other manner than ResourceBundles. API is clean and simple, every Qt widget have method tr(String) where you can specify default value, but not the key as ResourceBundle suggested. From one point of view it's good because you're hardcoding default values, and you will be sure that on any system it will at least show default version. From the other side - those messages can take a lot of space in your source files, plus they are actually keys in internationalization files, similar to properties files. Having keys like this is not very good, because modifying single char you have to modify all resource bundles, while in ResourceBundle you can leave code "as is", modifying only value but not key.

GWT is totally different. It's using properties files too, but you have to extend Constants interface, and add all your keys as String methods to interface. As for me GWT is the total winner, because you have properties files with key-value pairs and IDE support, and you have compile-time safety because you're getting those strings from Java class. In ResourceBundle you're operating mostly with Strings, and simple typo can waste lots of your time, while using GWT approach you must ensure your keys only once, then you're totally saved from any kinds of typos using Java methods to get your internationalized messages.

Qt Jambi first experience

Being long time KDE user and Java developer - I couldn't ignore Qt Jambi release. Of course I downloaded it and tried as soon as version 1.0 vas released. Yes, at first it was version 1.0, built with Qt 4.3. Only after some time Jambi got version as its Qt.

I was impressed even with first version, but it seemed a bit slow and not yet ready for every day usage. But last week there were some news about Qt 4.5 and LGPL license, so I downloaded last available version of Jambi and started few example apps.

And now I am really impressed! I used to think about Swing as fast and developer-friendly when developing some desktop applications, but now I know Qt is really two heads higher in desktop apps development. Jambi evolved and now there is no problem of setting LD_LIBRARY_PATH and other params, you can simply include jar file with Qt and Jambi libs to your classpath.

Then I started a bit bigger project to have complete application in Jambi. As long as there is no fast and stable notepads for Windows I wrote QEdit. You can see sources here.

Now, after I have some first experience with Jambi I can compare Jambi and Swing:

+ Jambi has better shortcuts system. You don't have to work with root panes and actionmaps, you can just ass some shortcut to your action.
+ QStatusBar. I thought about writing something similar for Swing few month ago, but here you can assign statusTip to your action and that tip will appear in status bar on rollover.
+ QSettings. It is much more usable than Properties for storing your settings.
+ QToolBar. Even if it is possible to do something similar in Swing - you will never spend so much time to do it like Qt can. You can download and run QEdit to see how you can move toolbars to different parts of main window and this position will be saved between sessions.
+ QFontDialog. Almost every Swing application have to implement Font Chooser themselves, while QFontDialog is almost the same in every application.
+ Components already have their scrollbars, you can just enable or disable them. I can't remember at least one case when you don't need to wrap JTextArea into JScrollPane.
+ Wide range of supported graphic formats and components adjust size of graphic automatically.
- Jambi can't see if wrapped C++ classes extend some other classes.
- Jambi QFile is very slow and locking file. I don't like when File object locks real file on file system, only io operation should block it. So don't try to use Qt Jambi for all your tasks at once.
- No way to extend or customize QFileDialog. Even style is not applied to QFileDialog.
- Signals in "action system"... It's just wrong in Java. Thanks that application fails on first start but not in time of invocation if something is wrong in source.
- You can't give both small and large icon to QAction. After providing 22x22 icons some of them looks too smooth in main menu.
- Lack of documentation. If you are not enough documentation and examples from Jambi distribution - even Google will not give you a lot.
- Looks like all the work is performed in blocking QApplication.exec() method. I can't find is there anything like SwingWorker for Qt or Jambi...
- There are lots of possible pitfalls when you are writing huge application, and Swing "experience base" is huge enough to help you in almost everything, plus Swing is pure Java where you can debug everything you want. But where to go with Jambi? There is support in Trolltech for commercial version...