Today’s lunch topic was “how difficult can it be to deploy a browser on Linux?”. After extensive discussion (~ 30 seconds), we decided to give Arora a try.

First, Qt was configured with -platform linux-lsb-g++ –prefix=/opt/arora. The linux-lsb-g++ makespec uses lsbc++ to compile, which ensures that the binaries will be ABI compatible with all recent Linux flavors. Since Arora picks up Qt’s default make spec, it too was built with lsbc++. Linking was done with –lsb-use-default-linker to ensure that the application will run even if the LSB packages are not installed.

About an hour later(*), I’m happy to present the result: arora.tar.gz (~511 MB 16 MB). Unpack it to /opt, then run /opt/arora/bin/arora. Please let me know if it doesn’t run on your GNU/Linux desktop.

After a bit of yahoo’ing, it looks like the makelsbpkg offers a straightforward way to create an installable package, but I leave that topic open for another lunch discussion

(*) I got carried away a bit by making two minor modifications to the default build. First, GStreamer is currently not part of the LSB. The good thing is that Phonon’s GStreamer support is completely factored out into a plugin. It can be safely shipped with the application - if GStreamer is not available, the plugin will not load, but the rest of the application will run just fine. lsbc++’s –lsb-shared-libs parameter was used to link the plugin to GStreamer.
My second small adjustment was to enable Qt’s GTK+ style. The GTK+ version shipped with LSB is a bit too old for us, but compiling against my desktop’s GTK+ worked just fine. Since the GTK+ style resolves its symbols at runtime, it’s also safe to ship - if GTK+ is not installed or too old, another Qt style will be used as a fallback and the application will run just fine.

Whenever I try to play around with KDE 4 on Mac OS X, I find myself mostly compiling and installing 3rdparty libraries. Fink and MacPorts ease software installation, but have one disadvantage: Software packages that are already available on Mac OS X are installed again, sometimes differing only in minor versions. I do understand the philosophy behind it - both projects want to ensure maximum consistency and quality. However, it takes time to compile all the dependencies (e.g. perl5) and it might lead to symbol clashes (Qt links to the system’s libiconv, some other KDE dependency to MacPort’s libiconv - boom).

So, to jumpstart things - here’s my repository of dummy Macports portfiles which will force MacPorts into using the system’s libraries. Of course, this should be used with care, will definitely ruin lots of MacPorts packages and is completely unsupported by the MacPorts community. However, it does get shared-mime-info (required for kdelibs) onto your machine in record time.

So, download the Qt/Mac binaries, get the “MacPorts dummies” and be able to hack around on your favorite KDE application in less than a day

As for the daring x86_64 Mac Cocoa users - all dummy portfiles are universal. For compiling kdepimlibs, you need this patch to get an universal build of the boost libraries.

Happy Hacking!

We are planning and implementing several measures to improve learning of Qt. This should certainly be done in accordance with YOUR needs. So, please take the following survey and give us feedback on how we can improve our learning content and tools in order to help you to expand your Qt knowledge.

There is a chance to win a Nokia 5800 XpressMusic cell phone as well

Survey: https://www.questback.com/trolltechasa/gm8gz1sx8a/

You may have already seen our Embedded Widgets Demo. We got a lot of good feedback, including lots of requests for the source code. Therefore, I’m happy to announce that the sources are now available.

Within the project you will find a collection of industrial style widgets - mainly for touch screen interaction. In addition there are two example applications (Patient Care and Catalog), which serve as a showcase for these widgets. Here’s a video featuring our lovely Carol:

The emphasis of this demo is on SVG and CSS use and how both these techniques can be combined to build an easy to use, industrial looking
user interface. The target audience for such a UI would for example be an operator in a factory, who is used to physical knobs and turning dials.

Although this demo is mainly targeted at and tested for our embedded platforms (Embedded Linux, Windows CE), it also runs fine on X11 (for example on the N810 with the Qt/Hildon integration), and even on a Mac OS X or Windows desktop.

The heavy use of SVGs paired with transformations, gradients, anti-aliasing and other effects comes with a cost, though: for Qt for Embedded Linux, we suggest to use the configure switch -D QT_COORD_TYPE=double, which will increase the rendering quality.

Solid Dragon

It’s time to present the little hack that I’ve been working on for a while now: A Mac OS X backend (source code) for Solid, KDE’s hardware introspection library. To make a good screen shot, and to show how easy it is to use Solid, here’s also a small hardware browser:

The backend is still in progress, and not all Solid hardware interfaces are implemented yet. Still, the generic interface can be used to introspect any device and read out its properties. You can even introspect the famous Dont_Steal_Mac_OS_X device

One of the nice things about Solid is that it can be used from non-KDE applications as well - it just requires Qt (*)

64-bit Leopard

Next to playing with Solid, the release of Qt 4.5 was a good excuse to play with 64-bit KDE on 10.5 (Leopard).

First, we need the magic CMake switch to build 64-bit Mac OS X applications: -DCMAKE_OSX_ARCHITECTURES=”x86_64″ (**)

Unfortunately, some of kdelib’s files rely on deprecated API which doesn’t exist in the 64-bit versions of OS X’s libraries. So after some fixing and some more commenting out of non-compiling stuff, I finally got my first KDE 64-bit application:

minibrowser.app/Contents/MacOS/minibrowser: Mach-O 64-bit executable x86_64

Screen shot: see above

(*) Well, there’s also a D-Bus dependency

(**) You can produce universal binaries by separating the desired architectures with a semicolon, e.g. -DCMAKE_OSX_ARCHITECTURES=”x86_64;i386;ppc;ppc64″ to get all four currently supported architectures. Unfortunately, I have no clue how to create universal binaries for the third party libs that KDE depends on (e.g. D-Bus) - any automake expert, please leave a comment (or convince the projects to switch to a more humane build system).

For some reason, I like using bleeding edge mail clients. The frequent crashes keep me productive (no “new mail arrived” popups to interrupt my work) as well as my co-workers (no mail with more than 20 words from me).

With the latest improvements, KMail became an even better mail client. Digging through company mail became almost pleasant. Time to fiddle around with it:

This screen shot shows KMail on Mac OS X, using WebKit instead of KHTML to render the mails. Why, do you ask? Heat up a flame war? No, just to give a choice. I prefer KHTML on Linux, but WebKit on OS X, since it’s significantly easier to build due to fewer dependencies (I have neither fink nor mac ports installed, so every external lib is a bit of a hassle).

So here I go again, the patch is ugly enough to ensure instability. Time to go back to work.

Disclaimer: Don’t apply the patch, really, don’t, unless you are a developer who dislikes mail. It doesn’t block external images yet, so regardless of your KMail settings, you’ll inform every spammer on opening a spam mail. That is, if you’re able to open a mail at all, of course.

To summarize my achievement at Akademy:

[Argument: a{sv} {"a" = [Variant(int): 1], "b" = [Variant(QByteArray): {99}], "c" = [Variant(QString): "b"], "d" = [Variant(uint): 42], "date" = [Variant: [Argument: (iii) 1977, 1, 1]], "datetime" = [Variant: [Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0],[Argument: (iiii) 8, 59, 31, 0], 0]], "dtlist" = [Variant: [Argument: a((iii)(iiii)i) {[Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0], [Argument: (iiii) -1, -1, -1, -1], 0], [Argument: ((iii)(iiii)i) [Argument: (iii) 1977, 9, 13], [Argument: (iiii) 0, 0, 0, 0], 0], [Argument: ((iii)(iiii)i) [Argument: (iii) 2006, 6, 18], [Argument: (iiii) 13, 14, 0, 0], 0]}]], "e" = [Variant(short): -47], "f" = [Variant: [Variant(int): 0]], "ismap" = [Variant: [Argument: a{is} {-47 = "c", 1 = "a", 2000 = "b"}]], "lldtmap" = [Variant: [Argument: a{x((iii)(iiii)i)} {0 = [Argument: ((iii)(iiii)i) [Argument: (iii) 0, 0, 0], [Argument: (iiii) -1, -1, -1, -1], 0], 1 = [Argument: ((iii)(iiii)i)[Argument: (iii) 1970, 1, 1], [Argument: (iiii) 0, 0, 1, 0], 1], 1150629776 = [Argument: ((iii)(iiii)i) [Argument: (iii) 2006, 6, 18], [Argument: (iiii) 11, 22, 56, 0], 1]}]], "pointf" = [Variant: [Argument: (dd) 0.5, -0.5]], "ssmap" = [Variant: [Argument: a{ss} {"a" = "a", "b" = "c", "c" = "b"}]], "time" = [Variant: [Argument: (iiii) 8, 58, 0, 0]]}]

Looks scary? It’s supposed to. D-Bus supports recursive complex types like structures, maps or variants, and until now, neither the Qt D-Bus viewer (part of Qt’s demos) nor the qdbus command line client were able to dump the contents of complex arguments. So, one day of hacking later, and thanks to a small API addition from Mr. QtDBus Thiago, we can now show pretty much everything that comes through the bus. The above example shows the output of one of our D-Bus tests - you can find complex structures inside variants and complex structs inside maps, and everything is nicely dumped.

But don’t worry - not many interfaces use deep nesting. Why we started to write the code in the first place is to display rectangles (4 integers in a D-Bus structure) from Qt’s D-Bus accessibility, Decibel’s properties (a D-Bus map structure) or some of the more complex calls of Telepathy.

The code will be available in Qt 4.5’s snapshots, happy introspecting!

P.S.: Many, many thanks to the organizers of this year’s Akademy. As always, it’s a great pleasure to be here.

New business cards (not arrived yet). New employee badge (photo looks bad, as always). New email address (@nokia.com). New phone (starts with N). New intranet (huge). New Desktop (KDE 4.1 - I’m so impressed by you guys). New presentation templates (for my Akademy presentation). New marital status. New version control system (git).

And a new patch to make Qt 4.4 build within the LSB 3.2 environment, we’re getting very close to having one binary Qt/X11 Linux version to rule all distributions (bye bye distribution pain): lsb3.2-20080801.patch

Disclaimer: The patch above is unsupported, please contact my first name dot last name at domain starting with N for questions.

One of the more heated points in the ongoing KDevelop team meeting here in Munich is the good old language war - while I love (and hate just as much) Perl, Alex likes Ruby, Roberto JavaScript and I’m sure we can find someone who prefers Python.

Since Revision 797621 of KDevPlatform, scripting via Kross is now supported. This allows everyone to write an extension to KDevelop in his favorite scripting language. Since I’m most familiar with QtScript (yes, I did forget all my Perl a moment ago), here’s an example KDevelop script:

function documentLoaded(doc) {
    print(KDevTools.toDocument(doc).url());
}

documentController = KDevTools.toDocumentController(KDevCore.documentController());
documentController.documentLoaded.connect(docLoaded);

This little script will listen to all documentLoaded signals from the document controller and outpout the URL of the file once it’s loaded.

So, let’s load a file:

documentController.openDocument("test.cpp");

and watch the URL being printed to command line. The available scripting backend could already be used to implement a simple “switch header/source” plugin, that opens the corresponding *.h/*.cpp file when invoked.

For the moment, the “casts” using KDevTools are required as long as I don’t understand how to auto-convert meta-types in a script-independent way

My goal for this meeting - implement a version control system plugin completely in a scripting language, so it can be deployed without headache for all supported OSes.

… literally means “love goes through the stomach”. What better way to announce some of the delights that await the weekend visitors of the KDevelop team meeting? As if free coffee including a free USB coffee warmer wasn’t enough!

This Saturday (April 12), carefully buttered fresh Bavarian Brezn will be served from 9:00 in the morning. This peak of taste bud stimuli will be accompanied by another non-plus-ultra of cuisine - our local specialities shop, which is usually closed on Saturdays, is going make a one-time exception just for us and freshly bake Poğaça - delightful small rolls filled with tasty cheese.

For the ones that prefer sweet things, don’t worry - there will be German Fruchtplunder and Turkish Baklava - after eating those, pure sugar will taste sour.

More information, including a visual guide on how to get there, can be found on the KDevelop wiki.