It’s taken a little longer than expected, but the nice and polished Qt Jambi 4.5.0_01 packages are finally ready for download on Qt Software’s server. As usual, there are both source and binary packages available, but to match the new licensing of Qt, the GPL packages have been replaced by LGPL packages this time around. Read the press release.

As has been announced earlier, this will be the final feature release of Qt Jambi from Qt Software. Patch releases and support will continue for the next year, but when Qt 4.6 comes out, Qt Software will not be releasing an official Java version. Part of me is sad about this, sure, but part of me is excited as well, because with the new licensing terms, I think there is a real chance that Qt Jambi can become a success in the wild and continue to grow, maybe even at a quicker rate, in both stability and popularity and excellence, after the official support for it has ended.

This success relies on one thing in particular: Our ability to establish a community of volunteers who want to maintain and use Qt Jambi when its official life as a Qt Software product ends. Having this community is vital. It’s what will make or break Qt Jambi in the future, so we want to do what we can to get that going.

The first step is of course to license the product under the LGPL. This means that both open and closed source users can continue to use the product.

The second step we are taking is to host a public git repository for Qt Jambi. People who wish to contribute to Qt Jambi can clone the repository and request merges to master when they feel their changes are ready for it. We will maintain the public repository for the coming year, and integrate changes that are deemed safe/tested and that pass whatever legal criteria might be required (I don’t have details on this yet, so lets call everything subject to change.)

As a third measure, we have made sure that the repository is complete, meaning that it contains the revision history from the very moment we took Qt Jambi out of research and made a product branch of it. The inner workings of Qt Jambi are complex, so being able to do a “git blame” and find the change description that explains exactly why, for instance, a particular function requires a recursion guard or a mutex lock, is a requirement when new maintainers take over control.

Fourth: As many of you know, we have always tried to keep a direct line of communication with users. So far this has been using the Qt Jambi Interest mailing list, and that will continue unless the community takes its discussion elsewhere. In addition, I want to make available as much information as possible on the processes we have established and experience we have gained while working on Qt Jambi for the past years. My current thinking is to put this here on labs in the form of blogs, but as the amount of information grows, a wiki might also be in order.

Finally, if you are interested in contributing to Qt Jambi, and you have any questions/ideas on how we can make it a success as a community project, please sign up to the mailing list and let us know. Also, clone the repository at http://gitorious.org/qt-jambi and start hacking!

With the announcement back in January of Qt going LGPL there was a small piece of information that slipped though the cracks of the wider news reporting, namely the fact that we were planing on opening up our repositories and development model. The first major phase of this work is now complete, and we are proud to present the results:

Launching a public repository is a big milestone for us in Qt Software, as it allows us to work closer with contributors, strengthens the the link to the community, and gives that warm and fuzzy feeling of working with open source. Granted, our releases have been open source, but our development model has not. Although you could always send us patches by mail or through our bug tracker it was a cumbersome process, requiring a faxed copy of a copyright-assignment form from the contributor, as well as a lot of manual labor on our part.

Our goal with the new site is to make this process as simple and welcoming as possible, and that’s why we will no longer ask for copyright assignment. Instead we ask contributors to grant Qt Software a non-exclusive right to re-use and incorporate the code as a part of Qt, handled by a one-time online click-through the first time you submit code for inclusion in Qt.

Maintaining your patches to Qt and working in parallel with our development is also very easy thanks to the features of Git and Gitorious. Just clone the official Qt repository, push you changes to your newly created clone, and submit a merge request for our reviewers. Everything happens on the site. (For more information on how to contribute see the Qt project wiki).

Choosing Gitorious as the basis for our public repository hosting was the result of both chance and strategy. As previously blogged about we switched to Git for our development almost a year ago, and as part of the move we installed Gitorious on one of our servers to manage our many projects and repositories. We soon started hacking on the code to add various features and tweaks, and quickly fell in love with the codebase. Fast forward a couple of months to the LGPL and public repository planning, we started playing with the idea of using Gitorious for hosting the public site too. At that point we realized that the author and maintainer of Gitorious, Johan Sørensen, was actually living in Oslo, so we invited him to our offices for a chat. One thing lead to another, and we ended up funding Johan and one of his colleagues to work on Gitorious for the past four months. The new Gitorious site is the result of that work. All of our changes have been pushed upstream, and we will continue to invest in further development of the site.

So what are the features of the new site? Johan has already enumerated these in full on his blog, but a few highlights are in order:

• Team support (easier to manage committers and project ownership)
• Asynchronous task processing (no more lag when pushing)
• Visual tweaks (including breadcrumbs and pretty URLs)

We are also looking at improving the whole review process, for example by adding line-based commenting to merge requests, bug-tracker integration, and automated testing of contributions, but these are ideas still in research. Stay tuned for updates on this.

So, what are you waiting for? Create an account on Gitorious, start cloning, and join the exciting development of Qt!

Good luck!

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.