The release of Mac OS X 10.6 (Snow Leopard) snuck up on me while I have been working hard on a major new release of PerfectTablePlan plan. I didn’t really want to risk messing up my stable Mac development machine by installing it, so I asked testlab2.com (who have been doing some third party testing for me) to test my latest beta on it.
Bad news. All the combo boxes in my application (which work fine in Mac OS X 10.3, 10.4 and 10.5) have visual artefacts on Mac OS X 10.6. They work fine, but they don’t look right. I wondered if the artefact could be unique to some weird configuration on testlab2’s test machine, so I asked the fine folk on macsb mailing list to see if they could replicate it. 4 of them tried (thanks Cesar, Jon, Aaron and Pierre) and they all saw the visual artefacts. Damn.
I posted a question on the qt-interest forum. The single response (thanks Francesco) mentioned that this issue had been reported in the Qt development blog. I managed to find the blog post, applied the recommended single line code patch to Qt 4.4.2 and rebuilt everything. Cesar from macsb kindly re-tried the new binaries and reports that this improved things, but some artefacts are still visible the first time a combo box is shown. Perhaps the patch works better for Qt 4.5.
Note the artefacts at the top and bottom of the combo box drop-down list
It looks like I am going to have to release it like this, unless someone knows of a better patch. This is very annoying after the months of hard work I have put into the new release. Aesthetics are important for commercial software, especially on the Mac. This could cost me quite a few sales.
I am not on the very latest release of Qt, but apparently this issue would still occur even if I was. Qt/Nokia have announced that they don’t expect to support Mac OS X 10.6 until they release Qt 4.6, whenever that might be. What use is a cross-platform toolkit that doesn’t support the latest major OSs?
Developer releases of 10.6 have been available for a while – I believe the Qt team should have burnt the midnight oil to make sure they had a release that properly supported 10.6 as soon as it became generally available. I know that isn’t easy given the size of the Qt framework and Apple’s penchant for secretiveness. But that is the game they are in and that is what I expect. I think they have seriously dropped the ball here, and this is coming from a longtime Qt fan-boy. Perhaps they have spread themselves a bit too thin by moving to LGPL licensing.
I have written this post as a quick heads up to other Qt developers. Thanks to everyone that helped me get this far.
Successful Software 
We have the same problem with our Qt based applications that you see in OSX 10.6. I totally agree with your comment ‘what use is a cross-platform toolkit that doesn’t support the latest major OSs’. Trolltech’s official policy should be to ‘be on it’ whenever there’s a major OS release so that Qt works fine on the new os version at the release date or very soon afterwards if there are unexpected surprises. Instead they seem to be more focused on the mechanics of their internal corporate schedule as opposed to addressing the realities that application developers who use their framework need to deal with.
I’d go further and say that it should be working with the major OSes as they’re approaching release – as far ahead as possible, not just on release day. If you have software which you want to hand updates of to customers on the day they install the OS, it’s no good if your dev platform isn’t working until that day – you need time to make any necessary adjustments and get releases sorted out.
While I am fully aware that you are frustated, I think it’s a bit unfair to extrapolate the mentioned bug to “they have seriously dropped the ball here” or “they seem to be more focused on the mechanics of their internal corporate schedule”.
I am not saying that bugs should not be fixed, I merely want to make a point that Snow Leopard is officially supported only in 4.6, and the reason for that has been given (Apple breaks stuff, getting early developer releases does not always solve the problem). Yes it sucks, our resources are limited, things could be better, bla bla bla. But rest assured, it has nothing to do with the said over-the-top accusations.
>Snow Leopard is officially supported only in 4.6
Sorry. That just isn’t good enough. The latest version of Qt needs to support all the latest OSs when they become available to our customers (and preferably months before to give developers time to address issues that arise). Apple isn’t going to change their schedule to suit Qt, so ‘Mohammed must go to the mountain’. Qt seems to have managed this admirably with all the previous OS releases I can remember (Vista, 10.5 etc). What is different this time?
If Qt doesn’t have the resources for this then I suggest they reallocate some of the people working on whizzy new features. I would rather Qt supported current platforms properly than have new multimedia or animation classes.
Ariya, there are no ‘accusations’ being made here. Qt isn’t ready for Snow Leopard, so anyone who has customers on OS X is looking red-faced at the moment.
By not ensuring that Qt works with Snow Leopard on release day – and that developers have time to see that their software already works and to make new releases – Qt is not going to appeal to developers who are expected by their customers to provide quality software.
As an ex-KDE developer, I often look at the state of Qt, to gauge whether it is currently suitable as a platform in case I fancy using it for a new project. It’s problems like this that put me off using it. Of course for some developers their software running badly on their customers’ machines may not be such an issue but there are plenty of us who refuse to accept such lapses.
Let’s not get trapped in the childish game of blaming here. I hate to repeat myself, but what I stated before was that you may call Qt for Snow Leopard “not ready”, “not good enough”, “not appealing”, “buggy as hell”, “completely broken”, you name it, *but* it has nothing to do with “dropping any ball” or similar guesses.
An easier analogy would be like this. If I fail your exam, call me lazy, incompetent, idiot, whatsoever. But the moment you stamp me, “Yeah, for my class, you just don’t really care”, that is where I may feel insulted.
And Rik, by “accusation” here I mean of course the (IMHO) extrapolated, unfair guesses. The *why*, not the *what*.
Ariya, I really think you are missing the point of this conversation. You are hearing people speak here who have put substantial time and effort into building applications using Qt that need to run properly on OSX 10.6 now, not some time next year. It’s simply not acceptable for us to tell our customers that our applications won’t work properly on a new apple or Microsoft os release. If that was the way we approached our business we might not be in business next year.
People who work for Trolltech are telling us that Trolltech’s official policy is to not worry about fully supporting new Apple os releases until Trolltech gets around to releasing the next point release they do once a year (in this case 10.6). Which based on past Qt release cycles would happen sometime in spring 2010. And we’re saying that we don’t consider that official policy to be acceptable to us. For obvious reasons, our customers simply won’t accept that kind of response from us.
In my opinion Trolltech’s official policy should be to prepare for platform os releases like Apple osx releases or Microsoft windows releases and have a fully functioning version of Qt available for their developers as soon as physically possible after a major platform release date. That’s fully what i expected, and it blew me away when i was told that is not the official policy.
There are thousands of developers who depend on Qt working properly when a new operating system is released, not at some arbitrary point afterwards. There were no real surprises associated with the timing of the Apple 10.6 release, the approximate release time has been known for a long time, Apple provided builds of 10.6 over a long period of time to developers, and the final GM build was available for several weeks prior to the official 10.6 release to the public. I would expect Trolltech to be on it during the entire osx development cycle, so that when the final osx 10.6 release happened they would be ready with a point release of Qt 4.5 that fully functioned properly. Because again, thousands of developers with real world shipping applications based on Qt depend on Trolltech to be providing this level of support.
If Trolltech stated, ‘look, we’re on it, we’re committed to getting a fully working point update of Qt 4.5 running on osx as soon as physically possible, things are looking good, we want to do some more testing to be sure, here’s what we know is broken, we anticipate fixing everything on this timely release date (like within a month of the osx 10.6 release date) no one would be speaking their mind here. And in fact that is what i hope they are doing. But the official response we’re getting is not really this kind of answer, hence the anger on our part.
Ariya,
I am glad to hear you care. I care as well, I have been using Qt for about 9/10 years now and am a big fan of the product and the company that made it. But I also care that my software looks crappy on the current Mac OS.
On the ‘supporting Qt developers who ship on Mac OS X’ exam Trolltech/Qt is currently scoring is a big fat FAIL in my eyes.
I am looking at this from customer’s point view. I suggest you try looking at it from your customer’s point of view.
Good news at last. Cesar of http://www.design-nation.net has tested the latest PerfectTablePlan binaries on 10.6 and tells me that Qt 4.4.2 with both of Morten’s patches is not displaying any artifacts in combo boxes. Thanks Morten!!!
fortunately it’s an open source widely used library and someone had fix it, I can’t see an happy ending if it was closed source.
“fortunately it’s an open source widely used library and someone had fix it, I can’t see an happy ending if it was closed source.”
I think that if it was closed source the company would have made damn sure they supported Snow Leopard before it was released.
In this case Open Source made Trolltech lazy and has allowed them to shirk their responsibility.
And Ariya shouldn’t be allowed to speak on their behalf, he has done further damage to their reputation.
Well done Andy for taking a stand about this on such a visible blog.
There is no Trolltech, it’s Nokia.
John, I have no idea how I can express my comments better. I am not sure I miss the point of the conversation, that is not what I am commenting. Please read it again my previous comments, did I even challenge Andy’s and yours opinion on the Qt readiness for Snow Leopard? You can even write an essay on that matter, still I can’t form a fair comment there, because I am not competent in that field (mainly Linux guy).
What I challenge is his statement: “I think they have seriously dropped the ball here”. That is his opinion, which I fully respect. However, I am allowed to have my opinion, too. And here is mine: “No, we didn’t drop the ball”. Same with yours “they seem to be more focused on the mechanics of their internal corporate schedule”. I beg to differ, my opinion is “No, we are not blindly only focusing on our internal corporate schedule”.
And Andy, please don’t just bother to suggest me try looking at it from our customer’s point of view. Just reread my comments, I am explicitly allow you (and John, and others) to say anything bad about Qt. Write down a hundred big fat FAILs if you want, get angry, scream aloud if you need to, insult me if I am nearby. I would not feel annoyed nor upset. You are the customers, you have the right to do so, and I understand that. But the moment you state that we drop the ball, I would claim my right to have a different opinion (is it too much to ask to have a different opinion?): we don’t drop the ball, extrapolating the bug to the said over-the-top statement is unfair.
I hope I am better now at making myself clear.
Pingback: Spot the difference « Successful Software
Ariya, I think the term drop the ball is appropriate, as far as I understand the meaning. I believe its origin is in ball games, where literally dropping the ball would, for the dropper’s team mates, cause a loss of points – and therefore position in the game.
For example, if I were playing cricket and was on the bowling team, if my team mate dropped a catch – and therefore we missed the chance to take a wicket, he would have let down the team due to his failure.
Notice that this does not suggest that the person is, in general, incompetent or even prone to error – only that on this occasion, they have made an error which has had a negative effect on their team mates (or in our real world scenario, their customers).
I can’t comment on the reference to the ‘corporate schedule’ as I don’t know what the basis is, but I think ‘dropped the ball’ is a fair choice of term in this case.
Ariya,
The software needs to work on the latest version of Mac OS X — anything less is an embarrassment to those who use Qt in their products, and totally unacceptable to their customers.
It is, quite literally, “dropping the ball” — your users *need* any issues with Qt to be corrected well in advance of a new operating system release.
Pushing a fix out several months to a year later — and even attempting to justify that position — does not win you any support. You dropped the ball when you failed to fix outstanding issues with a major operating system release that was available to developers well in advance of its public release. You then proceeded to obliterate the ball by trying to justify your absolutely ridiculous position.
Rik and Kip, thanks for the explanation. Obviously we agree to disagree, in my book I would have let you down only if I fail to deliver something that I promise you beforehand. Of course, we might disagree (again) on what kind of promises I shall deliver to you. But then, that particular level of discussion is beyond my pay grade.
Ariya,
I don’t think anyone is accusing you or the Qt team of dishonesty or bad faith. But Qt users such as myself are under great commercial pressure to support the latest release of OSes and there is an implicit assumption Qt will enable us to do that. It always has before. Frankly Qt isn’t very useful to commercial developers if it doesn’t.
I think that whoever decided your release policy made a serious error of judgement. But it isn’t too late to repair most of the damage e.g. a 10.5.x release for Mac in the next week with Morten’s two bug fixes would be a good step in the right direction.
Andy, thanks for the clarification. Note that I never feel accused by your statement, neither of dishonesty nor bad faith. I would still have made the same comment (“the unfairness”) and stated my opinion, even I were an outsider.
It’s the classic diplomacy case. A believes B should implement X. B never denies that X is fantastic (best thing since slice bread!), but due to numerous technical/business reasons, B can only promise Y, where Y < X. Obviously A is not happy. Now, if A goes on to write a dissertation and distribute pamphlets (with a big fat FAIL of course) on how the lack of X destroys his multibillion enterprise, that does not encourage a fruitful discussion on how to move forwards and bring Y closer to X. Imagine if A is your customer.
It does not need to be Qt vs Snow Leopard. Often while working on QtWebKit, our team gets flamed with something along the line that QtWebKit is completely a piece of junk if it can't implement . Most of the asked feature are valid, sensible, important, and necessary for many applications. I would have asked the same if I were in their shoes. We seldom disagree that we should not implement them. But decisions have to be made (there are only 7 days a week), which means sadly we can’t promise everything. It just breaks my heart when then people start to draw an unfair, extrapolated claims based on the situation. Or, in a term popularized here, “it does not win any support” from my side.
This is likely the last time I would bother to stand in the line of fire. I have my share of fun, but instead of resulting in the said fruitful discussion (making X and Y gets closer together), people seems to be happy to empty their steaming ammo on me and lecture me (repeatedly, as if I am deaf) on things I never disagree. I am just a lowly code monkey, I can’t afford to buy the state-of-the-art combat suit, and I can only take so many bullets from both parties.
Good luck.
Ariya,
I have to agree completely with my fellow Qt customers here. Trolltech, or I suppose now it’s Nokia, has really dropped the ball here in stating that their policy is to only support Mac OS 10.6 in the Qt 4.6 release. Qt 4.5 is the latest shipping version of Qt and as such it must support the latest OS releases, i.e. it must support 10.6. It’s not acceptable for us to tell our customers that our apps won’t support 10.6 for an unspecified number of months in the future (i.e. until Qt 4.6 is released). As such, we as your customers don’t find it acceptable that you (by you I mean Nokia as a whole) won’t provide official 10.6 support in Qt until 4.6 is released – which doesn’t even have a release date and might not be until next year for all we know.
Your policy should be that the latest released version of Qt (4.5) will support the latest OS releases. Anything less is unacceptable to us, your customers.
The good thing here is that by and large Qt does support Snow Leopard just fine – even Qt 4.4.3 (which is what I’m using) supports Snow Leopard very well. The visual artifacts are really just cosmetic annoyances that don’t affect functionality. And best of all there is a fix available by Morten here:
http://labs.trolltech.com/blogs/2009/08/31/qt-46-on-mac-os-106/
Also, Morten said that he would backport this bug fix to Qt 4.5.3. So hopefully this is all much ado about nothing.
Our hope as customers is that Nokia would realize that support for the latest OS releases is a top priority for us. As such we hope that you guys would make some effort to test and verify that the current Qt release properly supports the latest OS releases and quickly release any bug fixes for any compatibility issues that might be found.
Ariya,
I have to agree completely with my fellow Qt customers here. Trolltech, or I suppose now it's Nok9a, has really dropped the ball here in stating that their policy is to only support Mac OS 10.6 in the Qt 4.6 release. Qt 4.5 is the latest shipping version of Qt and as such it must support the latest OS releases, i.e. it must support 10.6. It's not acceptable for us to tell our customers that our apps won't support 10.6 for an unspecified number of months in the future (i.e. until Qt 4.6 is released). As such, we as your customers don't find it acceptable that you (by you I mean Nokia as a whole) won't provide official 10.6 support in Qt until 4.6 is released – which doesn't even have a release date and might not be until next year for all we know.
You5 policy should be that the latest released version of Qt (4.5) will support the latest OS releases. Anything less is unacceptable to us, your customers.
The good thing here is that by and large Qt does support Snow Leopard just fine – even Qt 4.4.3 (which is what I'm using) supports Snow Leopard very well. The visual artifacts are really just cosmetic annoyances thqt don't affect functionality. And best of all there is a fix available by Morten here:
http://labs.trolltech.com/blogs/2009/08/31/qt-46-on-mac-os-106/
Also, Morten said that he would backport this bug fix to Qt 4.5.3. So hopefully this is all much ado about nothing.
Our hope as customers is that Nokia would realize that support for the latest OS releases is a top priority for us. As such we hope that you guys would make some effort to test and verify that the current Qt release properly supports the latest OS releases and quickly release any bug fixes for any compatibility issues that might be found.;