guitone – Page 3 – dead fish

montone hackery

As promised a few days ago I’m writing a few words on the Monotone Summit which took place in Wuppertal from 28th of April to 4th of May 2008. I could only attend for five days because my train left already on early saturday morning, and I almost managed to get too late to it – must have been the absence of sleep, but lets tell the story from the start.

Before I arrived in Wuppertal on monday noon my feelings were a bit mixed about the event. On the one hand I had not attended anything like this before in my life, on the other hand I was completly puzzled what should actually happen there, because virtually no conversations or communication about possible topics happened on the mailing list beforehand. Given the fact that only seven people attended our little summit (me included) and none of the core hackers managed to ship over from the US, I was also unsure if it would actually become a success. Last but not least I was not sure if there was actually so much I could do for the project, being only a casual contributor who most of the time fixes UI / frontend bugs or works on the automation interface.

So after about five and a half hours train riding I found my way to the W-tec building and to the summit room we’ve been invited to use for the whole week. The ice broke pretty fast. Thomas Moschny, Dan Carosone and Lapo Luchini arrived earlier and were already discussing and working on different topics. Our hosts, Christof Petig and Siegfried Herbold, were also there and provided us with everything we needed (well, you know a programmer is satisfied if he gets coffein and occasionally something to eat :-)). Richard Levitte arrived later at the same day after getting horribly lost while navigating to W-tec by car. I must admit that I wouldn’t have done any better as a Swede in Germany.

Since our little crowd contained at least two interface gurus (Thomas Moschny, who is the author of TracMonotone and me obviously, the guitone guy), one of the main topics were improvements in the automation interface. We had and still have the strong belief that with a better, more complete interface it gets easier to connect monotone to all kinds of other software, thus increasing the uses and the amount of users over time.

Dan’s and Christof’s first topic was cvssync, which should help projects which are still stuck on CVS to get into touch with distributed version control much easier, by providing tools to push and pull contents from a CVS repository to and from monotone.

Lapo created a new grammar for selectors with the help of ANTLR which also led to many discussions during the summit (most of these discussions were lead by Dan :)).

On wednesday or thursday Lapo, Richard and Dan started on moving our existing, completly spammed MoinMoin wiki installation over to ikiwiki. The nice thing about ikiwiki is that it provides many different backends to version control systems, so our new wiki (temporary URL here) actually has a fully blown history, merge support and can be edited just from our local command lines – neat! My task later was to make it look a bit prettier and similar to what our front page looks like – easy, given the fact that I don’t do much else on my daily job…

Beside working on the automation interface (here especially ticker support for commands which need those, like f.e. push, pull and sync) I did some work on guitone. Lapo gave me input for the file diff dialog (which now displays correct line numbers).

Christof and me also started on thursday working on a TortoiseMonotone version. Christof stole some code from TortoiseHg (which astounded us is completly written in Python!) and wrapped his head around the Windows API, while I started the work on making interfacing with guitone possible, in particular preparing guitone on the other side to make it run mainwindow-less on request. This was actually pretty easy thanks to the fact that I introduced the dialogmanager wrappers in 0.7, so main windows and dialogs were only roughly coupled together.

(Lapo, Dan, Christof, Thomas M. and Siegfried [from left])

More stuff will probably fall out within the next versions of monotone and guitone, when more work and polishing is done on the projects which just started at the summit, so don’t expect that everything is already in place the next time you pull the development head of either project.

In the end these five days have been a great time for me, because I finally met some of the people I only knew from IRC or the mailing list and I got the strong feeling that the monotone community – despite of all the competition it has to face – is still alive and keen on working on this great software.

Christof was an awesome and gentle host for Richard and me during the time – we’ve had our own little appartment in his house and he managed to spend a lot of time during the summit for us even though he has a wife and two kids which obviously needed some care as well. This was not always easy, given the fact that our usual day started on 9:30am and ended between 12am and 2am in the morning. I guess he needs a vacation after this “vacation” – so Christof let me repeat my invitation: If you ever want to go east and visit Leipzig, you’re very welcome here!

(Richard and me)

Perverted Logic / Monotone Summit

If you like to have a laugh today, read this. Found via Rob Weir’s blog.

The Monotone Summit goes on and its quite fun to meet and work with all the people I just know from IRC or the mailing list. I mostly worked on automation stuff so far and improved some things in guitone. A longer blog entry with other impressions (and maybe some pictures) will follow within the next days…

Google Summer of Code 2008 is up…

…and neither guitone nor monotone will be a part of it.

Google just put the list of mentoring organizations online and our direct competitors, namely git and Mercurial, of course got slots. On #gsoc on Freenode a Google employee told the crowd about a total of 505 applications this year, where only 20 or so have been spam, so it seemed to be a rather hard selection on Google’s side as well, because in the end only 175 organizations could be accepted, mainly for organizational reasons.

Now while I was almost sure that my application with guitone would not be accepted (this was kind of already written in the FAQ), it is surely a shame that we couldn’t bring up some ressources for a proper application for monotone.

Sure, no application is better than a half-baked application, which, in the end, may create bad karma and reputation for the project itself, but still, I’m feeling a bit depressed right now.

Maybe next year… in the meantime I hope people are at least willing to work on a successful European Monotone Summit…

Summer Of Code 2008 / guitone Status Update

I’ve just read on Slashdot that applications for this year’s edition of Google’s Summer Of Code start in early March. I’m thinking about pushing this a little more this year for the monotone project, since we kind of “missed” it last year (we sent in our application too late). And I’m positive to also place at least one possible project for guitone there. While it certainly makes a lot of fun to code with Qt, it would make even more fun if somebody could team up and help out here and there…

In the other news: monotone 0.39 has been released yesterday and I’m once again astonished how easy openSUSE’s build service makes it to create rpms for a great variety of distributions and architectures. I’m currently using it to build openSUSE rpms for monotone and guitone there and its really easy and fun to do that.

I’m also pretty actively hacking on guitone at the moment, fixing bugs and implementing new features there. There are still some things on my TODO list before 0.8 is ready to release, amongst fixing bugs, f.e.

make the filesystem watcher implementation usable and working properly, so guitone updates the workspace view in the background if changes happen to the underlying filesystem
implement some of the workspace commands with native calls (i.e. add, drop), rename / move will be slightly harder, also wrt to view updates, maybe I’ll implement simple filename renames at first

The following things already have been implemented and are definitely part of 0.8:

restricted commit (right-click on any file/folder and hit commit!)
diff possibility for patched files in the commit and changeset dialogs
a new panel to view, add, edit and drop database variables
improved, more user friendly startup dialog which now also contains possibilities to edit the preferences and load recent databases and / or workspaces
improved loading times for huge workspaces, f.e. loading the complete org.openembedded.dev should run a couple of times faster now
and much more…

guitone 0.8 will also be the first version of guitone to be released under GNU GPLv3. Now that the Trolls released Qt 4.3.4 recently which allows licensing the library under the very same license, I’m positive that this change will not introduce too many headaches to distributors. Otherwise, drop me a note via private mail and we’ll work out a solution.

Based on my current workload and other activities (Chemnitzer LinuxTage, anyone?) I hope to get a stable version out mid march. No promises on this, though 😉

guitone 0.7 released

guitone 0.7, my Qt-based monotone GUI, has just been released today. Most of the changes over the past 9+ months since the latest major version are under the hood, so there are only a few “new” things you can actually see (most notably the
file history browser, a new icon set and numerous other improvements in existing dialogs).
The main reason for all the internal overhaul is however, that guitone should now run much smoother, faster and less crash/error prone than previous versions. It also includes better mtn error detection and fixed some of the outstanding platform bugs on Mac OS X and Windows.

A complete overview of all the changes can be found – as always – in the
NEWS file. Make sure you grab your copy here.

If you encounter any problems, have suggestions or anything else, drop
me a note or open a new task in the task tracker.

And here is finally the mandatory screenshot – click to see more screens:

Step by step

Over the last few months I’ve worked on a new monotone interface for guitone from time to time. This new interface supersedes the old one in a couple of aspects; the most important one is that it runs the monotone processes in separate QThreads instead of the main GUI thread. I hope this will make many unexplainable locking problems on Mac OS X and Win32 vanish, which especially pop up when starting the application up or – weird enough – when the application is run as non-root user (Win32).

Rewriting something so important almost from the scratch is very tedious. Since it basically affects the whole application, the head of the net.venge.monotone.guitone branch has been and probably will be broken for a while. This is actually the first time I appreciated the fact that you can compile single source files step by step with make, just by triggering `make target_dir/filename.o`, so I’m kind of proud to say that I already have the actual thread class, a task item and a thread manager working (i.e. they compile ;)) – and I just finished the new utility class which supports synchronous queries to the thread (with the help of QEventLoop), which otherwise has a pure async i/o.

Sure, there is still a lot of work left and this work could be done faster if I wouldn’t be the only one right now hacking on this project (*wink*, *wink*, want to join?) – but at least I have the feeling that I’m getting somewhere now. And maybe I get even more impressions how to do things _better_ if I come back from the Trolltech Developer Days 2007 in Munich (16th and 17th October), whose attendance is sponsored by my company and Trolltech themselves.

Yes, thats right, they invited me to go there for free; a normal entry would have cost me nearly 600 Euro! And all this just because I develop this nice little Open Source application named guitone – isn’t that great?!

guitone 0.6.4 released

This is mainly a compatibility release so that guitone 0.6.x keeps working with newer monotone versions like the recently released 0.36. There are no new features or bug fixes included.

Please note that it won’t be possible to use monotone 0.34 or monotone 0.35 with this version of guitone due to a incompatible change in the monotone interface. Use guitone 0.6.3 or earlier for that purpose.

Grab your copy of guitone 0.6.4 here.

The work on 0.7 still goes slowly after having decided to completly redo the internals with QThread support. However I’m always open for help ;).

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 =)