Category: guitone

guitone license change

[Guitone](http://guitone.thomaskeller.biz), my little GUI frontend for the [monotone SCM](http://www.monotone.ca), is currently licensed according to the terms of the GPLv3+ and was previously – before version 0.8 – licensed under GPLv2+. Newer development however forces me to re-license it again, this time under slightly less restrictive “copyleft” terms, under LGPLv3.

The reason for this is my usage of the [Graphviz library](http://www.graphviz.org) to render monotone revision trees. Graphviz is released under EPL (older versions under CPL even), and this license is strictly incompatible to any pure GPL version. I contacted the Graphviz guys and I also contacted the legal affairs support of the FSF and checked the options I had and the result is now that I have to adapt, one way or another. I could either use the “command line interface” of Graphviz or choose another license for guitone. I didn’t want to go the first route, simply because I have a working implementation and because I didn’t want to make slow calls into external binaries, so a new license had to be chosen on my side.

So, starting with the upcoming version 1.0 guitone is licensed under LGPLv3. I contacted the previous contributors of guitone and all parties are ok with the license change, so the actual license change will pop up in the [current development’s head shortly](https://code.monotone.ca/p/guitone/source/tree/h:net.venge.monotone.guitone/).

Thanks for your interest.

monotone activity roundup

If you remember my earlier post(s) you probably ask where the highly anticipated version _one dot zero_ remains. Originally we planned to release it by the end of 2010, but we couldn’t really meet that date because we really wanted to polish a couple of things before releasing it. So what is the new plan then?

Well, we agreed that we want to release not later than by the end of Q1 2011 and if you look at our [RoadMap](http://wiki.monotone.ca/RoadMap/) you see that most stuff is already worked on, but you also see that we have quite a lot to do.

#### Core Monotone

Stephen did a great job over the last couple of weeks and reviewed our manual: He restructured the commands section, included many cross references, reworked and clarified many sections and purged old contents.

Richard, Stephen and Lapo worked on the wiki and tagged contents for certain user groups, i.e. users and developers. They also reviewed and cleaned up many pages which are often looked after and accessed. While all this is not quite finished yet, it already looks a bit better than before.

Richard and me fixed [a couple bugs](https://code.monotone.ca/p/monotone/issues/label/399/open/) that have been reported since 0.99. Right now the tracker looks more or less green with only two issues left open.

Beside the issues I’ve been working privately on the [source tree cleanup branch](https://code.monotone.ca/p/monotone/source/tree/h:net.venge.monotone.source-tree-cleanup/) and got some help from Richard here as well. This branch basically moves tests and sources around and puts them into a proper directory structure, so we do not clutter the main directory with sources, documentation, utilities and other stuff. I hope I can finish this branch next – only some work on the documentation is missing – and can merge that soon to the trunk.

#### Tools

Three others news are not about monotone itself, but related to it: [usher](https://code.monotone.ca/p/contrib/source/tree/h:net.venge.monotone.contrib.usher/), [indefero](http://projects.ceondo.com/p/indefero/) and [guitone](http://guitone.thomaskeller.biz).

Richard is currently preparing usher’s sources for packaging. We learned a lot about a proper usher setup when we configured usher with indefero on our own server instance, [code.monotone.ca](https://code.monotone.ca), and while Richard used that knowledge to bring usher forward, I reworked the [sources](http://projects.ceondo.com/p/indefero/source/tree/develop/src/IDF/Plugin/SyncMonotone.php) and [documentation](http://projects.ceondo.com/p/indefero/page/InstallationScmMonotone/) of the SyncMonotone plugin in indefero.


Beside that I’m also working on including a graphical branch view to guitone. Work has gotten somewhere already as you can imagine from the screenshot, but there are a couple of subleties to fix and clean before I’ll release that actually. Packaging this version will be kind-of fun; yesterday for example I stumbled upon a crash in libgvc after I moved the Graphviz libraries into the Mac OS X application bundle (which is needed for easy deployment), Windows packaging hasn’t even be started in this regard and I also need to investigate further if and how Graphviz’ Common Public License (CPL) allows me to distribute its binaries with my binaries at all.

#### Roundup

So you see we’re not lazy, but we all have so many things to do that it will just take a little longer. So stay tuned and thanks for your continued support!

guitone 1.0rc5 Windows installer available

Sorry that it took a while, but I got largely distracted by other things. Finally the Windows installer binary for [guitone 1.0rc5](http://www.thomaskeller.biz/blog/2010/11/06/guitone-1-0rc5-released/) is [available for download](http://guitone.thomaskeller.biz/g/download) – compiled under WinXP SP3 with Qt 4.7.1.

Please let me know if you encounter problems, for example by reporting issues in [guitone’s bug tracker](https://code.monotone.ca/p/guitone/issues/).

guitone 1.0rc5 released

I’m proud to announce the immediate release of guitone 1.0rc5. This fifth release candidate requires monotone 0.99.1 or later. The plan is to release guitone 1.0 final together with monotone 1.0 final
by the end of this year.

Amongst some minor bug fixes, this release also features a new “server mode” with which remote monotone databases can be explored (requires compatible netsync servers with remote automation permissions).

The tarball and a Mac OS X disk image can be [downloaded already](http://guitone.thomaskeller.biz/g/download), a Windows binary should follow shortly.

As always, please [report bugs](http://code.monotone.ca/p/guitone/issues/) if possible. And I’m still looking for more translators – if you’re interested, [drop me a note](mailto:me@thomaskeller.biz).

Thanks for reading,
Thomas.

guitone Mac OS X package

Newer versions of Qt come with the nice and handy tool `macdeployqt` – I think it first appeared offically in 4.6. What this basically does is that it looks for linked Qt libraries and plugins in your binary file and copies the needed ones over to your application bundle, so your application is ready for distribution.

So far so good, this worked nicely with the [Carbon binaries](http://qt.nokia.com/downloads/qt-for-open-source-cpp-development-on-mac-os-x) supplied by Nokia, but it stopped working properly with the Cocoa builds. While the latter are advertised as “…for Mac OS 10.5 – 10.6” and really let you build and run your application on 10.5 (yes, I still haven’t followed the crowd and updated), the `macdeployqt` does not. It depends on newer versions of `strip` and `install_name_tool` which only come with newer versions of Xcode, i.e. >= 3.2. And guess what… yes, Xcode 3.2 is of course not available on 10.6.

(Nokia has actually an older, already closed [bug report](http://bugreports.qt.nokia.com/browse/QTBUG-9318) on the issue, but I doubt they will fix the issue, they do not invest much anyways on non-mobile platforms these days and 10.7 is soon out as well, making 10.5 look even more deprecated…)

So at first I thought “lets try build a Cocoa distribution” for guitone, because I believed this could bring some speed and other improvements and I accepted that I had to kick 10.4 support out of the way for this to achieve, but this bug is actually a show stopper for me.

I’ll probably have to give away Mac packaging for guitone in the mid-term future anyways. I do not plan to upgrade to 10.7 nor to a complete new Mac (I don’t like the direction Apple is heading, but this is a different story) and Qt 4.8 will definitely no longer ship with Carbon support.

Monotone's new project forge officially online

I’m proud to announce that we’re almost done with one big entry in our TODO list for the ongoing server migration: Our indefero forge instance, a web-based project management software, is now set up and online under code.monotone.ca!

The forge contains several monotone-related projects, each with their own bug tracker, wiki, code browser and review module. Here is monotone’s one, and here the one for guitone. We’re planning to add more projects as the need arises and people demand them.

Each of the current and future setups also includes automatic access management for the underlying monotone repository which is served over usher – our proxy. Repositories can simply be accessed by their project name – so if you want to pull from the monotone repository, just trigger

$ mtn pull ‘mtn://code.monotone.ca/monotone?*’

Please note that with the advent of indefero, the main bug tracker of the monotone project is no longer Savannah, but Indefero. All the of the existing open bugs have been imported into monotone’s indefero project, so Savannah’s bug tracker should no longer be used (we’ll leave it online for reference for a little longer, though).

So I said “almost done” – whats missing? A few things actually:

* automatic mirroring of selected repositories with the designated mirrors
* push notifications for IRC / mailing list updates
* a better visual integration into the rest of our setups

While the first two things are on Richard’s TODO list, the last one is on my own schedule, though I want to wait a little longer until indefero’s redesign is through (expected sometime this fall).

And finally, the indefero monotone plugin needed a couple of extensions to core monotone, which I’ll likely blog later about, so stay tuned. If you’re interested in hosting your own monotone-related project on our forge, just drop me a note.

Thanks for reading.

guitone and monotone 0.48

The current fourth release candidate of guitone doesn’t work out of the box with monotone 0.48. The reason is that the minor interface version changed slightly and my version check is too strict in this regard. But there is an option for the rescue – simply check “relaxed version check” in the preferences and guitone will happily work with monotone 0.48 and later versions, unless a major change lets something break there:

The final version of guitone will probably take a little longer, since I want to synchronize this release with the release of 0.99 / 1.0 of monotone, so stay tuned. Other development continues in the meantime, I’m currently working on including support to query remote databases from guitone, which will likely make it into guitone 1.1.

Makefile-based InnoSetup automation with QMake

Over the last couple of weeks I did several major improvements to the QMake-based build setup guitone uses: The project file comes now with one target to create a tarball, one to create a Mac OS X disk image containing all the needed Qt libraries and one target to install the application, which can be configured to use all the options you know from autotool-based projects (like PREFIX, BINDIR or DESTDIR, to name a few).

But yes, there was one task which was yet missing there – one to automatically create a Win32 installer. The steps to produce that had been so far:

  1. enter the to-be-packaged version in the InnoSetup script file
  2. convert the supplied text files from Unix to DOS line endings, while giving them a .txt extension
  3. call the InnoSetup compiler on the script file and create the executable

Especially the first and second action looked hard to automate, given the fact that Windows does not come with a rich set of tools to process text streams – and requiring a Cygwin installation just for using sed seemed awkward to me. Obviously other people had similar problems before and somebody proposed to emulate sed with a VBScript which would be executed by the Windows Scripting Host (WSH). Wow, cool thing – if I’d just remember my broken Visual Basic knowledge. But didn’t Microsoft have this Javascript Look-a-Like, JScript? Shouldn’t this be executable as well?

Apparently it was and I sat down to hack an improved JScript sed version:

var patterns = new Array();
var replacements = new Array();
var argcount = 0;

for (var i=0; icscript and to combine everything for a proper QMake target. Here we go:

DOCFILES="NEWS README README.driver COPYING"
...
win32 {
    isEmpty(QTDIR):QTDIR           = "c:\Qt\4.6.2"
    isEmpty(MINGWDIR):MINGWDIR     = "c:\MinGW"
    isEmpty(OPENSSLDIR):OPENSSLDIR = "c:\OpenSSL"
    isEmpty(ISCC):ISCC = "c:\Program Files\Inno Setup 5\ISCC.exe"
    
    win32setup.depends  = make_first
    win32setup.target   = win32setup
    win32setup.commands = \
        cscript //NoLogo res\win32\sed.js \
            s/@@VERSION@@/$${VERSION}/ \
            s/@@QTDIR@@/$${QTDIR}/ \
            s/@@MINGWDIR@@/$${MINGWDIR}/ \
            s/@@OPENSSLDIR@@/$${OPENSSLDIR}/ \
            < res\win32\guitone.iss.in > res\win32\guitone.iss && \
        ( for %%f in ($$DOCFILES) do \
            cscript //NoLogo res\win32\sed.js \
                s/\n\$$/\r\n/ \
                < %%f > %%f.txt ) && \
        \"$$ISCC\" res\win32\guitone.iss && \
        ( for %%f IN ($$DOCFILES) do del %%f.txt )
    
    QMAKE_EXTRA_TARGETS += win32setup
}

So if you know enough Javascript you can probably emulate whatever tool you’re missing on Win32 without having to depend on any external dependency. Very cool!

guitone 1.0rc4: we have a winner! (updated)

This fourth release candidate is dedicated to Lena, the Eurovision Song Contest Winner of 2010 :). It comes with a few new nifty features like an improved changeset browser and enhanced certificate support, as well as a couple of other smaller improvements and bugfixes.

The Tarball and a Mac OS X disk image can already be downloaded at the usual location, the Windows installer will follow shortly. [Update: The Windows installer has been added.]

As always, please report bugs if possible. And while guitone now comes with one new translation, Portuguese, thanks to Américo Monteiro, I’m still looking for more translators – if you’re interested, drop me a note!

Quitting a Qt application from the Mac OS X dock

So for some weird reason my application was not closable from the Mac OS X dock – it quit properly when you selected “Quit” from the application menu or hit the Cmd-Q shortcut – but the dock menu’s quit action was completely ignored.

While debugging the issue I hooked into `QApplication::notify(QObject *, QEvent *)` and noted that a `QCloseEvent` was send to my application… wait, what? A `QCloseEvent`? Yes, I also thought that these kinds of events would only be send to widgets, namely, top level widgets, but I got one for my application, and Qt plainly ignored it. So I went further ahead and tried to quit the application directly when the event occured, similar to this

bool MyApp::event(QEvent * ev)
{
    bool eaten = false;
    switch (ev->type())
    {
        // other stuff ...
#ifdef Q_WS_MAC:
        case QEvent::Close:
        {
            quit();
            eaten = true;
            break;
        }
#endif
        default:
            eaten = QCoreApplication::event(ev);
            break;
    }
    return eaten;
}

but this didn’t work out so nicely: while the application quitted correctly, the `quit()` slot was apparently called twice in a row. My guess is that Qt ignores the `quitOnLastWindowClosed` property – which I’ve set to false – and since I close all windows in the quit slot it executes quit again, or something else, so I decided to just close all open windows when the `QCloseEvent` arrived – without calling `quit()` directly, and tada, my application quitted and the slot was also only called once. (This was a mistake on my side because I missed a break.)