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.