I don't mind paying for software. If it was a one-time payment for a royalty-free library, we'd pay a few thousand dollars, no problem. But this is a cost per device thereafter (in addition to the substantial up-front cost), which in embedded could mean crazy money. So we just hacked up GTK to meet our needs, for $0 per unit cost.
Until you have to maintain it, or find developers for it. From a business perspective there are a ton of reasons why just using Qt would be a good option.
If you're going to build a million of something, and you have a team of 50 programmers, you're already going to use a standard/well supported library. A licensing fee for each unit might be bad, but being able to hire another 10/20/100 people who are all familiar with that framwork already is a net benefit, even with the license cost. It's cheaper to just use Qt, all things considered.
GTK is both "standard" and "well supported". Besides, this is embedded, it's not something you'll be rolling out features to every week, nor would you have to deal with more than 2-3 hardware platforms (usually just 1 and minor revisions thereof) so the need for "support" is way overrated.
Unless you try to build it using the native rendering system on Mac OS. GTK only looks decent or native when used on Linux, and with a GTK-based windowing system.
If GTK looked respectable by default, and easily compiled for Mac OS (without X11) and Windows, then I'd have much more respect for it.
Yes, Qt is a good option in many cases, but that doesn't mean everyone not using it has made the wrong choice, all things considered. The parent posters company might be in a completely different situation or scale.
