This post is from Tabula Crypticum:
As I’ve noted before, I have been interested in Qt development for some time and finally got to where I could allocate the hours to learning. I missed out on local Qt training a while back so I’m dependent on documentation along with patient people online.
The latter have been a huge help. I’ve encountered some weird and frustrating situations from which many friends have rescued me. The former, however, have been severely lacking. But let me share the pain with you progressively.
I decided to create an application for the Nokia N9. The app will make use of GPS and cellular services mainly, and shouldn’t be very complicated. I chose Qt Quick because I wanted to see how mature QML really is at this point. Plus I’m allergic to C++.
Installing the latest Qt SDK was no problem. It was a slow process, but everything just worked. I then began searching for sample code because starting projects that way has always been my best mode of learning outside of formal training. Note to others who do the same: always credit those who have selflessly shared code that gets you started. One day you’ll want others to do the same for you.
I elected to start with GPS since that was the crucial, and I wasn’t sure if there was even QML support for it. I was pleased to see many results come up for GPS +QML +sample, especially a MeeGo wiki entry by a friend. However, at first the code generated too many errors, most related to specifying invalid anchor properties. I passed that along, the code was updated, and I progressed from showstopping errors to a blank screen. Well, that was something! Another friend made a few more changes and success! I now had GPS data. What a feeling!
Then the weird stuff. I added another QML file and changed the id of the grid object on MainPage.qml, and after the next build my app was all black. There were no new errors or warnings so I was mystified. But no problem: surely unwinding the last code changes and reverting back to the last good state would restore the app to its previously successful condition… right?
Wrong.
Even after a new build the app stayed black. I exited Qt Creator and restarted the project twice; no improvement. No one online could provide an answer, either. Out of exasperation I killed the project and recreated it from scratch using the same code that had just failed. It now worked again. Go figure.
The next day I made some more changes, and each test build was successful. I really felt I was getting the hang of QML now! Until I renamed the id of a button on main.qml. Zap! Black Screen of Death again.
So at least now I had a culprit: mucking with element id values. But still no understanding of why. I was told in the #Qt irc channel on freenode.net that the project was not getting fully repackaged even after reverting the code. I would assume that the Clean function would resolve such issues… but in these two instances it did not. However, this second time exiting Qt Creator and reloading had the desired effect: the project compiled and ran properly again… mysteriously, even after I did the id rename a second time! In other words, the change that seemingly broke the build the first time sailed right through a second.
I now have a reputation on twitter as the guy who scares off wannabee QML coders.
But of course that’s not my goal. I really want to master this, and maybe ultimately help others as a Nokia Developer Champion. In the course of the past two days’ madness, however, I have discovered a few things:
- The Qt community is awesome. I cannot overstate that. Even as I flooded twitter and IRC with inane questions, rants and cries of despair, patient experts kept stepping forth. Nokia is truly blessed to have them involved.
- QML code examples are fairly easy to find and usually useful. I have been brute-force hacking my way through Qt Quick, and mostly successful at finding relevant code snips to plug into my project. And when they don’t work, again, the community does.
- Qt documentation is severely lacking. Don’t get me wrong: it’s easily available and there’s a LOT of ground covered– but it falls short in details. I ran into too many situations where the text would say “To do this you first need to do that” with no pointer whatsoever to how you did that. Come on… at least give us a link! And some examples that demonstrate entire solutions, not just pieces (note: according to the latest Qt Blog article, they are getting this now).
To be fair, documentation that comes up short is certainly not unique to Qt. The sort of omission I cited above has been a huge issue with Microsoft developer docs for decades. To the Qt team’s credit, they embedded bug reporting right into the dev environment. I dutifully reported my first bug and I’m sure it won’t be my last.
My suggestion to the Qt Project is to start floating docs past beginning users, especially those with a coding background in other platforms but new to Qt.
I learned in humbling fashion very early in my developer days how useful this can be. I had written a DOS QuickBasic utility that converted data from one format to another. There was a single screen of user inputs and I was very confident I had coded it strong enough to foil the worst of evil users. But to be sure, I sat a very disagreeable co-worker down at my PC and challenged him to find bugs.
Some time later, he smugly presented me with three pages worth.
It turns out I had neglected to test for invalid inputs in several cases. My trouble-making tester had tried every character combination he could imagine and broke my app more ways than I had thought possible. But he did me a huge favor: not only did that app turn out to be extremely robust after bug-fixing, but I learned a valuable lesson. That is, test your apps (and documentation, sample code, etc) on people who come at them with fresh eyes and even a high desire to find fault. Your product will ultimately emerge the better for it.
Now, back to QML coding… you’ve been warned!
Source Qt Experts
