KDE on Windows

From Friday to Sunday, I attended the KDE on Windows sprint, hosted by Intevation, in Osnabrück. There were seven attendants, making it a nice and hacking-focussed sprint. Sure, there were discussions about improvements to the system and so on, as you can read on the meeting wiki page.

Important items are changing the versioning of the portage system by removing the version from the package names, improving the sandboxing of KDE applications (so they don’t overwrite each other settings, system configuration cache and so on) and integration of creatsing nsis installers in the emerge system.

We had some non-keyboard time as well, when on Friday, KDAB sponsored a german-style dinner, and on Saturday, KO an Arabian-style dinner, followed by drinks in the “unikeller”. Some pretty obscure German beer was had there, very tasty. And then some of us went back to the office of an all-night hack session…

See also Patrik SPendrin’s blog, with group picture….

Builds

Currently, I’m working with three or four build trees: one with Microsoft Visual C++, one mixed Microsoft Visual C++ and Intel Composer, one with Mingw, all natively on Windows. Dominik Schmidt demonstrated how easy it is to create 32 and 64 bit builds on Linux using Tomahawk as an example. I hadn’t heard of Tomahawk before, since my media player of choice is ogg123… But the build system looks very simple to use, and Tomahawk is pretty cool, too. Dominik spent a large part of the weekend integrating kdelibs, kde-runtime and kdepim into this cross-compiling system. This system depends heavily on the OpenSUSE build system, which I need to investigate anyway to make my CentOS packages easier to generate.

Check the tomahawk wiki for a basic cross-compiling howto: it really is utterly simple, once you realize that you need to do the same trick as tomahawk with a toolchain file for cmake definitions. That needs to be in order; from that point onwards, everything should just work. I’ll give it a try with Krita soon: the only dependencies still missing are exiv2 and eigen2.

This generates NSIS-based installers, but I also heard that other people have had success generating WIX-based MSI installers using mono on Linux and OSX, so that’s worth investigating as well.

Packages

Being a newcomer to the KDE Windows scene, I did some simple stuff, like creating a calligra package for the emerge system. If you put an emerge checkout on your windows system and follow the basic setup steps (really, just get the checkout, install python3, create an etc directory with copy of kdesettings.bat), you should be able to do an “emerge calligra” and get a working calligra installation. Of course, there might be problems along the way, but the nice people in #kde-windows know most of the answers!

I also started on packaging ilmbase, the basic dependency for OpenEXR. This was trickier, since ilmbase is an autotools-based package, so we had to add a CMake-based build system. That basically worked, so I added the package to emerge’s portage tree, and Patrick Spendrin then finished up and added OpenEXR. Maybe we should try to get the CMake system for those libraries upstreamed, though. The upshot of this is that Krita on Windows, once I’ve made new installers, will be able to handle 32-bits floating point/channel images. Not 16 bit floating point, though, since LittleCMS cannot handle that yet. But Marti has promised that for the next release…