A while back we announced the research project Qt Jambi AWT Bridge which allows you to mix AWT/Swing components and Qt widgets in the same window on Windows and Linux.

There were a few issues with the original version. The main problems were the fact that your window would be deactivated by the window manager when you clicked inside an embedded widget, some issues with unnecessary whitespace around the embedded components when you embedded AWT inside of Qt, and some people experienced a race condition which caused the embedded widgets to sometimes disappear.

The project has now largely been rewritten to be more robust, and both the window activation issues and whitespace issues have been resolved. If you sync the latest version from Subversion, you should be able to see major improvements. There are still some issues with keyboard focus (tabbing between the application widgets and the embedded widgets) which we are trying to resolve.

The sequence of commands to build has also changed. Please follow the following steps in order to build the project from source (for users of a binary package of Qt Jambi, we will try to get binaries for the bridge up at some point.) The following steps will only work if you have also built Qt Jambi from source.

Windows (Replace “nmake” with the “make”-application of your choice.)
set JAMBIDIR=\path\to\jambi\source\package
set JAVADIR=\path\to\java\sdk
.\generatorstep.bat
qmake
nmake

Linux
export JAMBIDIR=/path/to/jambi/source/package
export JAVADIR=/path/java/sdk
./generatorstep.sh
qmake
make

That should take care of building the native binaries. Then put Qt Jambi in your class path and compile all the .java files:

javac com/trolltech/research/qtjambiawtbridge/generated/*.java
javac com/trolltech/research/qtjambiawtbridge/*.java
javac com/trolltech/research/qtjambiawtbridge/examples/*.java

There are two examples in the com.trolltech.research.qtjambiawtbridge.examples package: QtInAwt and AwtInQt. These are the same as before, and show, respectively, how to integrate a Qt widget in an AWT frame, and how to integrate an AWT component in a Qt widget. Here’s a screen shot of QtInAwt:

The window here is handled by AWT, the two input fields and labels for the name are Swing components, and the entire bottom part is a layout created in Qt Jambi.

Please go to the project homepage for more information.

So the time is finally here. Qt 4.4.0 was released a few weeks ago and as promised Qt Jambi is right behind. A lot of effort has gone into this one, in addition to supporting all the new Qt features, like Phonon, Webkit, Widgets in Graphics View, XQuery and Qt Concurrent, we also have a seriously improved deployment system, JDBC support and a compile-time checked signal-slot approach for the paranoid. Its a good time to be a Java developer I tell yah! We already mentioned all the featuers in the Qt Jambi 4.4.0 Preview Blog so we won’t repeat ourselves here… (There is a danger in linking to eskils blog, as it links to others again, which again links to others, which in the end proves to be a fairly complex graph, but then again… we are engineers and like that kind of stuff)

Under the cover we’ve also done quite some work. We also did an overhaul of the garbage collection and memory management subsystem and hopefully ironed out all the bumps and dents. We’ve also done some work on the build system, so that our users that build from source have a bit more substantial buildsystem to work with. Previously it was a complex install document, which has been replaced by a simple ant command which just does it all… I was very happy to see that the deployment system & ANT build scripts works well enough for the webstart to look like a plain, normal webstart app:

<resources>
<j2se version="1.5+"/>
<jar href="qtjambi-examples-4.4.0_01.jar"/>
<jar href="qtjambi-4.4.0_01.jar"/>
</resources>

<resources os="Windows" arch="x86">
<j2se version="1.5+"/>
<jar href="qtjambi-win32-msvc2005-4.4.0_01.jar"/>
</resources>

No magic nativejar or anything like that, just the qtjambi-win32-msvc2005-4.4.0_01.jar in the classpath and that is enough to load it, jpeg and svg plugins and all. The good thing is that the files included in the webstart are produced directly by the ant script with all dependencies etc set up properly… (well… almost properly, it took us an evening last week to get it really working, but now it works properly). Because of the fixes to memory management and deployment Eskil and I got these offical diplomas:

So, what more is there to say… Try the webstart with its new demos, download the packages and start hacking!

-
The Qt Jambi Team

The Qt 4.4 beta was released on February 26th, and, true to form, the corresponding Qt Jambi release comes a couple of weeks later.

In honor of the 4.4 release, we’d like to go through some of the new features you should look out for.

WebKit integration
WebKit is an open source web browser engine which is the basis of, among other things, the Safari web browser on Mac OS X. The engine has been integrated in Qt, and is available to Qt Jambi programmers in the package com.trolltech.qt.webkit. This means that you can easily integrate web content in your applications, and jump on the whole acronym-bandwagon by using AJAX methodology in your code. Håvard did a whole blog teasing this feature a while back, so instead of rewriting all that, we’ll just point you in the right direction. Benjamin wrote a blog a few days ago that goes into more detail, so take a look at that as well if you’re interested. On the WebKit Integration announcement page you’ll find lots more information, and some very cool videos that illustrate some of its awesome powers.

Multimedia framework
Qt and Qt Jambi 4.4 gets full-blown multimedia support through the Phonon framework adopted from KDE. This gives easy access to playing and manipulating movies and music in all the nice file formats for which the underlying media framework has codecs. The framework defaults to using Gstreamer (Linux), Microsoft DirectShow (Windows) and Quicktime (Mac OS X). There’s also this teaser blog about Qt Jambi and Phonon with an example for those interested.

New deployment system (Qt Jambi specific)
While we’ve always been recommending a .jar based deployment method, we’ve required people to build their own .jar files containing the necessary native libraries, and a meta-info approach to specifying which dependencies exists in a given project. This system has proven not only to be easy to misunderstand, but to have some fundemental flaws that could cause crashes and general discomfort if you did it wrong. In fact, in order to deploy previous versions on Mac, it was required that you were either Eskil, Gunnar, or someone with direct e-mail contact with either of us. In Qt Jambi 4.4 we’ve hopefully fixed this once and for all, by defining a default .jar based deployment system which avoids problems with mixing libraries and in which deploying to a different platform is as easy as replacing a single platform specific .jar file. In fact, if size is irrelevant, it’s possible to ship a single distribution of your application which will run on all platforms, as long as the platform .jar file for the given platform is in the class path when running the application.

If you are building from source and require extra libraries to be included, this can be achieved simply by editing the ant script.

JDBC support (Qt Jambi specific)
A drawback in our SQL framework in previous versions of Qt Jambi has been that you needed to have access to a Qt/C++ source distribution in order to use it. The reason was that we could not provide binaries that were compatible with all the different database drivers out there. In Qt Jambi 4.4 we support the Java DataBase Connectivity API which is the industry standard for database access in Java. This has been available on Trolltech Labs for a while, but now it has finally been integrated in Qt Jambi and is available in the com.trolltech.qt.sql package. Gunnar wrote a blog about it back when it was put up on labs.

XML patterns
XML support has been greatly improved in Qt and Qt Jambi 4.4. An example for this is the added support for XQuery 1.0 and XPath 2.0. In Qt Jambi, it is available in the package com.trolltech.qt.xmlpatterns. For more information, see Frans’s blogs about the C++ version of the API.

Qt Concurrent
One of the greater challenges in terms of mapping C++ to Java was the Qt Concurrent framework. This is a set of classes and functions that will help you parallelize tasks (e.g. to optimize for multicore cpus) without having to worry about many of issues the ordinarily related to multithreaded programming. In C++ it uses a lot of very language specific constructs, like templates and function pointers, making it hard to automatically map the API to Java. Indeed, we had to write part of the bindings layer by hand, replacing the use of function pointers with interfaces instead. We also implemented support in the Qt Jambi Generator for mapping C++ template classes to Java’s generic classes (under certain conditions) in order to get the correct API for classes such as QFuture. The underlying, generated code for binding this class uses a general, reference counting wrapper for java.lang.Object where the Java API (and the original C++ API) uses a generic parameter. Since generics in Java is a static, syntactic mechanism, there is no need to worry about it in the JNI code.

Other stuff
There are many more changes in Qt Jambi 4.4, bug fixes and new features. In order to get an overview of them all, you should see both the change logs for Qt Jambi 4.4 and Qt 4.4 (which will be out when the release is final.) From the top of our heads, we can mention an enhanced network API, QMetaObject introspection for Java objects, and numerous improvements to Designer.

–
Gunnar and Eskil

The Qt Jambi team has, as have all devs in Trolltech, been busy preparing two separate releases the past few weeks slash months (Qt Jambi 4.3.4_01 and Qt Jambi 4.4.0_01.)

In the midst of this, someone reminded me that I promised I’d post a blog when we added prebuilt Windows binaries to the repository for QtJambiAwtBridge. This has now been done (Gunnar actually added it a while ago), so it should be possible to use the bridge without having a Qt source package ready. It’s in QtJambiAwtBridge lab in the directory “prebuilt”. For maximum compatibility, please use the binary together with a Qt Jambi binary package.

As far as the code goes, not much has happened to the QtJambiAwtBridge, and there probably won’t be much time to work on it until the two upcoming releases are ready and out the door. At that point, I will sit down and see what I can do about the outstanding issues (mainly regarding focus handling and window activation as far as I know, please post a report if you find other problems.)

Since I’m already posting this, I might as well add that Qt Jambi JDBC has been target of a few bug fixes lately: The standard Java SQL types are now automatically displayable and editable in views of the database models, a bug has been fixed where the contents of cells in a view looking at a JDBC-based model would sometimes rearrange or blank out, and finally: We’ve added a few changes that greatly increase the number of JDBC drivers with which we are compatible. We previously required that the underlying driver supported returning autogenerated keys, which is optional in the JDBC specs, and there was also a bug with certain unforgiving drivers when trying to do random access on the result sets. One of the drivers for which these bug fixes adds compatibility is the pgsql one.

As far as Qt Jambi JDBC goes, the driver will be integrated into Qt Jambi 4.4 and become permanent part of the Qt Jambi library.

I planned on writing a blog about some of the work we’ve done on deployment for Qt Jambi 4.4, but I realized when writing that the memory of “Why the !”#!%!§ doesn’t it work on that linux box!” was still to fresh in memory and I was simply to upset to write anything about it. Some time has passed and a Finnish company came along, putting things into perspective, so now I can calmly share some thoughts on deployment with you…

Deploying C++ software across multiple platforms can be rather painful, partially because Qt doesn’t really provide any tools to help out. We do provide deployment guides for the various systems, but our users still have to learn and understand all the details. It doesn’t “just work”. Why? you may ask…

On windows life used to be pretty simple, you ship your .exe and .dll’s together in the same directory together with the right runtime libraries and you’re set, alternatively build with Visual Studio 6.0 and almost don’t worry about it at all. This was until a certain company introduced manifests as a way of describing dependencies between libraries and executables. It does sound great on paper, but in practice it really doesn’t work, especially if the executable (java.exe in this case) is built without manifest. As a direct effect, you are now required to either preinstall the runtime libraries in the WinSxS folder (via installer) or duplicate the runtime libraries in all directories that contain executable code, such as /lib, /bin and /plugins/…, meaning that each plugin directory needs to have its own duplicate copy of the MS runtime libraries. Should you choose to not follow these rules, the application won’t run…

On Linux we have the problem that the various systems are vastly different. Some boxes didn’t have Xinerama installed, some have libstdc++ version 5, some have version 6. Some have Qt installed with debug symbols and some have Qt 3 installed. Basically there are a lot of variables and the only way to go about this is for our users to ship a complete bundle containing all dependencies. In Qt 4.4 we changed Qt in some places to support dynamic resolving and loading a few X libs which reduced the dependency table a bit. In Qt 4.3 our binaries were built without Xinerama for instance, to make them run on certain systems. Since Qt 4.4 we support Xinerama if its available on the deployment machine out of the box.

On Mac OS X, things are immediately rather bright, save for this minor issue of install_name… Install names describes, among other things, the location of dependent binaries. When build Qt libraries in the default way, the dependencies will be absolute file names to things like ~/qt/lib/libQtCore which doesn’t work on a target machine. In Qt 4.3, we patched our prebuilt binaries to contain relative paths to where they were loaded from, but our users who built Qt Jambi themselves would have to do this too, which is a rather messy process. Why not simply use frameworks or bundles, and the reason is simply that we want to have a means of deployment that feels java-like and works identically across all platforms, so our users can understand this, and not care anymore about deployment on any target system. Frameworks and bundles are pretty far from that…

In addition to these platform spesific problems, we have the issue that in Java, you normally relate to .jar files which are portable while native libraries, such as the Qt C++ libraries, have to be available on the file system for the application to load them. These native libraries need to be available through the java.library.path, which equals the environment variables PATH on windows, LD_LIBRARY_PATH on Linux / UNIX and DYLD_LIBRARY_PATH on OS X. In Qt Jambi 4.3 we did provide some magic to automatically find the libraries without the environment variables, but ideally you want to relate to just .jar files, right? Well… With Qt Jambi 4.4 you can!

What we ended up doing is that we created some ant tasks to help us and our users out. The way it works is that we have build tasks for running qmake, make and juic and a task for bundling. The bundle task will make sure the binaries have the right install name in place on Mac OS X and on windows it will copy the manifests and runtimes into the right subdirectories. The result of this is a .jar file, for instance qtjambi-win64-msvc2005-4.4.0_01.jar which contains the correct native binaries for Windows 64bit and when its in the classpath, it will just work. Similarly it will create a qtjambi-linux32-gcc-4.4.0_01.jar for linux, and if you put both the two in the classpath, it will pick the right one.

This makes it extremly easy for the people that deploy a plain Qt Jambi application, as they simply include a .jar file in their classpath and it works. The slightly more complex scenario is where you generate some code using the Qt Jambi Generator and want to deploy that. The process is rather similar, you simply add your binaries to the bundle task and you get a .jar file containing Qt Jambi native libraries and you own native libraries and once again you are set. We still support loading binaries from the environment variables listed above, which is handy for development and for starting Qt Jambi from a C++ app, like Qt Designer, so hopefully, we covered most scenarios.

We hope to have the Qt Jambi 4.4.0_01 Beta out by the end of february, so I’m looking forward to getting your feedback on this…

As you might have seen, Nokia has announced to acquire Trolltech. An open letter to the open-source community can be found here.

This is exciting news for everyone. As you can see in the letter, our commitment to the community will not be affected by this. Qt development will continue in the same way as we’ve always done it.

There is almost always room for a browser in a desktop application. You might need to show some help pages, documents, formated source code, xml or what not. And then you need a browser.

Up to now these browsers have often been limited to show some simple html. But with Qt 4.4 and Qt Jambi 4.4 we will have a proper WebKit integration and voila.. you have a full fledged web browser at your fingertips.

Let’s have a quick look at what it can do!

Oi, that looks promising.. Let’s have a look at the source code to this example that has been written using Qt Jambi.

import com.trolltech.qt.core.*;
import com.trolltech.qt.gui.*;
import com.trolltech.qt.webkit.*;       

class HelloWebKit extends QWidget {       

    private QWebView browser;
    private QLineEdit field;       

    public HelloWebKit() {
        field = new QLineEdit();
        browser = new QWebView();       

        QVBoxLayout layout = new QVBoxLayout(this);
        layout.addWidget(field);
        layout.addWidget(browser);       

        field.returnPressed.connect(this, "open()");
    }       

    public void open() {
        String text = field.text();       

        if (text.indexOf("://") < 0)
            text = "http://" + text;       

        browser.load(new QUrl(text));
    }       

    public static void main(String args[]) {
        QApplication.initialize(args);       

        HelloWebKit widget = new HelloWebKit();
        widget.show();       

        QApplication.exec();
    }
}

That wasn’t difficult was it But can this actually render some normal webpages.. yes it can. So here goes another screenshot

It’s been a happy few weeks. Right before the Christmas holidays, Qt Jambi was nominated for the Jolt awards (”the Oscars of the industry”, we’re more or less nominated for an Oscar, tell your friends), and, as you may well be aware, Qt 4.4 will ship with the excellent Phonon Multimedia framework as announced in the beginning of December.

For those of you who hadn’t heard, the Phonon framework is a cross-platform class library which can (among other things) enable your application to play any media files supported by a system backend. By default, this backend is Microsoft DirectShow on Windows, GStreamer on Linux and QuickTime on Mac OS X.

Now, where it makes sense and is possible, we make the Qt Jambi APIs “identical” to the Qt APIs. This means that if you have experience with one framework, you should be able to learn the other one with very little effort, granted, of course, that you already know both programming languages well enough. In fact, porting examples from Qt for C++ to Qt Jambi (which I’ve done a fair number of times by now) is primarily a search/replace of arrows to dots, and is so simple it’s comparable to what scientists call “doing nothing.” The latest addition to Qt Jambi 4.4 is the com.trolltech.qt.phonon package, and this blog is mainly a celebration of the fact that I just finished porting the Media Player demo from C++ to Java, and that it works.

So, without further ado, here’s a brief low-res video of what you can expect. It shows the Qt Jambi media player running through Eclipse, the application playing a movie, and me moving some sliders to alter the brightness, contrast, saturation etc. of the movie stream. I forgot to turn off my microphone, which is why the audio is terrible, so please disregard that.

That’s it. I hope you find it impressive and I hope you will have some use for it when Qt 4.4 and Qt Jambi 4.4 are out later this year.

Qt Jambi is all about breaking away the barriers between Qt in Java and Qt in C++. In fact, ideally you should be able to sit inside of either language and throw anything you want over to the other side, and somewhere along its parabolic path over the wall, this thing should magically transform to whatever the destination expects it to be. In that sense, Qt Jambi is kind of like Shakespeare futilely trying to marry a Capulet with a Montague (a plague o’ both your language designers!)

Definitely, there’s a lot of drama and tragedy involved, and there are certainly always things you can throw over that wall which anyone sitting on the other side will consider mysterious and meaningless. Most of the time, though (and the emphasis is very much on “most”) this works. Despite the many differences between the two programming languages, the APIs in Qt Jambi are almost identical to the C++ APIs, and, most importantly, the intention of the APIs is intact.

Right now, though, I want to focus on one thing which has so far not been supported: the Qt meta-object system. The meta-object system is an extension to C++ which adds introspection, dynamic method invocation and similar concepts to the language (which otherwise lacks any such features.) It is also the basis of the signals and slots inter-object communication mechanism which is featured heavily in both the Qt and Qt Jambi APIs.

We never implemented an equivalent of the meta-object system in Java. The main reason for this was, quite simply, that it wasn’t necessary. Java already has a more or less complete reflection API with all the meta-info you could ever ask for. Thus, we decided to implement signals and slots in Java on top of Java’s reflection API, and create a small binding layer in between which ensures the grittiest of the details work (emitting a signal in C++ emits the equivalent signal in Java etc.)

Still, we lacked one gritty detail: In some cases, Qt relies on introspecting objects through the meta-object system without going through the signals and slots mechanism. An example of this is when you register a mandatory field in a wizard. In this particular case, Qt Jambi currently does not support custom widgets as editors for the mandatory fields. There are very few places in Qt where this is actually relevant, but even so, in principle it’s a pretty big gap, so following our quest to fill as many holes as possible, in Qt Jambi 4.4 we will introduce the fake meta object.

As you can see from my illustration of what a screen shot of the fake meta-object would look like, if it was indeed possible to take a screen shot of it, it is not all that different from the regular meta-object. The main difference is that the fake meta-object is generated at run-time rather than be a statically compiled unit, and also that it may at some point rob a train using only dynamite and a hot air balloon. We generate the meta-object on request, and only once per class, and only for user subclasses, as all the C++ classes will already have proper meta-objects of their own. For compatibility with the general expectations Qt has to meta-objects, we also convert all Java signatures into C++ signatures before stuffing them into the fake meta-object. Of course, not all Java classes have C++ equivalents known to us (any class featured in the type system used to generate the Java code is handled automatically), in which case we use the JNI type jobject as a general fall back, meaning that you can potentially use this together with other JNI-based frameworks.

So, in conclusion: In Qt Jambi 4.4 you can, among other things, look forward to cool-looking beards and even more complete mappings of the Qt APIs. The fake meta-object also allows us to remove a bunch of hacky hacks e.g. to make Java classes blend in with Qt Designer (you don’t want to know) so expect it to give a general boost in stability and readability as well. We really like it, hope you will too.

Some time ago a question popped up on qt-jambi-interest about how Qt Jambi would work together with jython. The main problem was signals and slots as our string-based approach doesn’t map to well into the world of interpreted languages on top of Java. I sat down some time ago and got jython to work pretty smoothly and the code has been sitting on my disk for a while, but I finally got around to making a project out of it. Below you see a small painting application I created.

The code for the signal / slot binding is available here:
http://labs.trolltech.com/page/Projects/QtJambi/jython

Happy coding!