I attended a meeting October last year in Boston where various parties dealing with text layouting met. This included members of the Pango/Gtk+, KOffice, OpenOffice/ICU and Scribus projects. Right now we duplicate a fair amount of work to support complex scripts and exotic languages. Only Pango and Qt share some code already that originates from the FreeType project for interpreting OpenType tables. On that meeting we agreed that it would be nice to share more of the work, to work on a common layer that can support not only OpenType but also SIL or Apple’s AAT. And most importantly to provide a single place in the free desktop software stack to add support for new complex languages and provide consistent behavior across applications when it comes to text shaping.

As a first important step Trolltech decided to relicense and contribute their existing code. Lars and I have been working on this in the past month(s) and we now finally got around pushing out our changes to a git repository on freedesktop.org. Based on the existing HarfBuzz code we’ve created a first version of a common API, ported our shaping engines that operate on top of OpenType and provide some fall backs if a font does not provide the necessary tables for shaping.

So now it’s screenshot time to demonstrate the beauty of shaped complex text. Thanks to frequent recent visits at a Sri Lankian restaurant here in Oslo and Girish’s help I decided to use some Tamil words for demonstration. We usually start the meal with a some of non-sweet Donut called Vadai (வடை). The “main” meal then consists of a kind of crêpe called Dosa (தோசை) where pieces are teared off with your hands and dipped into some chutney or Sambar (சாம்பார்). You’d be surprised to see how well Trolltech engineers manage to eat with just their hands! Here’s a picture linked in from Wikipedia that shows this kind of pan-cake:

With our changes Harfbuzz now shapes the word Dosa like this (rendered using FreeType):

If a toolkit renders the characters just individually it’ll appear incorrect and look like this:

As you can see by comparing the rendered glyphs they sometimes need to be swapped. This re-ordering can happen on the level of characters (think QChars in a QString) as well as on a level of glyph indices. Without this procedure the resulting glyphs form just garbage and don’t make any sense. (Well, they don’t make sense to me either way because I unfortunately can’t read Tamil, but Girish confirmed that only the first form is correct).

The delicious Sambar that we dip Dosa pieces in looks shaped with Harfbuzz like this:

This is the incorrect unshaped rendering for comparison

… where you can see that the dot marks are not placed nicely above the letters where they belong to.

Now none of this is a really new feature, the free software desktops as well as Mac OS X and Windows have been able to support these kind of advanced text rendering techniques for a while (although it’s sad to see that for example Ubuntu’s default shipped Firefox seems to render this correctly only if I set my locale to some indic one while Konqueror gets it always right). But as scripts change and as the software needs to be adapted sometimes it is even more important that this can be done in one central place. For example we’ve recently received patches for Qt that adapt tables in the shaper to recent developments in the Bengali script to permit certain previously disallowed combinations of vowels and consonants. If we succeed with Harfbuzz then it will only be necessary to adjust the software at one place instead of patching Qt, OpenOffice, Pango and perhaps others.

Here’s a follow up on the recent blog post which presented a new filedialog interface. Listening to the feedback it has been changed back to look very similar to the one in 4.2. The big differences are that the Save As collapsing functionality has been remove and the line edit is back and gets focus by default. The saving has been fixes so adding folders to the sidebar will be saved, along with history. Note that the painting issue on the cancel button is being looked into already and will be fixed shortly (it only occurs in Plastique style).

Feel free to provide feedback on what you think of this change.

Open dialog

Save dialog

P.S. A little hidden feature that has been in the file dialog sense at least 4.2 is that if you type “..” in the line edit and hit enter it will move to the parent directory. In 4.3 that has been extended to the completer so you can now type ../foo/bar and the completer will understand the relative path.

Since October 2006 we’ve been porting Qt 4.x to Windows CE 5.0 and Windows Mobile 5.0 and we’re starting to get somewhere, so I thought it was time to break the news. The plan is to have a Technology Preview ready late this summer, and have a final release together with the rest of Qt 4.4.0 sometime next year.

So how far are we? We’ve ported QtCore, QtGui and QAxContainer (ActiveQt) as well as updated the buildsystem (configure.exe, qmake etc.) for supporting shadowbuilds and compiling to host and target platforms. We’ve got our QMenu stuff integrated into the native Windows Mobile menubars, and we’ve got two new styles: Windows CE and Windows Mobile. We’re also running nightly autotests of the Qt/CE branch running through the hundreds of autotests we’ve got for our different modules. Wanna have a look? Here is some obligatory screenshots:

Tetrix running on Windows Mobile 5.0. We were very quick to map the softkeys so we could pla^H^H test this application when testing packages.

Textedit demo running on Windows Mobile 5.0 (Smartphones). Notice how the menu is the actual native Windows Mobile one.

Textedit demo running on Windows CE. Here the menu is more like we’re used to in desktop apps. Also - notice the crappy style…. It’s not our fault - we’re just following the “guidelines” :).

At the moment we support these SDKs from Microsoft:

• Windows Mobile 5.0 Pocket PC Edition (ARM)
• Windows Mobile 5.0 Smartphone Edition (ARM)
• Windows CE 5.0 Standard SDK (ARM)
• Windows CE 5.0 Standard SDK (X86)

and we already had our binaries running on Windows Mobile 6.0. Windows CE 6.0 we don’t support yet, but the moment there is an SDK available from Microsoft (if ever?) we will add support for it ASAP. We develop and test both on the emulators provided by Microsoft, but also on a Dell AXIM X51v (Pocket PC) and a Qtek 8310 (Smartphone).

Now if you want to try out the stuff, here is Tetrix statically built for Windows Mobile 5.0 (ARM). It’s around 3 megs. And if you want to get serious and get your hands on the current code to help us with suggestions and bug reports, you can do that too! Just send a mail to support and/or sales and ask them nicely about joining the Qt/CE testing program (you need to sign an NDA at the moment - and don’t worry there will be publicly available previews later).

So what is left you ask? Well, we need to make all the other Qt modules compile and work on the platform. But more importantly we also need to make sure that Qt performs well on the Windows CE devices. As you know we already support embedded Linux with Qtopia Core. Now we need to give the same love and caring to Windows CE as embedded Linux has been getting all these years. At the moment we are working on optimizing painting performance (we’re trying to make Qt/CE use 16bit colordepth internally rather than 32bit as it is at the moment) and also ways to make the size of the Qt libraries smaller. The cool thing is that we now have two embedded platforms where Qt will run, and since we’re working together it will improve them both! Is this one of the few places where I can use the word synergy? I think it is!

I have been working with embedded distribution build systems for some years now, since the Sharp Zaurus 5000d first got released and have thought a lot about this subject. I have tried many build systems, some commercial, and all have short comings. A build system should require a few things:

1) It has got to be stable and should “just work”, out of the box.

some of them out there are neither. They use mainly very unstable cvs/svn for sources, and a developer can either never get a build finished, has to spend precious time fixing things that should just work to get it building. They themselves are ‘works in progress’, and have never created something stable.

2)It should be easy to configure which packages get build.

I have used the old openzaurus ‘buildroot’. I prefer it, because it uses the old kernel config gui, and doesn’t download entirely new completely unstable cvs/svn sources just because the wind blew differently. It is stable because no one but myself works on it. Give me some kind of gui to select packages! The gui should be easy to maintain, and well known.

3) It should have good up to date documentation on it’s use

Nothing worse than trying to use documents on a wiki, which are outdated and do not work.

4) It should be easy to maintain

Build systems should not have to be complicated. They should be easy to understand, so a developer can easily
add new packages, or remove them. Having to download and learn 5 or 6 ever changing packages just to suit the build system is not my idea of easy.

5) It should build a toolchain, and should be configurable where it lives

I hate to hear it, and hear it often, some developer just wants to cross compile one or two apps for some device. Someone jumps in with “Why don’t you use < some ungodly big, unstable distribution build system >“. Cross compiling is just that - a simple process that someone wants to do quickly, without too much hassle. Developers just want a frickin’ toolchain! Don’t recommend overkill. You wouldn’t use a jack hammer to pound in one small tack. It should also be configurable where this toolchain lives, because no one likes your idea of putting the cross compiling environment in some unstandard, unobvious and out of the way place.

more thoughts later… my one and a half year old just woke up…

Gah… I’m currently working hard to finish QSslSocket, need to get it 100% rock solid before the 4.3.0 release. It’s tough; OpenSSL isn’t the easiest toolkit to deal with, but then again, the API that Qt 4.3 provides is looking so good that it’s all going to be worth it (/me tries to comfort himself).

For example, take a look at this little well-known snippet of code. It’s a stub for a Qt Console application, one of my favorite templates for writing nice little command line tools:

int main(int argc, char **argv)
{
    QCoreApplication app(argc, argv);
}

Now, with 5 lines of code, we’ll add a QSslSocket that downloads PayPal’s front page using HTTPS. Don’t take these very few lines lightly; although you cannot see any certificates/keys/ciphers or anything, this code is as secure as SSL can get. And as is typical for Qt, it’s so easy to do that you’d want to add SSL to all your networking ;-).

int main(int argc, char **argv)
{
    QCoreApplication app(argc, argv);

    QSslSocket socket;
    socket.connectToHostEncrypted("www.paypal.com", 443);
    socket.write("GET / HTTP/1.0\r\n\r\n");
    while (socket.waitForReadyRead())
        qDebug() << socket.readAll().data();
}

QSslSocket::connectToHostEncrypted() is a special version of connectToHost() that auto-initiates a client side hand shake after the connection has been established. QSslSocket uses the system’s default CA bundle (or, in lack of such a bundle, it uses a built-in bundle). And if anything goes wrong with the SSL handshake (i.e., the host identity is not established), the connection will be torn down, and the first waitForReadyRead() call will fail before any data is transmitted. Is that sweet, or what.

Now let’s take this a step further. Say you want to use one of the public proxy servers available. Ever been worried that these proxies can intercept your transmission? Well with QSslSocket, you no longer need to worry. Add one line to the above script to use an HTTP CONNECT proxy:

    QSslSocket socket;
    socket.setProxy(QNetworkProxy(QNetworkProxy::HttpProxy, "130.226.169.133", 3128));
    ...

Now, your 5-liner has become a 6-liner, with a fully-secured connection over an HTTP proxy (disclaimer: I have no clue who owns that proxy, I just know whomever it is cannot decrypt the transmission!).

Open Source
Open Source binaries are now available at ftp://ftp.troll.no/qt/source

There have been a couple of reports of compilation failing with MinGW. You can solve this in two ways - Either upgrade your Win32 API headers to atleast 3.7 OR use the binary package which comes with a fix for the compilation. Note that you won’t be required to upgrade your Win32 API for the final 4.3.0 package.

Commercial
Commercial binaries should be available in your distribution directory.

There are two binaries for Windows - One with Direct3d support and one without Direct3d support. The package with Direct3d support requires the Direct3d runtime. IMPORTANT : Without the runtime, none of the programs in the package will run. You need a fairly recent runtime - Use this NOT this). Once installed, you can start any Qt program with the -direct3d argument to see the Direct3d paint engine in action.

Note: Qt’s dependency on Direct3d run time when compiled with “configure -direct3d” has been removed in the snapshots. The limitation exists only in the beta.

We released Qt and Qtopia Core 4.3.0 beta source packages today. You can download them here. Binaries will be available by this friday. Note that the Open Source beta packages are now available under GPL.

Space being limited, a lot of non-buzzword-compliant features got unceremoniously dropped from the What’s new page. So here is a random list of features I can think of right away that are not mentioned there

* New platform Qt/MSYS (being the release manager, I get to shamelessly plug my feature first )
* Unified tool bar for MAC
* New XML classes QXmlStreamReader and QXmlStreamWriter
* Object Bounding Mode for gradients
* QDir search path
* Perspective transformations
* Almost every Qt widget now supports styling using stylesheets (I will blog about all the enhancements in the days to come).
* QApplication::alert
* QDirIterator
* Prioritized posting of events
* Set operations on paths
* QWidget is now locale aware
* QColumnView
* Unicode 5 support
* Editing dynamic properties in Qt Designer
* The supremely cool Qt::BlockingQueuedConnections

A few more come to my mind but I will leave them for you to discover :). Don’t hesitate to contact us at the qt4-preview-feedback for any help.

Happy hacking!

After my last Graphics View blog about Widgets on the Canvas, people have been contacting me and telling how much they really really want true widgets on the canvas, with full transformations support. Resolution independent user interfaces, now that’s something very many drool over, especially the idea of not having to worry about pixel sizes relative to the size of the desktop. The KDE Plasma project is also very inspiring.

I don’t have any code or screenshots to show this time, but I wanted to let everyone know that we’re investigating all viable options. It’s very very exciting. Maybe I’ll have something to show off in not too long time. Most of my time is spent researching this topic right now. I hope to be able to point back at this blog after we have full widgets-on-the-canvas support in Qt 4, and say… “This is what we were working on back then!” :-).

Graphics View has so many applications, it’s amazing what people use it for.

And I have made up my mind.

When I grow old, I want to live in a Graphics View house and drink Graphics View coffee.

It’s now “official”. The new Brisbane, Australia (pronounced “BRIZ-buhn”) office of Trolltech is now open!
Story here

We actually moved in December, but had a media bruhaha the other day. I took some photos of the office
Trolltech office photos

Of course, the office is huge, and not all the open places are covered. You might find other photos somewhere else.

Oh, and by the way, we are still hiring!

For keeping our HP-UX support up to date, we’re experimenting with adding support for HP-UX on Itanium. For now, the aCC 6 compiler range seems to work; gcc doesn’t work yet. If you want to try it out, you can either download a Qt 4.3 snapshot, or wait for the first official beta, and configure with hpuxi-acc-64 (notice the ‘i’).

qt@host:~/qt-4.3> ./configure -platform hpuxi-acc-64

Initial testing shows that it’s on par with the other HP-UX configurations we support (PA-RISC 32 and 64bit aCC, and 32bit gcc).

Hai, PA-RISC	Gravlaks, Itanium2