(First, an apology in advance, this is a bit of a braindump, and as such, isn't very well structured.)

One thing which comes up quite often when I'm talking to developers new to Qt is the topic of strings, more specifically, character encoding: how to do it right, what options are available, and best practices.

Having written this a few times now, I thought that perhaps it was about time I write it up in a more permanent location (here) in the hopes that people will stumble across it and magically become enlightened, and end world hunger. ;)

Qt (and C++) have a number of different string types.

QString

Qt has a string type in QtCore called QString. QString, internally, stores data in utf16, and *does* have knowledge of character encoding.

Services across a network (like web services) often want data in utf8. QString, however, stores data in utf16. To get to utf8, you want QString::toUtf8(). To convert from utf8 back to utf16 QString (e.g. parsing input from a web service) see, QString::fromUtf8().

std::string

C++ also has std::string (although you won't find a lot of this in Qt applications). Simply put, it's a wrapper around a C string providing convenience operations and nicer syntax. It still doesn't have such (fairly essential) things like character encoding.

You probably want to avoid using this in an internationalized application or one requiring interaction with network services unless you find your own solution for encoding issues.

QString has ::toStdString() and ::fromStdString() methods if you must use them for whatever reason.

C strings (char*)

Finally, you have C strings (char*) which don't have any idea what encoding is, they are just a bunch of bytes.

Generally speaking, they're latin1 encoded (ASCII), to put them into a QString.. QString::fromLatin1(). If they aren't latin1, see QTextCodec::setCodecForCStrings().

QLatin1String class is also helpful - in particular, this will allow you to compile when using QT_NO_CAST_FROM_ASCII (which itself is helpful to make sure you explicitly give encodings for all of your strings).

I have written a lot of articles previously about project openness, and I've had this one cooking in drafts for a while without time to write much around the actual issues I'm presenting.

With some more thought, I realised that the best way to proceed is just to publish, and not point fingers and draw conclusions (though I certainly did write this with some projects in mind), so here goes.

• Do you reject contributions for non-technical reasons?
• Do you have development documentation (e.g. build instructions, architecture information) available for external contributors?
• Do you answer questions on design, architecture, etc. from external contributors?
• Do you work with contributors to polish their contributions and educate them as to best practices and your project?
• Do you let external contributors take part in design decisions?
• Do you hold external contributions to the same standards of review as internal contributions?
• Do you grant rights (such as commit access, ability to close bugs) to external contributors?
• Do you have a public means for (preferably real time) communication that you use?
• Do you have a public issue tracker?
• Do you use your public infrastructure wherever possible unless an issue is explicitly private?

Run your project against the list -- perhaps you'll find some things you can improve on.

If you've any suggestions to add to the list, why not write a comment? :)

Smart pointers are a great thing. When used properly, they can really help make life easier, and simpler. But things can, and do, occasionally go wrong - and that is when the hurt comes in. Qt provides a number of smart pointer classes, some might say too many, but that's a topic for a whole different discussion, one of which is QSharedPointer.

I witnessed (and was pleased to take part in) some interesting discussions on #qt-labs this afternoon, all stemming from a contribution to Qt3Support being rejected.

A long story short, the contribution - despite looking reasonably valid - was rejected because Qt3Support is effectively unmaintained, and as a result, any changes to it could have negative impacts on users of the support API.

I understand that argument, yet at the same time - I can't help but think it's a bit of a backwards approach to be taking. Typically, a contributor will wander along, find a bitrotting module/project that interests them, throw patches at the previous maintainer - and shortly after doing so, find themselves a de-facto (or indeed official) maintainer through their efforts.

This is a natural progression of things and should really be encouraged, it allows what would otherwise be dead code to live on. However, in Qt3Support's case, the central point was that they'd love someone else to take responsibility for it, but don't want to expend the effort themselves to triage, maintain, and otherwise support it right now.

To me, it's a false saving.

Time you save not maintaining it now (and encouraging potential contributors/future maintainers along the way) is spent being forced to put the code on life support maintenance if you decide you want that code, for whatever reason, later on.

Not to mention that those people who might be happily contributing you ideas or patches (to code old and new) are instead going to be spending their spare time doing something more rewarding than having their hard work rejected in the future.

Openness doesn't just happen overnight. It isn't just in the licensing. It requires real persistent effort and culture change. This is something I plan to keep revisiting over my next few posts.

{Note}: Before commenting, please note that this issue isn't *just* based around Qt3Support. That is one example of the problem, yes, but the patch was actually to QWorkspace which actually wasn't part of Qt3Support, and QtSql is in a similar boat - and there is nothing to port code using QtSql *to*.

Just a short note to point n8x0 owners to the unofficial adaptation thread, where Stskeeps has made a preview release which demonstrates the MeeGo handset UX running on n8x0.

As he notes, it is pretty unusably slow right now, but hopefully that is an improvable slow. I've been spending some time with him on this to try improve the libmeegotouch end and it is good to see that progress is happening on getting it actually working on the devices.

It's a little intriguing as to what the slowness actually is. Software rendering on my desktop at least is pretty snappy (even under heavy load). I don't own an n8x0, so I think I'm going to have to dig around on my n900 and see whether I can find anything of interest out.

Just a short post to note that the promised infrastructure for Qt's open governance project is now live - go read Thiago's blogpost announcing this for more information.

This is something that concerns me quite a lot, and I'm extremely happy to see it move forward.

I would like to urge anyone interested to subscribe to the mailing list and help take part in the discussions over the coming weeks.

Some of the more observant people may have already seen my mail to meego-dev proposing a program for developer engagement, or one of the forum threads about it within the relevant communities I'm targeting with it. (and for those of you who haven't, you have now!).

I made the unfortunate mistake of advertising this proposal just before heading off to Oslo, so I wasn't able to do it justice on the mailing list or write about it here, so, it's probably time to stop, pause, and reflect a bit.

In the days after writing that, I have been approached by a few people pointing out various other good work in a similar vein to this, such as the MeeGo application developer site being spearheaded by Ronan, all of which is great news - it's nice to know that I'm not alone in thinking that we need comprehensive developer help networks set up sooner, rather than later. So the tutorials side of my proposal can probably largely be shifted under the application developer site.

Where does that leave me? I still think that my proposal has value to add - primarily: a human touch. I think that the majority of we hackers are at heart a social bunch (of antisocial individuals, ironically). We don't like answering machines, or being fobbed off with boilerplate answers, and when we have problems, we want to talk to someone about it, and that's where developer engagement can really help go the last mile. We have technical solutions to this (blogs, and whatnot) - but at heart, it's a social issue, and we need to make sure we're fostering and encouraging the right attitude of collaboration and community to help carry the load.

I still don't have the answers to how this is going to fit together, despite a lot of soul searching over my brief time in Oslo, but I hope to schedule an IRC meeting sometime within the next week or two with the energetic bunch of volunteers that I have already picked up to discuss priorities, options, and where we go from here.

If you're reading this, you probably use Qt for some reason or other. And if you use Qt, it's only a matter of time before you run into one of the 'pillars' of Qt 4: the Interview Framework, also known as model/view. If you need a little background, read on, otherwise, feel free to skim the next few paragraphs.

The topic pretty much sums it up.

I got sick of applications reinventing portrait keyboards, and so dug around to find something that would work a bit more generically. I found that hildon-input-method had some example plugins, one of which provided a portrait-usable keyboard (pictured left). So, after the help of frals (and Stskeeps and yerga), we're on the road - now it's your turn to help us get a bit further.
It's still in a very early stage, and the stuff we're dealing with (hildon-input-method) is pretty scary ..not to mention that I'm not really the most experienced person in the world when it comes to raw Hildon/Gtk+, but I'm sure we can get there, with some help.

If you want to help out, come join us in the talk.maemo.org thread and wander over to Gitorious.