Are you a developer and use ACE, TAO, CIAO? Do you use and/or deploy to Debian, Ubuntu or any other Debian-based distribution?

If you answered affirmatively to those two questions, you have probably noticed Debian still ships ACE 5.6.3, which is 18 months old. The reason is twofold:

  • ACE is a complex beast. The source tarball generates 59 binary packages for 5.6.3, and that’s only to increase in the latest version (5.7.4).
  • The only Debian developer working on ACE, Thomas Girard, is too busy at the moment. He did a great job maintaing ACE for years but now it’s time for others to help him.

Therefore, if you use ACE and Debian directly or indirectly, please step in and help me get the latest ACE in Debian. I’m half done but I’m having trouble with autotools (the autotools build system in ACE seems to need some love, I’m probably moving to the traditional build system) and I do not know where to put some of the new libraries (DAnCE, etc).

NB: The comments in this blog do not work due to a hosting issue, please contact me directly by e-mail: or subscribe to the pkg-ace-devel mailing list.

You probably know I love Wt, the Qt-like C++ library for developing webapplications. I gave up on Ruby on Rails and PHP when I started using Wt about three years ago.

Koen and Wim, the authors of Wt, happen to be from Belgium and they attended aKademy 2008. I “arranged” a metting between Koen, Wim, Richard Dale (the KDEbindings man) and me. We talked about how great Wt is, how much the API ressembles Qt and how nice bindings to other languages would be. Guess what? A few months later, Richard had adapted SMOKE to Wt and had developed Wt::Ruby bindings. Impressive.

I attended last year’s FOSDEM and there we go again: over dinner we came with a new idea. Google Gears makes it possible to run webapplications like they were desktop applications. But it’s Python, it requires a Python interpreter an a load of libraries. Can’t we do the same thing with Wt and generate a single executable by statically linking everything? Can’t we? Of course we can! In theory, it would be very easy: start Wt with its own embedded server (wthttp) in a QThread, then load that in a QtWebKit-powered browser. Koen put that in writing as a “>GSoC idea but EmWeb (the company Koen and Wim founded to support Wt) was not accepted as a mentor in GSoC 2009.

It took me a long time to get started with WtDesktop because I was busy with other stuff but two weeks ago I finally started to cut the meat. And it turned out to be surprisingly easy! Yes, WtDesktop works! It’s not in Wt, it’s not finished yet, but I hope I will be able to work on it and have something very nice in a few weeks time (get WtDesktop Technology Preview 2 here; TP3 is in the works, clone this repository)

What will WtDesktop have in the future?

  • Port autodiscovery (for now it’s hardcoded to run on port 9000, I’m having some trouble mixing Qt and Boost signals and slots to make it choose a new port automatically). This is almost done in TP3, which will be available soon.
  • Call-outs: let the webapp go out of the web and add menus, toolbars, etc to the application when it’s linked against libwtdesktop.so. Yes, you read it correctly: if you link against libwthttp.so you get a webapp with its own embedded webserver, if you link against libwtfcgi.so you get a FastCGI module you can serve from Apache, IIS or whatever, and if you link against libwtdesktop.so you get a desktop appliation. No changes to your code at all! I’d like to have some declarative language like QML for this but that’ll take some time.
  • Printing support. There is basic printing support (i. e. printing the whole page) already but I’d like to be able to connect buttons, frames, etc in the webapp to be able to print only some parts. This would require the above call-outs.
  • Session-sharing and session-stealing. Wt has all the DOM tree for each session in memory, therefore it is able to send the same HTML, CSS, DOM tree, etc to some other address. Session-sharing would be like Remote Assistance on Windows: you can see what the other client is doing but you cannot touch. Session-stealing would be like Remote Desktop: you can click, type, etc and the other client would see a “this application is being used by XXX (IP address: X.Y.Z.T)”.

So yes, attending conferences is definitely fruitful. By the way, I’m attending FOSDEM 2010. Let’s see if I come with some other great idea!

UPDATE: Added git repository

A long time ago I started hacking on a library I named libQtGit. As you’ll deduce from the name, it provides a Qt-like API to git, the stupid content tracker.

I had a vision for libQtGit: it was not an end in itself but a piece of a more ambitious framework/library tentatively named QVersioned or libQtVersioned.

QVersioned would provide QVersionedDir and QVersionedFile classes (amongst others, but those two are the most important). Those classes would essentially have the same API QDir and QFile have. QVersioned would open ZIP files and store a .git directory inside. There are cases, like ODF (which itself is a ZIP file) where nothing special is needed. For other cases (for instance, a .txt file), there would be a .txtv (meaning “.txt versioned”) which would be a ZIP file containing the .txt + .git directory (why ZIP? because it’s supported natively by Windows XP and newer and Mac OS).

Now, how did I intend to implement ODF versioning, which was going to be the “this thing works” case?:

  • The .git folder would store the uncompressed contents of the ODF file, i. e. XML, images, etc. This is needed to avoid duplication, allow diffs, etc
  • There would be also a full copy of the latest version (XML, images, etc) in the ZIP file, just like any ODF-capable application not supporting QVersioned would expect (these applications would just ignore the .git directory)
  • When a QVersioned-capable application opens an ODF file, it compares the XML, images, etc to the latest version in git:
    • If the diff is empty, last save was by a QVersioned-capable application, no action needed at moment
    • If the diff is not empty, last save was by a QVersioned-incapable application. A new “git commit -a” is performed. Yes, we probably have lost “versions” of the document in between this commit and the former one but something’s better than nothing.

By using libQtGit and QVersioned, it would also be possible to add collaboration features such as “send me an update” (i. e. send me a diff which transforms my outdated document into your latest version), collaborative editing (send diffs back and forth) and more things I cannot think of right now.

In case you are interested in the libQtGit API (remember QVersioned will offer a higher-level API), this is the signature of the method you would call:

Git::Repository::Commit* Git::Repository::commit ( const
QString& message = QString(),
const Commit* c = 0,
const QString& author = QString(),
const CommitFlags cf = DefaultCommitFlags,
const CleanUpMode cum = DefaultCleanUpBehavior );

That’s equivalent to “git commit -C commit_id -m “message” “.

CommitFlags is a QFlag and CleanUpMode a QEnum:

enum CommitFlag {
DefaultCommitFlags = 0x0 /*< git commit */, OverrideIndexCommit = 0x1 /*< git commit -a */, SignOffCommit = 0x2 /*< git commit -s */, AmendCommit = 0x4 /*< git commit --amend */, AllowEmptyCommit = 0x8 /*< git commit --allow-empty */, NoVerifyCommit = 0x16 /*< git commit -n */ }; Q_DECLARE_FLAGS ( CommitFlags, CommitFlag ) enum CleanUpMode { DefaultCleanUpBehavior = 0x0 /*< git commit */, VerbatimClean = 0x1 /*< git commit --cleanup=verbatim */, WhiteSpaceClean = 0x2 /*< git commit --cleanup=whitespace*/, StripClean = 0x4 /*< git commit --cleanup=strip */, DefaultClean = 0x8 /*< git commit --cleanup=default */ }; Q_ENUMS ( CleanUpMode )

For the "git commit -a -m "Save latest unversioned version on ODF document opening" ", we would use:

// Assuming 'repo' is a valid Git::Repository object

repo->commit ( "Save latest unversioned version on ODF document opening",
0,
"(The application would probably take the
author's name from the product registration)",
Git::Repository::OverrideIndexCommit );

So, how is libQtGit doing? Well, the API is there for git add, commit, init, mv, rm, checkout, clone, branch, revert, reset, clean, gc, status, merge, push, fetch, pull, rebase, config, update-server-info and (partially) symbolic-ref.

When I say “the API is there” I mean “all the QFlags, QEnums, methods, classes and its translation to git parameters is done”. It’s just a matter of implementing the QProcess part, parsing output, etc. Boring and
time-consuming but easy.

Given that I’m busy with other stuff, and some people have been asking for the code for a long time (sorry Riccardo!), I have just published what I have now. It’s unfinished, barely tested and yet to implement in many places. But it’s a starting point. It’s available now from Gitorious: http://gitorious.org/libqtgit/libqtgit

As for QVersioned, nothing is done yet.

Yesterday I learned Drobe, THE site for Risc OS and Acorn news was closing as its news service, thus remaining in archive-only mode. I have never used Risc OS or an Acorn and there is none in my classic computers collection but it is still sad news.

But I digress.

I cannot remember how but somehow, via Drobe, I discovered Risc OS had an Internet browser called NetSurf and it was available for Linux now. I backported the latest version (2.1) for Hardy and Jaunty.

Rendering-wise, it’s not too good. Plugins did not work for me and I’d say JavaScript is not working either. But there are some interesting points: NetSurf has its own rendering engine, split in several libraries:

Everything is MIT licensed.

Summary: NetSurf 2.1, libnsgif, libnsbmp, libparserutils and libhubbub are now available for Hardy and Jaunty from my PPA

If you are in a trusted environment, or you already have an alternative access/authorization mechanism in place, using SSH keys for git is sometimes an annoyance. Turns out you can easily get rid of that, although you should only do that if you are 100% sure what you are doing.

WARNING The following will make your git repository public and anybody will be able to write to it

$ touch .git/git-daemon-export-ok
$ git config daemon.receivepack true

If you receive the following error:

$ git push origin master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 323 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
error: unpack failed: unpacker exited with error code
To git://server/git/test.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to ‘git://server/git/test.git’

Make sure your repository is owned by the user running git-daemon on the server.

I’m going to use git for a project of mine and instead of parsing git’s output (which is the adviced way to use it from your application), I thought I’d rather use libgit and link to it. The first step was getting rid of autohell and moving to CMake.

This patch against git’s current master branch includes the CMakeLists.txt file and a few modifications to the source (mostly due to the different way variable replacement works in autotools vs CMake).

So far, only libgit, libxdiff and git are built. Will I go go for the other binaries (gitweb, gitk, etc)? I’m not sure, as I’m not interested but it shouldn’t be difficult to CMake-ize those.

I think the move from autotools to CMake could be very useful for the msysgit* developers, as they no longer would depend on MSys*

* I have not tried to build git on Windows with my CMakeLists.txt yet, I’ll do it tomorrow

** It’s not actually true yet: I run two bourne shell-scripts but I could easily rewrite those in CMake, too.

Update I’ve produced a new patch, as the old one did not perform a few needed renames

Most of my coworkers use Qt4 but only on Windows. Some of them did not even know KDE existed, much less that since KDE 4.1 there are official packages and an official installer for Windows.

Last week, I wandered around the office, occasionally assaulting people to show them KDE on Windows, the API docs, this-and-that widget, answering their questions (mostly technical), etc (if you know how tackatpromotioned Marble at past aKademy-s, you know what I did 🙂 )

So, what was the reaction of people to KDE? Surprisingly, extremely good! I was expecting more resistance to the fact that to use K* classes, KParts, etc you have to convert your QApplication to a KApplication but they went like “the advantages of using KDE classes and KDE’s ActiveX [that’s how some of them call KParts] are so obvious I will do that as soon as I installing a development version of KDE on Windows is easy”. People specially liked the Kate, oKular and KPlato KParts (although I showed KPlato 1.6 and only on Linux). The pie-like ToolBox menu in Amarok also received some praising.

My conclusion: I really think we should raise more awareness of KDE among Windows developers and the “wander-around-and-assault-for-no-reason” approach works very well. Try it with your Win32 coworkers and friends and blog about KDE on Windows. Let’s get some momentum for KDE4 on Windows!