As a quick post, someone at work mentioned putting an at-a-glance "is something broken" display on a dedicated monitor or few at work; that led to me writing StatusBoard yesterday/today:

If a test doesn't pass, the relevant item turns red. It's configured via JSON (example included), and supports full-screen mode, and has an optional system tray icon. It basically fetches a web address. It supports:

• A different refetch interval for each item
• A pattern for a revision number
• A pattern that must be matched to count as a 'pass'
• A pattern that must be matched to count as a 'failure'
• Another pattern to limit the scope of the 'pass'/'fail' patterns
• HTTP + HTTPS (well, anything QNetworkAccessManager supports)
• Ignoring SSL errors, such as self-signed certificates
• Linux + OSX + (probably, but untested) Windows

The source is available via git, under the GPLv3.

git clone http://git.fredemmott.co.uk/repo/statusboard/

See the README file for build/configuration instructions.

Slamd64 12.2 is released, and is an incremental improvement over 12.1, including:

• Linux 2.6.27.7
• GCC 4.2.4
• Apache HTTPD 2.2.10, with SSL support and PHP 5.2.8
• Updated development tools
• KDE 3.5.10
• XFCE 4.4.3
• Mozilla Firefox 3.0.5
• Mozilla Thunderbird 2.0.0.19
• Sun Java (JRE and JDK) 6u11

Like previous releases of Slamd64, 12.2 provides seamless FHS-compliant 32-bit compatibility, via a multilib system (/lib for 32-bit libraries and /lib64 for 64-bit libraries). This provides easier and increased support for both existing 32-bit software (in most cases, you can just install a package designed for Slackware with no special work needed), and for 64-bit binaries too (which require /lib64/ld-linux-x86-64.so.2 to be present) such as the NVidia drivers, without requiring compatability symlinks which clutter the root directory and remove the separation of 32 and 64-bit binaries.

nspluginwrapper is still included in c/, allowing you to easily use 32-bit browser plugins (such as Adobe Flash) in the included 64-bit browsers, such as Firefox and Konqueror - given the availability of prerelease 64-bit versions of Adobe Flash Player and Sun's Java Plugin, this will hopefully vanish soon.

As per usual, there's several people that really deserve my thanks:

• Carlos Corbacho - again, a huge amount of contributions to Slamd64, in many areas.
• Andrew Brouwers - many contributions and support.
• Joshua Wood - many contributions and support.
• Patrick Volkerding - for making Slackware
• Everyone who's helped with bug reports or support on the forums/IRC
• The residents of a variety of IRC channels (you know who you are)
• Distributions I have taken compatability patches from; especially Cross-LFS, Gentoo, and OpenSUSE

Additionally, as announced previously, support for 11.0 will be dropped shortly.

On an unrelated note:

Because of this, I've started writing FastCGI-Qt, a library to make writing FastCGI applications using C++/Qt as simple as possible - as demonstrated by the example on the first page of the documentation (more are linked at the bottom of that page).

It is currently only tested under Apache HTTPD 2.2 with mod_fastcgi-2.4.6, but supporting other servers is on my to-do list.

The current feature set is:

• Handle communication with the mod_fastcgi, and create instances of your class as necessary to respond to each request.
• Makes HTTP headers and POST data available.
• Parses any form-encoded variables on the query string.
• Provides a stream interface for reading POST data (responders will be created before POST data has been received).
• Parse variables defined in form-encoded POST data (this blocks if the POST data is form data and there is still un-received POST data.
• Defaults to a content-type of text/html and 200 OK status, but this can be overridden if nothing's been sent to the client yet.
• Each application executes requests in parallel, in a thread pool of QThread::idealThreadCount() (typically the number of cores in the system) threads.
• It should handle multiple requests multiplexed over one socket, but mod_fastcgi doesn't do this, so it's untested.

My short-term plans for it include:

• Adding output buffering support.
• Adding support for FastCGI authorizers, not just responders.
• Providing a Responder subclass that you can inherit from and maps request URLs to public slots.
• Writing something non-trivial using it.

It's under the ISC license (with the exception of an internal header file from the fastcgi dev kit, which is under the fastcgi license); there's also QxtWeb which is somewhat similar, but uses SCGI instead of FastCGI, has a different end-user API from what I'm aiming for, and (currently) is only under a GPL-incompatible license.

Jerboa's had a fairly major UI change (well, given the amount of UI there is, there's not much to change), and while the toolbar takes up much more space, I think it's better and more consistent. I also got around to making a DMG for mac users (windows users: MSI coming soon, builds and works fine though - linux users: cmake/qt4.4 from source). I've still not managed to hit my feature plan for 0.3 yet - when it's done ¬_¬.

I've also been working on a typing game, called TypoFail - only source so far for it though, and a screenshot or two:

The first is a clone of the amazing timewaster TypeRacer, though without the lag issues that annoy me over wireless; the latter is a clone of the venerable 'typespeed' game.

In the first mode, you type the quote as quickly as possible, and your score is your WPM. In TypeSpeed mode, your score is the number of characters in complete words you typed before you fail (10 words reaching the right hand edge of the field is a failure).

The game supports multiplayer (and pops up mini game windows showing your opponent's state), though requires a manually set-up standalone server at the moment. One neat thing about the quotes mode is that it reads fortune-format files, so you can easily load up whatever quotes you like - it'll even recognize ones which look like a dictation/IRC log:

Both of these applications are pure Qt4, and work fine on Windows, Linux, and OSX - though TypoFail's networking requires JsonQt, which it contains in a git submodule.

• JsonQt doesn't depend on bison, Boost::Spirit, or anything except a compiler, cmake, and Qt - easier for windows builds, and means I don't have to worry about syntax changes between one version of $parserGenerator to the next.
• QJson is written using bison - if bison's your thing, this can make it easier to fix errors.
• QJson can handle the top-level JSON "thing" being an array, not an object - JsonQt requires it to be an object.
• JsonQt provides both translation both ways

The last point I think is due to me misreading json.org - though it's easy enough to change (make it so that the main public functions take/return QVariants instead of QVariantMaps, and if trying to parse as an object fails, try to parse as an array).

Update: QJson has the bison-generated files in SVN, in addition to the bison source files.