Posts tagged ‘radio button’

Programming Rant – Annoyed With Qt – Pixel Metric Failure

Here’s an odd one. Today was the first time that I can ever say I was truly annoyed by something in Qt.

Well, okay, maybe not exactly the first time. I mean there are still some niggling bugs that get on my nerves, like how resize events called between constructor and the first show can result in incorrect sizing thanks to the optimizations being done. (Fortunately once you resize after that initial cluster-FUBAR things work fine, so you can work around it by sending a single-shot timer event to force a resize to the same size and all is fixed.)

And I have to say that there are times even in Qt4 when I have to wonder if the Trolls got their own memo about cleaning up the architecture from Qt3 by doing everything the “right” way, like all drawn objects inherit from QWidget so that there are no longer any strange custom drawing widgets without proper QWidget architecture. I mean I get why for performance it was done that way in earlier versions, and I guess still is done on (rare) occasion, but it’d be nice if we could have a clean simple architecture.

(By the way, can anyone explain why QGraphicsViewItems don’t inherit from QObject?  Talk about missing the memo!)

And, well, that whole private class internal architecture thing, that gets annoying too sometimes. It would be awfully more convenient if everything were accessible when you inherit from something. Not to mention be nice if the sourcecode were a lot more straight forward and readable.  (But then I guess that’s where their licensing starts making them money.  If you need to fix something that low level, you either pay for a commercial license, or you’re forced to make your changes available to the world at large.)

But these are all things that I can overlook, because I love Qt. They generally can be worked with or worked around in a way that in the end really isn’t a big deal.

Today, however, I ran into one that’s really making me scratch my head. I’m working on a touchscreen application and wanted to do something that I thought would be simple: create a custom GUI style based on the Windows Vista style. Inheriting from QWindowsVistaStyle was easy. That part was no worry. As was reimplementing the pixelMetric method so that I could return larger values for things like checkbox and scroll bars sizing. The idea was to keep the Windows 7 look-and-feel, only to make things larger targets for finger pressing. (It’s amazing how many tablet-style devices exist and yet this notion isn’t taken a lot more seriously.)

Well, as I said, in theory it was as easy as you’d expect from Qt.

In practice however … epic fail.

I don’t know if it’s the Trolls to blame, or if it’s Microsoft. But whichever the case may be, it turns out that checkboxes aren’t sized according to their pixel metrics. Meh? Say what?! Yeah!

Go fig!

So you can increase the pixel metrics all you want, but it does you no good. The GUI style does not draw according to its own pixel metrics!

I don’t know how many of the GUI styles are affected. Nor how many other of the primitives ignore their corresponding pixel metrics.  I do know for certain that the Windows-based ones all do ignore the checkbox pixel metrics to one extent or another. At first the QWindowsVistaStyle and QWindowsXPStyle both altogether ignore PM_IndicatorWidth and PM_IndicatorHeight when drawing checkboxes, but if you go back far enough to the basic QWindowsStyle you’ll find that the box will draw larger, like it should, but the checkmark inside of the box does not. Eh?  It’s a truly “special” look.

I wonder what other GUI styles perform similar bloopers.

I don’t know… Call me crazy, but I really expected better from the Trolls. Even if it was something kernel-based and not their own code, per se, I can’t imagine why they wouldn’t have implemented a workaround of some kind.  It seems like an awful cop-out to me to just say, “Well that’s the way Windows does it.”  Not that the Trolls have said that, because to my knowledge they haven’t said anything on this bug, but I really don’t see how you could intentionally implement the pixel metric system in a way so that you can easily adjust the pixel metric values and then not have tested it and found this bug.

Presently my workaround is to also reimplement drawPrimitive so that I can create a pixmap buffer to draw the undersized checkbox to using the bugged sizing, and then scale it up to the correct size. It works. It looks like crap because checkboxes are tiny, so pixelate badly when enlarged. But it works.

In the longer run however, it’s not a good enough solution.  Obviously.  It’s a kludge of the worst kind. So what I’m going to have to do (assuming that the Trolls don’t fix this blunder) is to manually draw these controls myself. I really don’t look forward to that, because there are a lot of shading effects in Windows 7 to duplicate. I may end up cheating and inserting a few XPM images into the code to scale down from. Or possibly even sit down and work on some vector graphics…

But in any event, the point is, who the heck would have expected that one of the main points of styles is in fact moot? That the pixel metrics are ignored when drawing the style primitives? And for the first time, there is no odd architectural quick to just get used to, or easy workaround to solve the problem. It’s going to take some serious effort to overcome this issue. Talk about being a waste of my time! For the first time in years I am actually annoyed with Qt and unimpressed by the Trolls that this somehow hasn’t been already addressed.

And speaking of GUI styles, I also get why certain GUI styles are only available on their target platform. Well … kind of. I mean I get why using the underlying kernel code may be necessary to get the native look and feel … without performance penalties. What I don’t get however is why no one bothered to write kernel-independent workarounds for the non-native platforms. Wouldn’t it have made sense to do that so that you can use these styles on any platform, just with some performance penalties? The whole purpose of Qt is that it’s a highly flexible multiplatform GUI solution. Except … apparently … it isn’t completely.  You can’t have your Mac look and feel port to every other platform.  Nor your Windows 7.  Etc.

Nerf!