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