Porting Dialcentral: The Last "10%"

I had thought I was "almost done" with the rewrite of DialCentral from GTK to Qt.  I've even started investigating my Meego ports and started helping package / develop a new project.  Oh the joy of rewriting software and reimplementing old bugs and the creation of all new ones.

Maemo 4.1 was leading in being the least polished.  Somehow I kept missing the setIconSize method on QTabWidget to override the default tab size on that platform which was incredibly small.

I also had to fix some modality issues.  I had not set the parent window of my dialogs because rather than a new window appearing, the dialog's contents would be drawn on the parent window on top of everything else.  It took me a bit to discover the variant of setParent that I also needed to set the Qt::WindowsFlags which you can conveniently do both with a setParent overload.  The other side of this modality issue was with close buttons on Ubuntu on tap-out-of-window on Maemo 5, I forgot close buttons on some dialogs.

The last major user complaint is for those who haven't yet installed a Qt application on Maemo 4.1.  The Application Manager reports the size of a package as its own size plus all of its dependencies.  This makes sense for if a program has a separate data package or uses a rare but large library.  The downside is if you see 5 packages listed at 24 MB "each" then that is a bit discouraging for installing any of them.  Not much can be done about this one though.

I think most of the other Maemo 4.1 issues have been resolved or are "good enough".

Maemo 5 is now presenting the bigger challenge.  Take a look at the following screenshot.

If you can't tell "Tell Me" is my number of choice for testing DialCentral.

Problems:

• The box/line in the text box are an artifact of scrolling
• The "Cancel Call" button is marked as not-visible but the "Send SMS" and "Call" buttons are marked as visible.  Sure doesn't look that way in the UI.  Well, until you press on part of "Cancel Call", then the "Call" button is drawn on top.

The best I can figure is that it is glitches in Qt dealing with the compositing.  While the window is hidden and in the time that it is sliding in I am changing up the UI in response to changes in the model.  If you cause something in the UI to change, like going back and adding another contact or entering some text, some or all of the glitches go away.

I could just chalk this up as a Qt bug, file it, and move on.  Even if I can find a simpler reproduction case what is the chance that Maemo 5 users will see the fix?  Even if there is a chance that they do see it, how does that help them in the mean time?  I've been experimenting with update, activate, enableUpdate with and without delays aimed to arrive after the slide-in animation and have not gotten any results.  I might just have to queue up the UI changes for a timed delay after show to hope it is after the animation.  This will take a bit of rewriting this dialog for a problem that is only on one platform.  I'm not looking forward to this.

Primitive Debugging

At the end of a release at work our product has to be tested mixed in with other products.  In development we tend to be focused on our individual product and we try to keep things simple for reproducibility sake.  Our customers focus on a problem and need multiple products to be used in complex ways.  This helps give us some comfort that things won't break terribly in the customer's environment.

These are no the most fun issues to be had.  It is difficult if at all possible to reproduce these issues outside of the test lab.  The test lab also exists on an isolated network.  These combine to reproduce some interesting challenges when debugging.

By dumb luck I ended up being the one to usually go down to look at these problems.  This time around a different developer got wrangled in.  This is an experienced person who previously only dealt in app software.  His favorite tools like remote desktop and Visual Studio debugging (remote or even local) are thrown out the window.
 
Normally I end up using WinDBG but some quick looking leads us to believe it is an issue with the startup of a service we have.  Debuggers aren't much use in these situations because you can't start the service from inside it and you can't always attach in time.  So even though my coworker dreads WinDBG, he can't even use this tool.  That leaves us with print messages from a debug build of our service.  I am the one to generally maintain the service in question and I've been sure to put in debug messages in all the most useful spots.  I also showed my fellow developer a few tricks with debugging through DebugView.

This just gave me pause to reflect on how useful it is to use (in my case exclusively) these "primitive" tools.  In regular day-to-day debugging I can use the right tool (user space debugger, kernel space debugger, prints).  In addition I have the experience to deal with these more extreme debugging situations.  This is another great benefit for tools like VIM which you can use in a GUI, local command prompt, and through SSH.