From This Day

Hey there, QOAuth 1.0.1 is out. Here’s the changelog:

• new API (refer to the API docs for more info):
  • QOAuth::Interface::networkAccessManager()
  • QOAuth::Interface::setNetworkAccessManager()
  • QOAuth::Interface::ignoreSslErrors()
  • QOAuth::Interface::setIgnoreSslErrors()
• added missing export statements to some global functions,
• Percent encode consumer secret and token secret for the Signature Base String signing key [#8],
• Parse for request content when sending POST [#10],
• API docs and examples fixes [#9],
• temporarily removed QOAuth::DELETE from QOAuth::HttpMethod enum on Windows [#4],
• buildsystem fixes – install under /usr/lib64 on 64-bit Unix-like systems and fix headers installation path in oauth.prf.

There is a room for future improvements, but I’m in terrible lack of free time (or time that I can spend on developing QOAuth), so I can’t promise anything at the moment. If there’s anyone that can help me with QOAuth, I’d be extremely happy to share the work.

Also, I’m not going to maintain QOAuth on Windows anymore. Sorry for that, but I have no Windows box and having to care about Windows stuff with no Windows machine around makes my life even more miserable… Again, I’d greatly appreciate a Windows maintainer for QOAuth. If you happen to use the library on Windows, and you find it more or less useful, please consider contacting me (d at ayoy dot net) regarding handling QOAuth releases for Windows.

Thanks a lot :)

Lastly I improved some things in the QOAuth library, also did small code refactoring and provided new functionality. All in all, I’m pretty much able to call the new version 1.0 and say that it’s mostly feature complete. Here’s exactly what I did:

• Added support for RSA-SHA1 signing algorithm, also working with passphrase-protected private RSA keys. Passphrase is passed as a QCA::SecureArray, so it won’t be cached on disk or left in memory after quitting the application.
• Added initial support for PLAINTEXT authorization. It seems to be working, however it may fail with untrusted SSL connections. I didn’t find a service that takes PLAINTEXT into use, only tested it with a test server which communicates over HTTP (unencrypted). But still, if anybody uses PLAINTEXT authorization and provides untrusted server to handle it, it kinda sucks…
• inlineParameters() extended by the parameter specifying parsing method – now it’s usable for both GET and POST requests,
• Introduced the QOAuth namespace, with QOAuth::Interface class holding the core functionality.

The detailed documentation (together with simple usage examples) resides here. The library was tested with a test server at http://term.ie/oauth/example and appears to be working. The test set is distributed alongside the library. I also use QOAuth for communication with Twitter API in qTwitter and find HMAC-SHA1 signing working properly.

The source code repository for QOAuth is hosted on GitHub. The framework for MacOS X as well as packages for several Linux distros are available from qt-apps.org. Gentoo users do emerge qoauth :)

Lastly I spent some time looking for a decent OAuth support for C++. I found that the only available libary (which is actually a pure C code), surely does what I expect, but provides pretty complicated API making it inconvenient to use. And I’m kind of a lazy guy (oh who’s not :-) ) and I’m getting scared with just thinking of writing tens of lines of code to complete just a single OAuth request. Plus, instead of endlessly converting from QString and QByteArray to char* I’d prefer to have some friendly, Qt-compatible way to deal with the whole OAuth thing. That’s how the idea of QOAuth came up.

Last time when I was deploying a Qt application on MacOS X I spent several hours struggling with otool and install_name_tool to make my app see all the bundled Qt frameworks and plugins. Then I found out that there is a dedicated tool for it, called macdeployqt and, what is more, it’s nothing new. To be honest, it’s so well known that it is currently shipped together with Qt. Shame on me.

Great then, macdeployqt reduces the deployment work to one line in terminal, and time thereof to several seconds :) However, my application, apart from Qt frameworks uses other custom, self-made frameworks that depend on Qt. It seems that macdeployqt doesn’t support deploying frameworks, as it searches for application binary located in <bundle_name>/Contents/MacOS, which simply doesn’t exist in a framework bundle. So I created a simple script, called frameworkdeployqt.pl that does the dirty work of deploying frameworks written in Qt. The basic concept is:

1. you want to deploy a Qt application on MacOS X,
2. your application uses custom/self-made/third-party frameworks written in Qt,
3. all the frameworks are going to be located in <bundle_name>/Contents/Frameworks.

Then you deploy the application in two simple steps:

1. run macdeployqt to copy needed Qt frameworks to the application bundle and adjust its internal framework references,
2. run frameworkdeployqt.pl to make your custom frameworks use Qt frameworks bundled with your application. You’ll of course need perl, but it comes out of the box with MacOS X.

The script looks for non-Qt frameworks inside the bundle given as an argument (namely, it searches <bundle_name>/Contents/Frameworks for frameworks other than Qt*) and then replaces their references to Qt frameworks so that they point to the ones that macdeployqt have just copied to the bundle. For now it’s a bit dumb, i.e. it doesn’t check the existence of Qt frameworks, so if your custom framework uses other Qt modules than the application (or macdeployqt somehow failed to copy them), you’ll have to copy them manually to the bundle.

Other drawback is that you can’t create a dmg image directly using macdeployqt, but anyway, if you happen to need frameworkdeployqt.pl, that dmg would have been useless for you.

The script is available from GitHub. Enjoy!

Indeed, here comes the new qTwitter. Mainly a bugfix release, but there were some annoying issues that couldn’t wait to be fixed. Details are covered in changelog, as always. And I finally went for documenting things. All in all, I’m happy to announce qTwitter 0.4.1. Available from usual places, such as qt-apps.org or GitHub.

There’a also one more thing I’d like to share — my tiny contribution for QtCreator:

I have to say that it’s a pleasure to me to help promote Qt and QtCreator, and I really really owe Alexandra from Qt Software for contacting me about the whole thing. Thanks!

So we finally have Qt 4.5 released! And we finally have a stable QtCreator! Too bad that their servers almost can’t stand the load that everyone produces downloading the fresh new framework. But this particular thing was totally predictable. Anyway, I luckily managed to get Windows release in 2 hours and now waiting for a Mac one — unfortunately torrent downloads don’t help in this case.

Back to the topic, what’s new for the first sight? Well, the main page has changed… ;) So back to the topic, we have the LGPL licensing, expected by lots of developers. Mac users get Qt ported to Cocoa, supporting 64-bit processor instructions. Performance improvements, QtWebkit improvements, QtDesigner improvements, QtLinguist improvements, improvements, improvements, improvements… You’ll find the full list here. And finally, the QtCreator 1.0 is ready to rock. They put it together with Qt framework and called Qt SDK — I personally hate this word, it sounds so damn “professional”… But it doesn’t matter now, I just can’t wait until the download finishes so I could dive deeply into Qt 4.5 and check it out by myself :)

If you didn’t yet, get (or better start getting :P) your Qt 4.5 copy from qtsoftware.com now!

Ok, it’s high time. I’d like to present you my first app shown to the world. qTwitter is a Twitter client written in Qt. The current version is 0.4 and it seems to be pretty stable at the moment. It is based on a http connection to the Twitter REST API, parsing the requested XML data and displaying processed info in a list pimped with customized item widgets. As for usability, it provides:

• getting public or friends timeline + (optionally) direct messages,
• posting (including replying and retweeting) and deleting updates,
• being recognized as a source of updates,
• UI color themes,
• HTTP proxy support,
• translation to Polish, Catalan and Spanish (poor ones, but anyway),

and it looks more or less like below:

It’s actually my first complex decent application in Qt, and in the same time a thing thanks to which I learnt a loooooot of Qt — and I still do. Concerning the code itself — I realize that it’s pretty messy at the moment, but I’m still working on cleaning it up so that it can be easily understandable. The source code for qTwitter is hosted on GitHub, and the app is also available as a binary for MacOS X and several Linux distros at qt-apps.org ← you’ll find there more information as well as the full changelog. Go and check it out now!

Those who ever happened to write an application for Mac have to realize the existence of Property List files – for storing user’s settings and defining details on app’s behavior inside the OS. For example, if you want your application to be an agent, i.e. run without menu bar and Dock icon, you set the appropriate flag in the Info.plist file inside the application bundle:

  1
  2

<key>LSUIElement</key>
<true/>

Fair enough, if you’re an Objective-C Cocoa developer. But if you’re, let’s say, a C++ Qt programmer deploying your app on Mac OS X as yet another platform, you can end up with such a flood of (probably) unexplainable errors:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21

ayoy@batory repo % ./qtwitter.app/Contents/MacOS/qtwitter
2009-02-22 00:14:40.420 qtwitter[46617:10b] *** _NSAutoreleaseNoPool(): Object 0x1315f30 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x9330173f 0x9320de32 0x92f1f1b1 0x92f1f21d 0x92f1f271 0x92f1d90c 0x92f1d9d2 0x92eb5b17 0x3d1f2b 0x9a3e08 0x94fd23 0x950096 0x6b64 0x653b 0x6469)
(... boooooring ...)
2009-02-22 00:14:40.428 qtwitter[46617:10b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFBoolean length]: unrecognized selector sent to instance 0xa03d8400'
2009-02-22 00:14:40.429 qtwitter[46617:10b] Stack: (
2465300747,
2491215419,
2465329930,
2465323276,
2465323474,
2464897815,
4005675,
10108424,
9764131,
9765014,
27492,
25915,
25705
)
zsh: trace trap ./qtwitter.app/Contents/MacOS/qtwitter

Not that I dislike Macs, but that’s really uncool. Strictly speaking, the program is failing badly when trying to create an instance of QApplication. And this applies at least to Qt 4.4.3 and, as I suppose, the previous releases too. Now here comes the good news — we already have a release candidate of Qt 4.5, which can cope with the LSUIElement setting. So if you experience such a problem, just switch to the newest Qt available, it should be stable enough in most cases. And if you’re afraid of release candidates, just wait these few days until it becomes official.

Just a note here, if you would have to pass custom data types between threads in Qt. As we know, a signal-slot connection is then (by default) of type Qt::QueuedConnection. Because in such a situation Qt needs to store passed parameters for a while, it creates their temporary copies. If it doesn’t recognize the passed data type, throws out an error:

QObject::connect: Cannot queue arguments of type 'MyType'

So custom data types have to be registered using qRegisterMetaType(), like in the example:

qRegisterMetaType<MyType>( "MyType" );

And this example is literal ⇒ when your class is called MyType, you register it as "MyType". Lastly I did something similar to this:

  1
  2
  3

typedef QMap<QString,QImage> MapStringImage;
(...)
qRegisterMetaType<MapStringImage>( "images" );

I didn’t get the error from QObject::connect (!), but also didn’t get things working. Wasted few hours hacking QMetaType class with no effect, and then more by accident than design changed "images" to "MapStringImage" and woo-hoo! That was my only problem… That’s why I’m stressing this naming issue, especially that documentation doesn’t tell a lot about it.

BTW I needed to use typedef because otherwise Qt didn’t have a clue what to do with such a complex type.