Category: Qt

guitone 0.8 released – spring time is hacking time!

guitone 0.8 has been released today. Major improvements happened under the hood, the outstanding changes are:

  • guitone is now licensed under GNU GPL Version 3 or later. Please note that you’re now only allowed to legally distribute binaries which you’ve built with Qt 4.3.4 or later, since earlier versions of Qt are GPLv2-only
  • new “driver” interface to call certain dialogs of guitone from the outside, which should help for all sorts of integration wishes ondifferent platforms. A “TortoiseMonotone” project has already been kicked off at the last summit – currently residing on the net.venge.monotone.tortoise branch – and this project is still looking for help from people which are fluent in Python and / or the Windows API
  • numerous improvement in workspace handling (faster, prettier, more configurable, yatta, yatta…)
  • for a full list of changes check the NEWS file

You can download guitone at the usual location, a win32 installer (yes, we’ll have one!) should follow shortly.

Hide Qt GUI applications from the Mac OS X dock and menu

Starting with Qt 4.4 which was released a few days ago Qt now honors the

LSUIElement
1

setting in the Info.plist file of the application bundle. This is particularily useful to create bundled application which should not pop up in the global dock or menu, f.e. daemons which run in the background or applications like Quicksilver which are only accessible via a global key stroke or an icon in systray area of the menu bar.

Now, with guitone I recently had the problem that I wanted exactly this mode under OSX in its new “driver” mode, which lets you automate / script the access to internal dialogs (check the nvm.guitone.app-driver branch for more information), but it should not interfere with the “standalone” mode, i.e. the dock icon and menu bar should be of course shown there.

One way of accomplishing that would have been to create a separate binary just for this usage and only set the setting in this property list. However, even without knowing much of OSX’ Carbon API, I came up with a better solution, inspired by what Qt does itself deep inside qapplication_mac.cpp if it stumbles upon the LSUIElement entry:

GuitoneStandalone::GuitoneStandalone(int & argc, char** argv)
: GuitoneCore(argc, argv),
{
#ifdef Q_WS_MACX
ProcessSerialNumber psn;
if (GetCurrentProcess(&psn) == noErr)
{
TransformProcessType(&psn,
kProcessTransformToForegroundApplication);
}
#endif
…
}

This unconditionally transforms such a background application to a foreground application with a dock icon and menu bar. So all I had to do was to check my calling arguments if the driver interface should be used and if not, create the correct QApplication instance which brings the application to the foreground. Nice!

Now I only have to fix this one, very weird behaviour of QMetaMethod::invokeMethod which does not accept my argument list… *grumbles*

Should Trolltech make their products support GPLv3?

Since the GNU General Public License v3 had been [released last week](http://gplv3.fsf.org/) I’m actively thinking about switching the license for some of my projects, f.e. [guitone](http://guitone.thomaskeller.biz), which are currently GPLv2 “or later”. The main reason for doing this for me personally is to protect my software even better from any possible [Tivoization](http://en.wikipedia.org/wiki/Tivoization), i.e. no patent restrictions, closed hardware, or anything else should hinder people to use, modify and distribute it further.

Looking more in detail at the license possibilities [Trolltech](http://www.trolltech.com) gives developers which use their Qt/Qtopia platform, upgrading Qt projects from GPLv2 to GPLv3 doesn’t seem to be possible: The problem is that even though Qt4 can be licensed under GPLv2, it does **not** contain the “… or – at your option – any later version” clause of the license, and since GPLv2 and GPLv3 are incompatible with each other, as Richard Stallman [told us here](http://gplv3.fsf.org/rms-why.html), you therefor can’t legally link GPLv3 code with those GPLv2 libraries:

> When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, If you include code under this license in a larger program, the larger program must be under this license too.? There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn’t do the job, because GPLv2 would need a similar clause.

([Source](http://gplv3.fsf.org/rms-why.html))

There _might_ be a way out of this dilemma, in case Trolltech doesn’t want to put Qt/Qtopia directly under “GPLv2 or later”/GPLv3: There already seems to exist a “Trolltech GPL Exception version 1.0”, but the text is currently unavailable from the [Troll’s site](http://trolltech.com/products/qt/gplexception). A temporary copy of it can be found in the Subversion repository of the libqxt project. The Exception states that you can use a couple of other accepted Free Software Licenses in your project and still use the GPL version of Qt:

> […] 1) The right to use Open Source Licenses not compatible with the GNU General Public License: You may link software (hereafter referred to as “Your Software”) against the Licensed Software and/or distribute binaries of Your Software linked against the Licensed Software, provided that:

> A) Your Software is licensed under one of the following licenses: […]

and what follows is a list which includes licenses like the Apache Software License, the LGPL, the BSD license, the Mozilla Public License, to just name a few. Furthermore:

> […] B) You must, on request, make a complete package including the complete source code of Your Software (as defined in the GNU General Public License version 2, section 3, but excluding anything excluded by the special exception in the same section) available to Trolltech under the same license as that granted to other recipients of the source code of Your Software. […]

…this seems only fair…

> […] C) Your or any other contributor’s rights to:

> i) distribute the source code of Your Software to anyone for any purpose;

> and

> ii) publicly discuss the development project for Your Software and its goals in any form and in any forumare not prohibited by any legal instrument, including but not limited to contracts, non-disclosure agreements, and employee contracts. […]

… yes I hope so!

Now I’m unsure if this exception is granted to every (free) software project using Qt. Currently, GPLv3 is not on the list, but if this exception is valid for everyone (not just paid customers of Trolltech), maybe it could be expanded to allow GPLv3 as well and therefor serve the Open Source community

Whatever route Trolltech will go, I hope they at least notice that there is **a demand from the Open Source community** to clarify the licensing issues with respect to GPLv3, and I hope this happens in the near future…

Edit 2007-08-09

It seems as Trolltech put back the GPL Exception in place, though the GPLv3 is still not listed as a valid license. One Trolltech engineer said however recently in a comment on the Labs Blog:

… As for GPL v3, we are actively working on it. From what I understand, it is a bigger step and not something we can just provide with an Exception.

(Source)

So its good to know that they’re aware of it!

Projects, projects, projects!

Last week my copy of Anno 1701 for the Nintendo DS dropped in and I instantly remembered the happy days when I played the original version for the PC, Anno 1602. While the gameplay is pretty much the same, graphics have been improved a bit and the product circuits got less complex. While you may have needed two or three buildings to produce a certain good, now one or two are enough.
All in all its a worthwile game, which made me looking into alternatives and/or ports for the Mac OS. Sunflowers, the company behind the Anno series, never considered such a step (“market share too less significant”) and I don’t know of any other publisher, such as Aspyr Media, ever considered that either way. This is kind of sad, especially if you look at the gorgeous PC version of 1701 which was released last fall. Intel Macs now certainly have enough power to play those games, but even Steve itself doesn’t put the “almost no mainstream games for the Mac”-problem on a high agenda – which you may imagine if you look at the half-hearted try of Electronic Arts to support the Mac OS with games, which was, of course, vastly announced by Steve on the last MacWorld.

Now, one very interesting project which recently took my attention in this regard is OpenAnno. It seems that a couple of Anno-enthusiasts try to create a clone of the original 1602 version. The game is in very early stage, there is an editor written in Qt, and the game itself seems to be build upon SDL, making it suitable for cross platform gaming. However, like every Open Source game, the developer’s biggest problem is to find people who create kick-ass graphics and animations, and in general, get more attention by the community. I decided to give it a try and create some native mac binaries for the most recent version. This is not done in five minutes, given the fact that the SDL libs (they use SDL_image, SDL_mixer, SDL_gfx and SDL_ttf) aren’t installed on most user Macs and most of those libs are known to have other horrible dependencies. So instead of messing around with frameworks I’ll probably try and link all of them statically to the main application. PhysFS is another dependency, but this shouldn’t be too hard to integrate. Lets see how this goes, I’ll of course post news here if I get it done =)

Beside OpenAnno there are of course other projects which have my attention. At first guitone, where the development slowed down a bit recently, because I’m in the process of rebuilding the monotone wrapper in use again. Having the mtn process run in the main GUI thread seems to cause a lot of problems, sometimes it just doesn’t signal that output is available, so the GUI is stucked (this happens on my beloved win32 port). But I’m not saying that it works better on other platforms… OSX has similar problems. My current solution involves putting the QProcess in a separate thread which has a local task queue and which signals when a certain task has been finished. Thanks to the Trolls that signals and slots work across threads (they are enqueue in this case and are not executed directly), still, my new solution includes some ugly code parts, f.e. when I try to match the finished task to any of the signalled slots. Given a general signal like this

void taskFinished(MonotoneTask & task);

and any amount of consumer classes which have a slot for this of course makes the need for code like this

void Consumer::taskFinished(MonotoneTask & task)
{
    // this is not our task...
    if (task.getTaskNumber() != rememberedTaskNumber) return;
}

if one uses a thread-global task number to identify each of them. I’ve looked into various other solutions for this; what I basically need is of course a callback or something which only functional languages provide: lambda notations. But this is Qt, this is C++, so without getting your hands very very dirty (or throwing in big dependencies like boost) there is no way of doing safe, reliable, non-intrusive, cross-thread callbacks. But hey, if you know something I don’t know, I’d be happy to hear from you!

There are two other projects which have my interest, but I guess I’ll tell you of those in my next post – this one got already far too long =)