So we reached another beta release of Qt Jambi, press release here.
This is, at least according to plans, the final beta before we release
the final version later this summer. The team has done a tremendous
job in improving this version from the previous and I’ll mention a few
things in detail later, but first of all, I’d like to mention that
this release is dual licensed.

Thats right! The beta2 version of Qt Jambi is released under the preview license
and also under the GPL license. We spent a some time getting this to
work together with Apache Harmony Open Source Java SE in addition to
the Sun JDK which we already had. For details on the law, look in the faq.
The GPLing includes both the library and the Qt Jambi Generator, and I
hope you’ll find this to be good news..

So what other things has happened since the last time… In the last
release we enabled object garbage collection for all objects, which
resulted in a number of reports from people that gui elements, like
toolbar buttins and menu items, were disappering. In this release we
introduced a reference counting scheme that should minimize the chance
for this happening…

We also got rid of most of the poorly named operator_Xxx functions and
tried to replace them with more intuitive functions. For instance
QDataStream.operator_shift_left(byte []) has become
QDataStream.writeBytes(byte []). The generator also detects a number
of operator== and operator which is used implement the equals()
function and the java.lang.Comparable interface.

The Eclipse integration has received several additions in making it
load a whole lot better. In fact on most systems you don’t need to set
-Djava.library.path anymore, Qt Jambi will just figure it out based on
the location of the qtjambi.jar file. In addition to that we also got
a new wizard for making custom widgets in Qt Designer from Eclipse.

There are a number of other things too, but this is turning into a
changelog and I didn’t want that, so just check it out. Here’s the
webstart:

I feel really good about this release, just look how exited we are…

MapReduce was originally developed by Google to simplify writing parallel algorithms for computer clusters. The basic idea is that you divide your algorithm into two parts: one part that can be run in parallel on individual pieces of the input data (’map’), and one sequential part that collects the map results and produces the final result (’reduce’). Your program then sends the map and reduce functions along with your input data to the MapReduce framework which automatically parcels out the data to each cluster node and collects the results afterwards.

MapReduce in Qt Concurrent is implemented to work on shared-memory systems, so instead of managing cluster nodes it manages threads on a single computer. This also means we can drop some of the features that the Google version has, such as fault tolerance. (we assume that processors don’t fail)

The API looks like this:

QFuture<T> mappedReduced(list, mapFunction, reducefunction);

As an example, let’s say we want to do a word frequency count on the contents of several documents. Here the map function will count the word occurrences in each document in parallel, and the reduce function will combine the them into a final frequency count.

The input for the function is a list of text strings that contains the documents:

QList<QString> list;

The map function takes one document and produces a hash that stores the frequency count for each word in the document. This function will be called in parallel by several threads, so it can’t have any side-effects such as modifying global data (or more accurately: any side-effcts must be thread-safe). The number of threads used will be scaled according to the number of CPU cores on the system.

QHash<QString, int> mapFunction(const QString &document);

The reduce function takes one intermediate result hash and aggregates it into the final result. Qt Concurrent will make sure only one thread calls this function at a time. This has two implications: there is no need to use a mutex lock when updating the result variable, and the system can be smarter about how it manages threads. If a thread tries to become the reducer thread while another thread is reducing, the first thread doesn’t have to block but can put the result on the to-be-reduced queue and then call the map function on a new piece of data instead.

void reduceFunction(QHasht<QString, int> &finalResut, const QHash<QString, int> &intermediateResult);

Finally we put it all together like this:

QFuture<QHash<QString, int> >counting =  mappedReduced(list, mapFunction, reduceFunction);

Since mappedReduced returns a QFuture we have several options on how to synchronize with the result. The simplest thing is to just call QFuture::result() which will block until the result is ready. If blocking is inappropriate (say we are in the gui thread) we can use signal-slot connections to get progress and result notifications instead. It’s also possible to cancel mappedReduced by calling QFuture::cancel().

I’ve skipped over the function implementations here, the complete word count example is available in the Qt Concurrent package.

Trolltech announces a Greenphone developer challenge.

Win a Greenphone!

More details at:
http://www.trolltech.com/gpchallenge

Hi!

For a while now I’ve been working on a new Qt demo. Conceptually the new demo works the same way as before; it presents you with a menu of demos and examples on how to build applications using Qt. The new version makes use of QGraphicsView, a faster and better component for dealing with graphics, that supports hardware accelerated rendering whenever possible, and software rendering if not. The new demo is scheduled for Qt 4.3.

It has really been fun writing this thing. It started out with a lightweight ’system’ for creating buttons using simple animations, and ended up with a small beast that haunts me at night. I still can’t get my hands off fixing and twiddling with the ticker transitioning stuff…

A new feature of the demo (compared to the old version) is that it adapts according to the environment. If run on a moderate computer with an old graphics card, chances are that most of the ‘fancy’ stuff will be hidden. This includes the green ticker (see the screenshot below) and animations/transitions for moving buttons and example content in and out from the screen. And if your desktop supports less then 16 bit colors, transparency will be replaced with opaque colors.

The adaption mechanism is performed in two passes; First, before anything shows up on screen, a static test is done to check the underlying hardware. If the test reports bad news, the demo will run in a low setting with no animations and alike. Otherwise, it starts up as normal, and uses the first seconds to perform a benchmark in the background. If the measured frames per second (FPS) is low, the ticker, and perhaps transitions/animations, will be skipped. All animations are written using QTimeline (except the ticker), which makes it easy to ensure that the ’speed’ of the animations will remain the same regardless of the FPS.

Adaption, and a lot of other things, are also controllable from the command line.

UPDATE: Here is a little movie that shows how it works!

…and a screenshot:

Over the long holiday weekend, I actually had time to do some fun stuff other than playing with Skyler. I managed to “install” the Greenphone SDK on my my old IBM T20 lappie, just because it was there…

What is special about this installation, is that it does not use vmware, and is a ‘native’ installation. It was fairly simple to do, as well.
Of course, Trolltech does not support this configuration, but since the SDK system is Debian based, it is entirely possible.

There may be other ways to do this, but this is what I did. After copying most of the the root filesystem (not including /proc /sys or /tmp) and tarballing it up ‘tar -cvpzf’. I separated it into the mount points, so I had three tarballs, the /opt/Qtopia, the /usr/local toolchain, an the root filesystem. I used a live cd (could have easily used the Qtopia live demo cd) to format a few partitions on my old t20. Then I mounted it and untarred the rootfilesystem and toolchain, and Qtopia sdk.

The only files I had to change are /etc/fstab, /boot/grub/menu.lst, /etc/X11/xorg.conf, oh and remove the vmware-tools service from starting at bootup. I also had to mkdir tmp sys proc as well. I used the live cd’s xorg.conf in place of the one from the Greenphone sdk, (as it uses the vmware displayer driver).

So now I have a workable Trollnux Debian Greenphone development distribution on the IBM, complete with KDE 3.5.5, KDevelop 3.4, and Qtopia 4.2!

One of the more frequent questions that I see is how to do interesting transition effects for applications. So here’s how, first of all prototype your algorithm. Here we’re going to use a page folding to visualize transitions as turning of pages. So that it looks like this:

Then we figure out how to adopt it to application. The trick is how to get contents of an application without extra repaints. In Qt the contents of top-level’s is buffered and there is a private but exported way of fetching that contents (not fully platform independent at the moment). The example #2 shows how to grab the contents of the window without extra repaints and copies and use it to implement the effect, so it looks like this:

The forms were taken from Kate config dialogs so they’re real config pages (hence also why they’re, well, not too pretty). The effect is fully animated so to get a better idea of how it looks you’ll have to look at the ogg file provided here. It’s also worth noting that this effect is very efficient and works smoothly with virtually 0 cpu usage.

As mentioned in the last blog, to see more examples and code for this one visit Graphics Dojo. The above mentioned examples are at the examples 2 page.

I have been traveling and working a lot lately. I was attending Bossa Conference, which was the best organized Open Source conference I had the pleasure of attending. I got to hang out with people I normally spend very little time with like Rasterman. Raster and I had some time to sit down and talk about graphics, Qt, Evas, chickens (don’t ask), him being a crab killer (again, don’t ask) and just have a lot of fun. Chris explained a few things about LLVM to me. It’s always fun to hang out with Marcelo as well. All around it was a great time.

I went to spend a little time with my “family” in England last week which was also just amazing.

The most important news though is that thanks to amazing work that Marius did on labs.trolltech.com I’ve got a Qt focused graphics corner. Being a Graphics Ninja, I’ve decided to call it the Graphics Dojo. The first action point was the release of some of the examples that I wrote in my spare time. You can take a look at an overview here or go directly to page 1 or page 2. There’s a few ones I’ve never shown before, like Mario Klingemann influenced Ring of Fire.

I hope that the “Graphics Dojo” and the articles which I’ll be posting on it will help everyone write better looking interfaces.

On the way to work today, on the train, I thought about how I can make this Monday the best possible. There’s a lot of stuff going on, and the art of getting Monday morning right sounded very appealing. So here I am; I’ve put on the Katamari soundtrack, wearing big earphones, sipping coffee and blogging about Graphics View. It’s working quite well :-)..

Lately I’ve been spending some more time researching “widgets on the canvas” and resolution independent UIs in general. It’s quite an interesting topic; there’s a lot of information to gather before we decide on what approach is most suitable for Qt. As for widgets on the canvas, the hot topic is whether we can support putting actual QWidgets on a scene, or if we need to fork our dear widgets and breed a new transformable species… One of the two might stand out as an obvious solution to you, but I can’t guess which one now that I see so many pros and cons for both approaches.

As a proof of concept, I ported QLayout to Graphics View, just to see if there are any immediate problems. Here’s what I got:

This picture shows QPushButtons in a QLayout, that is, several QPushButton clones inside a QGraphicsGridLayout. Running XP style. This experiment has brought up some important issues that need to be resolved:

• We need a layout-capable item, probably a QGraphicsWidget-like item with a geometry.
  • QGraphicsItem::children() conflicts with QObject::children() (argh, why didn’t we fix this before 4.2)
  • QGraphicsItem already has three geometry functions, so this widget might end up with like… 5 geometries. Confused?
  • The item needs to pick its style / font / palette from… what view?
• Layouts with qreals are incredibly cool, and powerful. You can specify a margin of 1.5 :-D. But for platforms that emulate floating points, doubles and floats are really slow (10-200x slower than ints).
• The buttons are drawn using QStyle, which is very pixel-oriented.
• No styles take transformations into consideration. For example, the way we do pixmap cacheing today is completely useless, exhausts memory and slows everything down for transformed widgets.
• Styles that use cosmetic pens (almost all styles do) look bad when transformed. In general, styles that try to use dots and lines look like frak when you zoom in ;-). I tried to do a little “search-and-replace” and the patch filled my home partition. No, just kidding… but the change is significant.

So far, my Monday morning is looking good. I’ve got some QSslSocket work to do, and some test fixing, and subconsciously I’m thinking about resolution independence 90% of my idle time. Which is fun ;-). There are so many possible solutions, and I foresee no problems in the showstopper category.