In my year of absense from writing anything here at all, it wasn’t necessarily only because the year was awful - although it kind of was, not just for the world at large, but also for more personal reasons – a subject for another post, or perhaps not.

Regardless, when I did eventually turn my attention back here, I managed to come back to find that Jekyll could no longer generate the same blog I left - even without any alterations or new content.

I first found out that jekyll couldn’t tell the time. In the less destructive cases, I had posts that were being timestamped an hour or two off where they should have been. In worse cases, they were a full day off the correct times. Sigh. I searched around a bit and I can now confirm, in case you were wondering, that dates and times are still awful in software.

I don’t know if that is precisely the issue I hit (because again, I just wanted to move on past all this and start actually doing things), so my workaround was to just remove dates off everything, because really, who needs to know what time of day I write things anyway. One s/([0-9]{4})-([0-9]{2})-([0-9]{2})T.+Z\'/\1-\2-\3'/ later, and my posts were pretty much as they should be. I have to ask, though, why in the actual fuck does a static content generator like jekyll care about timezones? The dates and times I give you are the dates I want displayed.

Oh, and for whatever reason, before I could even try to generate things, I had to gem install jekyll-paginate and add gems: [jekyll-paginate] to my _config.yaml - I don’t know what caused this (I didn’t bother to do my homework, as the solution was easy enough). I’m sure this was a change made with the best of intentions, but it certainly wasn’t helpful when I’ve already been struggling with the motivation to write anything at all.

Once I got past all that, though, it wasn’t all bad. I finally fixed the Makefile I use to write here to automatically generate title metadata for Jekyll (one less piece of friction involved in writing a post):

post:
    $(eval POSTTITLE ?= $(shell read -p "Post title: "; echo $$REPLY))
    $(eval POSTTITLE_ESCAPED ?= $(shell echo "${POSTTITLE}" | sed 's/ /-/g'))
    $(eval FILENAME := $(shell date +%Y/%Y-%m-%d-${POSTTITLE_ESCAPED}).md)
    mkdir -p _posts/$(shell date +%Y)
    cp _drafts/.template.md _posts/${FILENAME}
    sed -i '' "s/\%TITLE/$(POSTTITLE)/" _posts/${FILENAME}
    sed -i '' 's/\%DATE/$(shell date "+%Y-%m-%d")/' _posts/${FILENAME}
    vim _posts/${FILENAME} 

I’m sure this isn’t ideal somehow, but I didn’t want to deal with some kind of exotic language or system with dependencies back when I started, so I’ve just been gradually making this more arcane to (somehow) accomplish what I want. I don’t have a clue about Makefiles, so this is all trial-and-error. So sue me.

It’s still not perfect, because it means when I want to rename a post (which happens a lot after I start writing, as I did a few times on this post even), it means that I have to figure out how to do the escaping for the new filename, locate it in the awfully structured directory tree, and remember to change the title attribute. But I suppose this is the price I pay for not using a fancy web interface anymore.

Not that I miss the complete shit that blogger’s web interface generated instead of writing my posts in Markdown.

I think next, I want to figure out how to generate tag-based archives again – I did some initial research and it doesn’t look too difficult, just a matter of actually trying it out. And then I need to start actually using tags again, and maybe making the Makefile nightmare even worse, to help me tag a post.

I didn’t write anything about that year here so far. Let’s just say I figure that enough already has been said about that one. Here’s to 2017.

Qt, as a framework, makes extensive use of touch - particularly on mobile and embedded devices. Unfortunately, Qt isn’t readily able to magically make touch input appear on hardware that doesn’t support it, which can make exact testing of touch-related code difficult in typical developer environments – not a very desirable situation for a cross-platform development framework.

Thankfully, someone else has thought of a solution that helps to fill this gap, in the form of the TUIO protocol. TUIO is a specification for a protocol to encode touch events to be sent over a remote transport (such as a network).

In practice, this means that one can create a server that synthesizes touch events and sends them to an application, even if it is running on a completely different physical machine.

For example, there are a number of mobile clients such as TUIOPad and TUIODroid which can be used to take touch events from a mobile device (such as a phone or tablet) and send them to a remote TUIO listener.

I came across this last year, and thought the idea was pretty neat, so I went off and built something to bring this to Qt users - the result was an input plugin for Qt which listens for touch events coming in from a TUIO source.

This was made easy in that in the Qt 5 world, things such as input and display are abstracted away from the core of Qt itself, so that one can easily provide an additional input source.

show me!

If you’d like to check this out yourself, it’s easy! Grab a copy of Qt 5.5 (the alpha just came out, and that will do nicely), and build it as normal. When running your application, use the command line argument “-plugin” to tell Qt to load the TUIO input plugin as follows:

mytestapplication -plugin TuioTouch:udp=40001

The udp=40001 tells the plugin to bind to the UDP port 40001 and listen for incoming TUIO traffic.

known limitations

There’s a few caveats, here.

• Only UDP sources are supported, although other transports would not be impossible to add
• Sources are bound on QHostAddress::Any, meaning that your network is considered “trusted”
• Only a single TUIO server is supported. Multiple senders on a network will not intrinsically break, but it won’t work well.
• Only the 2dcur TUIO profile is supported at this time.

Patches are more than welcome! (to src/plugins/generic/tuiotouch in qtbase).

technical details

TUIO at a high level is a specification of events. The actual wire protocol used by TUIO is a seperate specification called “OSC”

• Open Sound Control.

The plugin contains a simple OSC parse (QOscBundle and QOscMessage) for handling the wire protocol parsing, and on top of that, a handler for TUIO messages (QTuioHandler).

QTuioHandler is responsible for receiving TUIO messages, using the OSC classes to parse them, and creating touch messages to send to QWindowSystemInterface, to notify Qt about the events. QWindowSystemInterface subsequently takes care of letting the application itself know about the touches through the regular and well known QTouchEvent interface.

The application can then consume the QTouchEvent without having to know about the origin :)

I’ve been working on moving away from Google for a while now. I have a lot of reasons, but the primary one is that I don’t like the feel of being a product rather than a consumer. I want to be in control of my own data, and how it is used and disseminated. With Google in control of it, I never really felt I had that, and it was only getting worse with time.

Anyway, 2015 has been a good year for making good on this resolution:

• I moved to using DuckDuckGo a few weeks ago
• About a week ago, I migrated my blog’s data to Jekyll (which you’re reading, right now).
• Most recently, after getting annoyed at Google once again, I finally got annoyed enough to take the last, most drastic step: email, calendaring and contacts.

I was on my second email account with Google. My original one was a Gmail account, created back in 2005 or so (I don’t even remember anymore). I stopped using that one in fan of using my own GApps account with my own domain (shared amongst other people in my family) in 2011 or something like that.

My migration plan went something like this:

• Sign up for FastMail (business tier, partly because we’re using it as a family, and partly because I actually have my own business, and partly because I want to support FastMail)
• Start FastMail’s IMAP import
• Clean up the imported stuff (my email has a long-going reputation for being a junkyard where important things go to die)
• Export ICS/VCard for my calendar & contact data out of Google and import them into FastMail
• Delete everything out of my GMail account

All of this went pretty painlessly, and so far, I’m very happy with the switch. I’ve found one pretty serious bug with FM’s iOS client which I need to report, but aside from that, smooth sailing. I look forward to writing my own JMAP client, when FastMail’s servers support it.

At this point, I’ve still got the Google account open (but now, dataless) so that I can keep G+. That (and occasional recreational YouTube video watching) are the only things I still have Google in my life for, and it feels pretty good.

It’s been a good run, but when you read this, it won’t be hosted by blogger anymore.

I’ve had hideous experiences with blogger being full of bugs in the past, and none of these issues ever seem to get any better. That, in conjunction with my not being happy with other people being in full control over my data.

So I figure that it’s time for a change.

Getting the text of my posts into Jekyll was pretty easy (thanks to the importer plugin). Unfortunately, the source text is in unimaginably bad HTML (thanks, blogger), so I hope I don’t ever need to go back and adjust formatting or anything.

Images are also hosted on blogspot, but there don’t seem to be too many. I’m not sure I’ll bother trying to migrate them over (I spent far too long trying to write some scripts to do that, and not having much luck).

We’ll see.