Planet maemo: category "feed:a93f39245539231538463d349e184dd2"

Robin Burchell

Another day, another itch.

2010-08-27 13:10 UTC  by  Robin Burchell
0
0
(First, an apology in advance, this is a bit of a braindump, and as such, isn't very well structured.)
Click to read 1008 more words
Categories: coding
Robin Burchell

Strings and Qt

2010-08-08 19:07 UTC  by  Robin Burchell
0
0
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).
Categories: C++
Robin Burchell
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? :)
Categories: meego
Robin Burchell

Tracking QSharedPointer leaks

2010-07-27 15:31 UTC  by  Robin Burchell
0
0
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.
Click to read 938 more words
Categories: meego
Robin Burchell

Qt: Bootstrapping openness

2010-07-21 18:43 UTC  by  Robin Burchell
0
0
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*.
Categories: meego
Robin Burchell

Devices of the Undead

2010-07-12 22:30 UTC  by  Robin Burchell
0
0
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.
Categories: n8x0
Robin Burchell

Qt and Open Governance - it begins!

2010-07-02 17:02 UTC  by  Robin Burchell
0
0
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.
Categories: oss
Robin Burchell

MeeGo Developer Engagement

2010-06-23 23:02 UTC  by  Robin Burchell
0
0
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.
Categories: meego
Robin Burchell
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.
Click to read 1394 more words
Categories: meego
Robin Burchell

Maemo? Portrait keyboard? Yes, we can!

2010-06-06 19:13 UTC  by  Robin Burchell
0
0
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.
Categories: maemo
Robin Burchell

Good news comes in bundles

2010-06-06 17:23 UTC  by  Robin Burchell
0
0
Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
For those of you that hadn't heard already, I just wanted to share a piece of good news: Qt have officially announced plans to start moving to an open governance model.
Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.
This is by no means going to be a short, or an easy journey, but I have high hopes that it will be productive, fulfilling, and rewarding in the long term.
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I--
I took the one less traveled by,
And that has made all the difference.

-- Robert Frost

Down to business, it's important to realise that this is not going to happen overnight.

But: in the longer term, we should see infrastructure start to open up, as I wrote about previously. For example, I've already had some chatter with some people from Qt about the work I've done on open testing infrastructure on #qt-labs, as they have similar goals.

With open mailing lists, quality assurance, and other infrastructure, we will have the beginning blocks for a true meritocracy, a more level playing field for independent contributors to Qt.

With that, we will have the capability for anyone to scratch their itches easily, without being bogged down in process, while at the same time, maintaining the high quality and feature set Qt already has today, as a result of keeping the same talented, quality people around.

We're not there yet, and we won't be for a while, but the mould has been made, and now: it's time to get to work.
Categories: oss
Robin Burchell

Qt: open testing infrastructure

2010-06-02 23:47 UTC  by  Robin Burchell
0
0
I recently wrote a post about how Qt could become a more open project, but after writing it, I was left asking myself what more I could do to help further the process.

As a result, I'd like to introduce you to a project I lovingly title the Qt Community Integration System. Its aim: to automatically build, test, and publish community merge requests.

This is an important step in order to help streamline the process of community contribution and get feedback to individual developers quicker. Qt  internally use a similar system, but theirs is not (yet?) public.

How does it work? There are a number of components:

  • A community Qt repository (why not the 'official' one? read on - this is not a fork)
  • This repository is updated by an integration script, which pulls pristine Qt, applies designated merge requests over the top of it, and then pushes it to the master-proposed branch, if they all merge cleanly.

    These lists of merge requests are currently maintained by ..me.

    However, the intention is to give other trusted people, such as those in #qt-labs or who submit frequent merge requests, access to edit these lists and push to this community repository too, so it becomes possible to request integration of a change if you're experienced and trusted.
  • A BuildBot which pulls Qt from the master-proposed branch of this repository, and then proceeds to try to configure, compile, build, and run Qt's extensive test suite, with the help of a custom tool I have purpose-written for this task, unimaginatively called qtestrunner.

    The results of these tests are then published on a website, where they may be viewed by others.
  • This last bit of this puzzle isn't quite finished, but, assuming all of the above steps succeed with no regressions from the previous test run, the master-community branch is updated with the latest contents of the master-proposed branch, as a working snapshot of Qt+community patches.

(Of course, 'master' will eventually be 'all current Qt branches'. I just wanted to pick one to start with.)

So, after I've described all of the above utopia, what's the current status? Well, I've got a lot of the pieces in place, and now I'm fighting problems with Xvfb causing some of the Qt GUI tests to fail *sometimes*, (even though they don't when I run them manually). Once that is solved, I hope to start adding people's access to integration, and start test-integrating merge requests. :)

Hopefully, all this work will help to accelerate the time it takes to send merge requests back for review if they break something, and ease the burden on getting requests merged in (due to requiring a little less testing). Time will tell. But at least I'm doing my bit. Patches welcome. :)

(thanks to John Brooks for copy-editing my appalling English as usual)
Categories: oss