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.
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.
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).
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).
When Gitorious first opened up, I jumped on it with open arms and pushed up quite a bit of stuff there. I migrated some of the larger group projects I worked on, such as InspIRCd there, contributed to others, and made my best to use the place, generally.
And after a while, I found myself increasingly getting frustrated with things. The UI was clunky in a lot of places, buggy in others (merge requests and the like in particular caused a lot of grief to me), and there was no real insight or visibility about the problems or work happening to fix any of that. So, I migrated my personal projects to Github, InspIRCd also moved to Github (once I noticed that it had been in a period of lull for quite a long time), and as far as I can tell, nobody really looked back.
I'm not sure what to make of any of this, if it's a case of complacency on the part of the people involved, or simply a "worst possible storm" of multiple factors, but I certainly can't say I'm surprised, one way or another.
The only thing that does surprise me, is that it took this long.
Or, "why I won't be buying it again".
Some of you might have heard of Chocolat. Some of you might not have, so here's a quick summary. It describes itself as a "Native text editor for Mac".
But soon after, OS X Yosemite bursts onto the scene.OS X Yosemite was announced and released to developers on June 2, 2014. The public beta was released on June 24, which I upgraded to on day one. I work on a lot of software, so it's kind of natural that I'm on the close-to-bleeding-edge, so I can make sure that things work.
Chocolat, unfortunately, didn't work on Yosemite. It crashed. As I don't use it all that much, I didn't mind, figuring that this would get sorted out sooner or later. Aside from that, my Yosemite story has been pretty painless and enjoyable.
This week, I finally decided to give Chocolat another try, figured out that version 3 supposedly doesn't crash on Yosemite, and got redirected to http://chocolatapp.com/3/. Right up there, in green font is this:
It costs money because, well, it's a major upgrade. Not too much visible on the user end, but apparently there was a lot of technical debt that needed to be paid down. I can respect that.
On the other hand, it's free for Mavericks users because 2.x crashes on Yosemite, and if it wasn't free for users before they upgrade, there would probably be a lot more pissed off people.
Meanwhile, everyone who stuck with Mavericks gets it for free, because otherwise, there would be no "smooth upgrade path" (read: a lot more pissed off people). I'm sorry, but where the hell is my "smooth upgrade path"?
What am I going to do about this? Well, I'm definitely not going to buy Chocolat for the second time in a year. Apparently, it's pissed enough other people off that they had to write a "FAQ" page about it. But an FAQ page doesn't give me the working software that I paid for already.
As an aside, I was originally not going to write about this, and just let it slide (it's not like it's expensive software). But then I actually talked to the author about it, and the answer I got could be tl;dr'd down to "well, but don't you think I should get paid for the work I did on v3?" to which my answer is "sure, but I already paid you two months before I stopped being able to use it". And that got me annoyed enough to write this post.
I'll be clear here: I have nothing wrong with the authors of software getting paid so they can keep writing software.
What I do have problems with is buying a product and not being able to use it two months later. And still not being able to use it once the admittedly beta operating system I was on at the time is out in public release. Especially when everyone else is able to upgrade without a second thought.
And that's why I'll be avoiding Chocolat in the future.