Code Cloning an example

Some parts of code cloning are bad. In contrast to my other post this is supposed to be entertaining and something you can do before breakfast. Find the difference yourself and draw the conclusion. This code is from qmailstore.cpp from the qtopiamail library. This is not to pick on any developer at Trolltech but to highlight how code review and discussion could create a better Qtopia product.

d->checkComparitors(key); QString sql = "SELECT id FROM mailfolders"; if(!key.isEmpty()) sql += " WHERE " + d->buildWhereClause(key); if(!sortKey.isEmpty()) sql += " " + d->buildOrderClause(sortKey); QSqlQuery query = d->prepare(sql); if(query.lastError().type() != QSqlError::NoError) qLog(Messaging) << "MailFolder query failed"; if(!key.isEmpty()) d->bindWhereData(key,query); if(!d->execute(query)) qLog(Messaging) << "MailFolder query failed"; QMailIdList results; while(query.next()) results.append(QMailId(query.value(0).toULongLong())); return results;

d->checkComparitors(key); QString sql = "SELECT id FROM mailmessages"; if(!key.isEmpty()) sql += " WHERE " + d->buildWhereClause(key); if(!sortKey.isEmpty()) sql += " " + d->buildOrderClause(sortKey); QSqlQuery query = d->prepare(sql); if(query.lastError().type() != QSqlError::NoError) qLog(Messaging) << "MailFolder query failed"; if(!key.isEmpty()) d->bindWhereData(key,query); if(!d->execute(query)) qLog(Messaging) << "MailFolder query failed"; QMailIdList results; while(query.next()) results.append(QMailId(query.value(0).toULongLong())); return results;

What differences did you find? Right, the only difference is that the select is done on a different table and that the qLog was not updated. So this is coming from QMailStore::queryMessages and QMailStore::queryFolders. Reuse code, but not by cloning, use the right abstraction. Have a nice weekend.

The Myth about a working Qtopia

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 (tm)).


• ...

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...

My two cents on the Openmoko April Software Update

I have been involved in this project with the goal to create the April Software Update (ASU). Just by the name Update one can guess that the stuff shipped (factory image) on the image is not the April Software Update. The default factory image, for what I know, is the Gtk+ based stack as you know it.

So why did we start to create the ASU? We wanted to have a working phone on a short time frame and some of us believed that the current stack, specially the gsmd, is not close to be working properly. The most promising alternative was the Qtopia stack. So we started marching into this direction by porting it to Qt/X11. When I say Qtopia we mean the prediction of the keyboard, the dialer, the sms program, the various other phone apps. So I'm using my ASU powered gta02 as my primary phone and fix the issues I encounter where ever they are. There are quite some things left but it is looking promising. So guys, be happy that you will getting working hardware and working telephony software. If you are bored with stuff just working (tm) the Gtk+ based stack is awaiting your patches.

So how does it fit into the platform strategy? This is not changing anything in regard to GNOME Mobile and Embedded (GMAE). Our SDK will support you in creating GMAE based applications. Our framework initiative will make sure that you can access the functionality you need. Due technical issues (before it would get political) our SDK will not contain Qtopia headers, libraries. The Gtk+ stack remains supported, patches are welcome.


So happy hacking and enjoy a working phone and more on how great EFL later.

z.

DVB-H with a Nokia SU-33W

Dear Free Software loving Nokia,

first of all congratulation for acquiring Trolltech. You have gained a great team of highly motivated and passionate people. Many from us in the Free Software and OpenSource community care a lot for Trolltech. Recently I have acquired something as well, the money was not enough for all of Nokia so I started with getting a Nokia SU-33W. This is a bluetooth based DVB-H (Digital Video Broadcast for Handhelds) receiver.

While I know a lot about mpeg transport stream, multiprotocol encapsulation (MPE), FLUTE, OMA BCAST, RTP, h264 and have seen quite some DVB-H/DVB-T chips, I'm unable to make any use of my acquisition because the bluetooth protocol (directly on top of L2CAP) used is not documented.


Please give me access to the protocol specification to allow me writing a Free Software driver for your bluetooth device as I would like to watch TV with a HTML5 Video Element inside a QtWebKit KPart.