2009-02-26

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...

2009-02-16

There is a myth that native is much faster than java. Lots of frameworks speculate this myth and using lots of native methods from java. But how often they are implementing same functionality and check native against true-java? They are often diving so deep in own fantasies about native performance that it is almost religion, they just don't accept facts. But how much it takes to JVM to invoke method from native library? And how much is it comparing to raw java interpretation?

I don't like to use things that I don't understand. Almost all methods from Math class is native, and I can't see sources of that classes. There are some functions that would be hard to implement, like Math.sin() or Math.cos(), but there are some easy-to-implement methods. This time I need functionality of method Math.pow(). It is not hard to implement it in java:

2009-02-12

Games Workshop produces two kinds of kits - metal and plastic. I hate metal kits - it is hard to convert them, hard to keep them unbroken, hard to repair them if they're broken. And Chaos Dreadnought is metal model.

Modeling Plastic Chaos Dreadnought!
All you need - Plastic Space Marines Dreadnought, few Terminator torso bits and few decorative chaos bits. And may be some greenstuff.