Yay, the latest Qt Jambi pre-release went out today. In addition to the regular supply of bug fixes and new example code, there are some changes to integral parts of the API and semantics in this version, and also some major improvements to Qt Designer and the Qt Jambi Eclipse Integration. It also contains bindings for the XML and Network modules, meaning that all relevant parts of Qt are now accessible from Java.
Qt Jambi Designer
In previous Qt Jambi releases, we’ve been using the original Qt Designer without any modifications. Since large parts of Qt Designer are written to be language independent, we’ve been able to generate Java code based on the original C++-based
.ui files that Qt Designer has produced. This has worked to an acceptable degree, but it was definitely far from ideal, both for technical solutions and for the user experience.
For this beta, we wanted to have a complete Jambi-interface in Qt Designer. We wanted to give Qt Jambi developers the same possibilities in Designer as Qt developers, and we wanted Designer to feel completely like a tool for creating a Java GUI.
The issues in previous versions was, specifically:
These issues have all been addressed in the Qt Jambi Beta, using a slightly modified
.ui format (
.jui files), and a couple of Designer plugins.
You can now use any icons located somewhere in your class path, and the correct paths (relative to the class path) will be generated for them in the resulting code, so that they can be e.g. bundled in .jar files when your application is packaged. You can write complete custom widgets in Qt Jambi and import them in Designer, where you will be able to modify their custom properties, connect their custom signals and slots, and preview them exactly as they will appear in the finished application. And finally, Java syntax will be used throughout the application.
How to use the new Qt Designer
In order to use the new Designer as a standalone application, you will need to set your
QT_PLUGIN_PATH environment variable to point to the
path/to/jambi/plugins directory beforehand. To make this a little bit simpler, there is a command line script (
designer.sh) which sets the right environment and starts up Designer for you.
The Eclipse Integration will attempt to load the plugins automatically using the path you set as the location of your Jambi installation. The plugins should be initialized when you open a form, and the resource browser and widget box will be populated based on the settings of the current project.
Some happy news for users of the Qt Jambi Generator! In previous releases, we’ve had a very minimal one-class example for use of the generator. For the beta, we’ve written a fresh example where we’ve attempted to use as many of the generator features as possible. We’ve also written documentation for the example where we propose what we believe is an efficient way of working with type systems for the generator, and where we’ve tried to pinpoint common pitfalls.
In order to use the generator with Qt Jambi, you should get our special Qt 4.3.0 snapshot made for Qt Jambi and set your
QTDIR to this. This is needed because Qt Jambi is based on a stable branch of the unreleased Qt 4.3, and it is not guaranteed that it will be compatible with regular snapshots of Qt. Use our snapshot to keep out of trouble 🙂 More about this on the release page.
Once this is done, you should be able to run the
generator_example command line script, and then you will have a nice little (emphasis on little) game with which to play around.
Things to be aware of for existing users
In this beta release, we have made some changes to the library which may affect existing applications, so current users of Qt Jambi should be aware of them. The most relevant change in this respect is that objects of all types are now automatically garbage collected when the objects become unrechable.
In previous versions, we had a distinction between “normal” types and subclasses of
QObject is the class used for event handling, and the superclass for all widgets in Qt Jambi. We believed objects of this class would live in a hierarchy, and designed Qt Jambi so that the programmer would have to explicitly dispose the root of such hierarchies. However, feedback has indicated that this pattern can be confusing and lead to unnecessary memory leaks, so in the beta, we have removed the distinction, and any object without a parent will now be collected and disposed automatically. This means that you will have to keep a reference to the root in a hierarchy for the tree to remain in memory. Usually this is already the case, but be aware that you may get exceptions if your code relied on memory leaks to work properly.
In addition, we have detached signals from the
QObject class. Previously you would have to subclass
QObject in order to have signals in your class. We realised that, as QObject is a relatively heavy class with special rules for multithreaded programming, this design worked poorly for short lived objects. In the beta, in order to use signals in your class, you should extend the class
com.trolltech.qt.QSignalEmitter. Existing code will work fine, since
QObject is a subclass of
QSignalEmitter, but if you are only using
QObject in order to get signal support, be aware that extending
QSignalEmitter instead will be more memory efficient.
A third thing to keep your eyes open for is initialization of signals. Qt Jambi would previously initialize all signal objects automatically, but we have since decided that this magic was too unclear and not really correct in the spirit of the Java language. If your code depends on this feature, you can expect to get some null pointer exceptions that need to be sorted out.
You should also be aware of the improved error checking. If your code has certain types of hard-to-find bugs, you can now expect to be alerted of them, either through runtime exceptions or warnings printed to stderr. It should be much easier to stabilize complicated code using the Qt Jambi beta.
Finally, you should look at the changes-file contained in the root of the package. There are some renamings and changes to API that may affect compilation of your project. They should easy to debug, but if you e.g. are using the
QNativePointer in you application, you can expect the API your are using to have changed to something which is easier to use.
Feature-wise, this is a big release for us, and I hope people will be happy with the changes. Don’t forget to sign up for the qt-jambi-interest mailing list if you haven’t already. We will do our best to be quick in addressing any issues and answering any questions that are raised on that list.