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.

A couple of weeks ago, I said I would not be backporting the latest versions of Glib2, Gtk+, GStreamer, etc to Hardy.

Today I decided I needed a newer GStreamer on my Hardy machine (where I build and use KDE from trunk almost daily) because I wanted to use libQtGstreamer.

As I expected, this requires major surgery to Hardy. Two prominent components of Hardy, ffmpeg and PulseAudio, require relatively recent versions. I don’t even know if it’s possible to build them due to limitations in Hardy’s kernel V4L2 support. In addition to that, I’m leaving on holidays to London and I won’t be able to work on this until next Wednesday.

Summary: IF YOU USE MY PPA AT THIS MOMENT, IT WILL BREAK YOUR HARDY INSTALLATION! BE VERY CAREFUL IF YOU RUN APTITUDE FULL-UPGRADE! I don’t like having the PPA broken for so long but I have to wake up in 4 hours and I really need to get some sleep.

E-mail arrived a couple of days ago from Will E. from School District #33 in British Columbia, Canada:

Also thank you for all of the work you have put into your package archive. (we use your archive here in our school district on almost 1000 Kubuntu workstations and servers)

Wow, thank you! These e-mails are really motivational and encouraging!

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