One comment to my previous post was why Openmoko isn’t using the plain Qtopia as it is just working. I wonder why and how some people and groups can deny reality in such a way. I met and read a lot of people thinking the same about Qtopia and I wonder what is wrong? I have to fix general bugs day-in and day-out, every time I open a sourcefile I go WTF and I could probably talk a whole week about Qtopia bugs, bad engineering practises employed and group thinking. It is not the single bug that makes Qtopia unusable, it is the amount of them, it is the severity and the fact that most of these bugs are conceptually and are repeated all over the sourcetree.

This goes from explaining that C++ needs destructors to actually free memory (no kidding, libqtopiapim didn’t free its private data), that you have to normally use delete when you created an instance with new (no kidding, addressbook.cpp is a good example of code cloning with variations and leaks). Just by these class of bugs I know that the Qtopia developers don’t use valgrind to find unitialized data and leaks. Just run your automated tests under valgrind and check the leak status. I assume they might fail as the execution is slower and your assumption on timing is breaking like on a real device but that would be good to fix anyway.

But why do I think Qtopia is not just working? The AT Command set for GSM is specified in chapter 07.07 of the GSM spec. The AT Commands and the response (parameters and possible values) are specified there. By default GSM is using a 7-bit alphabet, some responses specify a different coding scheme and some responses like SMS have a different format (PDU) which is specifying encoding inside the binary data. You probably can guess where I want to go. So sticking the 7-bit result into QString::fromLatin1 is going to work for English but not for other languages (e.g. Spanish and German). At least SMS, addressbook, and CUSD (e.g. asking your provider for the balance of your prepaid SIM card) will not work correctly if you use your native not english language. This means I will have to go through libqtopiaphonemodem, look at the parsing routines for AT command responses, open the manual, check which parameters they omit from parsing, which encoding to use and fix that.. By any definition this is not Code Less, Create More, this is not adding value for any user of Qtopia and being asked to buy Professional Services from PSO to get a working libqtopiaphonemodem is not making it any better. Not many “customers” will like that. Qtopia 2.0 should have gotten this right, 2.1 should have gottent this right, 4.0, 4.1, 4.2, 4.3 all should have gotten this right, and according to the support it is unlikely that Qtopia 4.4 will have this right. This means Qtopia Phone is not working for the majority of people.

So what went wrong? A lot probably ranging from people to bad API decisions (okay API is done by people as well). The implementer didn’t carefully read the GSM 07.07 spec and missed handling of encoding. Well, this is natural, humans make errors, he probably did not know GSM before starting the implementation, so this was a good prototype (throw one away). Nobody reviewed the code, I think code review is really missing on the Qtopia code (I have many funny mistakes that should be easily spottable if someone would review…). Nobody is using Qtopia Phone with their native tongue, using it at all(?), e.g. if Qtopia would be developed in Norway or Germany, I’m pretty sure this class of encoding issues wouldn’t exist. You have to eat your own dog food, you really have to eat your own dog foot. You can not develop phone software from 8-5 and go home and use your blackberry. The testing team failed as well. They should have had test cases that make you send and receive SMS with Farsi, Spanish, German, Japanese, simplified chinese…, make you store these names on your SIM card, make the phone simulator emit non english text. And the API is to blame as well. QAtUtils should not have parsing methods that return a QString. Once you have a unicode string you forget to convert. GSM is 7-bit or 8-bit, stick these things into a QByteArray. Everytime you need to convert this into a QString to show the value to the user you should be forced by the internal QAtUtls API to consider which QTextCodec* to use for that.

So how is this issue no fixed (frequently got wrong by some people…)

• Having a QTextCodec for GSM but not using it.
• Having non english speakers in your organisation. Just having them doesn’t
  fix it. Having a developer capable of tamil and making him work on networking
  stuff doesn’t fix text handling and rendering of tamil. No kidding.
• Denying the issue exists (it works here ™).
• …

Not all hope is lost with Qtopia. Someone needs to stop adding new buzzwords to Qtopia and fix what is there. Increase the quality, make customers happy. I know that I don’t make myself any friends in brisbane with this, but someone needs to stay the truth. time for pizza now…