Mac OS X Snow Leopard was released on friday, Qt 4.6 is on its way – The 4.6 branch has been created at gitorious.org. What’s new?
First of all we’re rolling the OS Support window: support for 10.3 Panther has been removed and support for 10.6 Snow Leopard has been added. This means that Qt 4.6 on Mac OS X will support three versions of the operating system(10.4 – 10.6), four different architectures (ppc/ppc64/i386/x86_64) and two toolkits (Carbon/Cocoa). About half of the OS/arch/toolkit combinations are valid, see developing-on-mac.html for all the details.
Removing 10.3 (Panther) support
With Qt 4.5 we removed support for gcc 3.3, making Qt deploy-only on Panther. We’re now removing run-time support as well. This allows us to remove a bit of code (Qt 4.5 contains around 60 10.3-spesific code paths), and also frees up developer, support and QA resources to focus on the newer platforms. In addition, our 10.3 testing machine here at the Oslo office is showing its age and is ready for retirement.
Adding 10.6 (Snow Leopard) support
From a developer viewpoint the biggest change in this release is more 64-bitness. Most(all?) of the bundled apps are 64-bit, and the gcc compiler produces x86_64 binaries by default. Qt follows suit and is also 64-bit by default when building for Cocoa (Select this with the -cocoa flag at the configure line or use the -arch x86_64 flag). Apple has also updated to gcc 4.2, which renders the macx-g++42 mkspec obsolete. Compiling for ppc64 is no longer supported by the gcc tool chain. Other than that developing on 10.6 is much the same, and we can all enjoy the new Exchange support in Mail.
Planning Ahead
Maintaining two ports is not sustainable in the long run, so the Carbon port is eventually going to be dropped. It is however our only means of supporting Tiger and legacy Qt3-based code, which suggests that we should keep it around for at least little bit longer. PPC support is not a big issue, the build infrastructure for it is there and the PPC-only bugs are few and far between. That being said, at some point in the future we’ll probably end up supporting x86_64/Cocoa only. Unless something new we can port to appears in the mean time 
So, here’s the conclusion with a tentative plan:
Possibly related posts:
42 comments
I fully support your plan to drop old platforms and to focus on 64-bit Cocoa. Qt 4.5.x already looks very promising but currently isn’t mature enough for a full-blown 64-bit Cocoa project. That being said, I really appreciate all the support from the Qt folks in moving to 64-bit on Mac OS X, you rock!
Nice to hear some news about Qt/Mac. I had to fix some issues when porting from Qt/Carbon to Qt/Cocoa but it was a relatively smooth process. I’m sure the remaining issues that I can’t workaround will be solved, too. It’s great that you can finally access all those Cocoa only APIs.
Btw, did Trenton leave your Team?
How much of these new Mac-ness will be supported in Creator?
Hit the submit too soon.
I am specifically interested in the out-of-box fat binary support. I need to support statically linked Intel/PPC UB build on OS X 10.4 on. The current Creator doesn’t seem to support it well.
Does this mean that Qt 4.5 apps will NOT run properly on Snow Leopard?
I don’t really mind Carbon vs Cocoa, or old OS versions. But what is important for me, for at least 2 or 3 years, is support for 32 bit. Because my application works with 32 bit dylib that won’t change soon. Your post was not clear about one point:
will “next +1 release ” support 32 bit Cocoa?
Hello.
Can you tells us if 4.5.2 (carbon for me) has any issues with the just shipping 10.6?
thank you
Qt 4.5 is not tested on Snow Leopard. It may or may not run. We make no promises.
Supporting an OS before it’s released is quite tricky, especially when that OS is the one from Apple, who loves to change stuff behind our back.
As a paying Qt application developer I find the above statement that Qt 4.5 has not been tested on OSX 10.6 by Trolltech to be truly frightening. Are you telling me that no one at Trolltech was working with pre release copies of OSX 10.6 and Qt? And at this point it is officially released, and the release build included on the snow leopard dvd has been available to developers for testing for weeks.
Fortunately, Qt 4.4 and 4.5 do seem to work with osx 10.6. Since my Qt based application customers who are switching to 10.6 expect our application to work NOW, not later. The only problem we have seen so far is the rather obnoxious visual bit noise that displays at the top and bottom of QComboBox popup menus. SO please FIX that quickly in Qt 4.5.3 (as opposed to waiting until Qt 4.6).
Support for legacy machines is a huge issue for application developers. Probably at least half of our mac customers are still on PPC machines. So i appreciate continuing to support legacy OS systems and cpus for 4.6 and 4.7 as discussed above. The timing you suggest for the changeover for no carbon support seems reasonable.
I agree with john dalton 100%.
My jaw just about dropped when I read Thiago’s comment and could not find the words to respond, thankfully John did eloquently.
Thiago, that just won’t do. With an LPGL version, Nokia/Trolltech needs to step up if they want commercial licenses to be sold, because the downward quality of email support over the past 8 months is certainly nothing to shell out a lot of $$$$ on.
Did you not see arrogrant statement that Adobe Rep John Nack posted last week?
Did you not see the PR mess Adobe into because of it, resulting in an apology letter today?
We are not asking for 4.5 to be working 100% on day one of 10.6, but as john said, the GM has been available to you for weeks,
What we should be getting is at least a report by Qt saying that based on our testing
X, Y and Z are working but comboboxes have a visual bug, and etc..
At least give us more then “Who knows? It may or may not”
Please forward this thread to people up the chain, a statement must be made soon (and should have been released last Friday when 10.6 came out.)
“It may or may not” is insulting to your users.
Does this “next + 1″ schedule for dropping Qt3Support apply to all platforms? The Qt3Support module is already not supported in the Cocoa port of Qt/Mac 4.5, but I’d like to know when the module will go away for other platforms–especially Windows. We have a substantial amount of code that still uses legacy objects.
@sergevk: Facing the same issue, we started to slowly replace the Qt3Support code in our application. To be able to move to 64-bit on Mac OS X and not having to replace all Qt3Support classes at the same time, I patched Qt 4.5 to compile Qt3Support again (with some GUI classes not doing much). Have a look at:
http://qt.gitorious.org/~mevis-mac64/qt/mevis-mac64-clone/commit/3a449bb8a2caf89730728058168a7eb597b3a238
if that would help you as well.
Thanks for the replies! Always good to see that people care about Qt on OS X. I’ll try to clear up any misunderstandings.
First things first: I (and other devs) have been testing Qt 4.5 on 10.6, so this should work. What Thiago was referring to was that it hasn’t gone through the whole QA process, so there is no official support for it. (This is a lot more work than me installing a developer seed and compiling Qt, think setting up build/test machines, making sure support is ready to handle support requests, etc.)
dalton: We’ve seen the QCombobox issue and fixed/worked around it in 4.6. (I seems like some CGImages that were previously properly initialized no longer are). If the issue is still there in the final 10.6 release I’ll backport the bugfix to 4.5.3. I the mean time, here’s a patch:
— a/src/gui/image/qpixmap_mac.cpp
+++ b/src/gui/image/qpixmap_mac.cpp
@@ -1178,6 +1178,7 @@ QPixmap QPixmap::fromMacCGImageRef(CGImageRef image)
const size_t w = CGImageGetWidth(image),
h = CGImageGetHeight(image);
QPixmap ret(w, h);
+ ret.fill(Qt::transparent);
CGRect rect = CGRectMake(0, 0, w, h);
sergevk: There are no plans to drop Qt3Support on the other platforms.
Philippe: No plans to drop 32-bit Cocoa either.
stephenju: I’m not an expert on Qt Creator, but I think the command line is the way to go for building universal binaries. (That’s what I do at least, work on a “native” version in Creator and then recompile from the command line before deploying.)
I hope that answers everyone
What’s the *approximate* time frame for Qt 4.5.3? I’m under the impression Qt 4.6 won’t be coming out until the end of the year. It would be great to have a supported version of Qt (4.5.3) on 10.6. It would also be nice to see a few bugs I’ve noticed a fixed from 4.5.2 in a released version of Qt sooner.
As a note, the installer for the SDK doesn’t currently work in Snow Leopard. It gets to “validating packages” hangs there for awhile and then fails without a useful message or diagnostic. I’ve downloaded it a few times now and I’m not the only one this is happening to. This is maybe unfortunate timing as this is my first download of QT (I want to eval it for application development) but just so you know – your downloads don’t install on Snow Leopard!
Thank you Morton.
This is makes me feel much better, If I seemed a little over the top it is only because I love Qt (and Qt on OSX) so much, I have been there since the beginning (OSX) and have watched and been amazed at its progress through the hard work of the Qt team.
So it looks like 4.5.3 should be the one, and the patch above for an early jump.
@john & Qt user: Like Morten said, our developers did try it before. They installed it, played around, checked if Qt compiled, ran a few apps, but it didn’t go through the full QA process. We don’t change our platform support policy during a patch-release. That means what Qt 4.5.0 could work on in March, when we released, is what Qt 4.5.3 will support when it comes out (which should be coming in about a month or so).
*Full* Snow Leopard support will come with Qt 4.6. Until then, the official position is that Qt 4.5 is *not* supported on Snow Leopard. That means we don’t guarantee things will work as expected — we will probably publish a list of what we know to work and what we know not to. Currently, we have no (official) clue. I’m sorry, but resources are limited. And we know Apple breaks stuff.
The fact that the installer isn’t working is a very good indication. It works in 10.4 and 10.5, and it’s built with standard Mac installer programs.
That said, once we know what the problems are, we may be able to fix them, depending on how complex the issue is. That is not to say we will support it, though.
@Nils: Yes, yes I did leave Nokia. I am now beginning the exciting life as a research scientist. It was an amicable “break-up” though and there still is a competant crew working on the Mac, so don’t panic. On the other hand here, what I say down here will be pure me and not filtered by Nokia, nor are they responsible to take my advice.
@QtUser: If you feel strongly about “forwarding this along,” posting on the blog is not the right place to do it. Put it through an official channel, where there a better chance the right eyes will see it.
@Warren. Yes, this is a bug in Snow Leopard. I reported this bug back in June, but it apparently wasn’t fixed before the final release. I believe if you don’t install documentation in the BIG package, but separately it will go through. You can file a bug report too, Apple tends to like multiple bug reports.
As a rule of thumb, since Qt 4.2.3, there’s enough logic in Qt to handle a large number of future release probably up to 10.9 if it would ever happen. Assuming things don’t change much in the underlying frameworks we use, most applications will run “OK” for some definition of “OK” on future Mac OS X releases. _Building_ may lead to different issues though. I put special changes into 4.5.0 before it’s release to ensure that it would build on Snow Leopard. Does that mean everything would work well, probably not. Still, though, it’s something you, the application developer, needs to be a bit pro-active about. I know in the past the team has been pretty responsive to bug reports about bugs in the new releases and have tried to put as many of these fixes as possible into a patch release. It’s not easy to make things work well on every occasion, check out: http://snowleopard.wikidot.com/ for other issues that programs are having (including Apple).
@QtUser: Regarding your comment about the support quality, can you please contact either support directly about this or your contact in Qt Development Framework sales with some more information on this? This will be passed on to the relevant people and looked into further on your behalf.
One of my applications uses Q3Dns module. Current version of Qt doesn’t have replacement for it (i mean full replacement which allows get all kind of dns records). Do you plan to add similar class to next qt versions before removing q3support?
Hi Sergey
There is no plan to support DNS queries directly again.
Bad. It seems i need write own replacement for q3dns
I tried the patch on Qt 4.4.2 and it improved things, but artefacts still remain. See:
http://successfulsoftware.net/2009/09/03/qt-visual-artefacts-on-mac-os-x-10-6/
I have spent months working on my new release and I am really disappointed that it is going to look crap on the latest Mac OS X release. This is going to cost me sales. What use is a cross platform toolkit that doesn’t support the latest OS’s? If you can come up with a patch that fully fixes the problem on Qt 4.4.2 I would really appreciate it.
Sergey: One possibility is of course to extract the Q3Dns code from Qt3Support and embed it into your application.
I am using Qt 4.5.2 on Mac OS X and updated my Mac to Snow Leopard the other day. It took me by surprise than _none_ of my software projects can be built anymore…
In file included from /Library/Frameworks/QtGui.framework/Headers/qmatrix.h:46,
from /Library/Frameworks/QtGui.framework/Headers/qbrush.h:49,
from /Library/Frameworks/QtGui.framework/Headers/qpalette.h:47,
from /Library/Frameworks/QtGui.framework/Headers/qwidget.h:48,
from /Library/Frameworks/QtGui.framework/Headers/qmainwindow.h:45,
from /Library/Frameworks/QtGui.framework/Headers/QMainWindow:1,
from mainwindow.h:23,
from main.cpp:23:
/Library/Frameworks/QtGui.framework/Headers/qregion.h: In member function ‘OpaqueRgnHandle* QRegion::handle(bool) const’:
/Library/Frameworks/QtGui.framework/Headers/qregion.h:158: error: ‘toQDRgn’ was not declared in this scope
make: *** [main.o] Error 1
Since this affects all my projects, it’s well possible that I did something wrong, which just happened to work in the past…
Marc, marc@msys.ch
Someone had same kind of problems…
http://www.qtcentre.org/forum/f-installation-and-deployment-5/t-snow-leopard-broke-my-qt-23679.html#post114892
@Marc: This is a confusing error, but as Morten points out, the compiler on Snow Leopard generates 64-bit code by default. Since your Qt is built 32-bit, it falls over. You need to force the compiler to generate 32-bit code by doing CONFIG+= x86 in your qmake file.
I added stuff into Qt 4.5 to give a better error message, but this didn’t make it into 4.5.2, it should be in 4.5.3.
@trenton Many, many thanks. Adding that solved my problem and projects compile again.
Andy: this patch should take care of the combobox issue:
diff –git a/src/gui/styles/qmacstyle_mac.mm b/src/gui/styles/qmacstyle_mac.mm
index 194c244..4cd8332 100644
— a/src/gui/styles/qmacstyle_mac.mm
+++ b/src/gui/styles/qmacstyle_mac.mm
@@ -2147,6 +2147,7 @@ void QMacStyle::polish(QWidget* w)
w->setWindowOpacity(QSysInfo::MacintoshVersion >= QSysInfo::MV_10_5 ? 0.985 : 0.94);
if (!w->testAttribute(Qt::WA_SetPalette)) {
QPixmap px(64, 64);
+ px.fill(Qt::white);
HIThemeMenuDrawInfo mtinfo;
mtinfo.version = qt_mac_hitheme_version;
mtinfo.menuType = kThemeMenuTypePopUp;
And what type of bug could this be? The answer is a classic case of missing data initialization when a call to malloc no longer returns zeroed-out bytes.
Once Carbon support is dropped, does that mean that static linking on Mac will be dropped too?
I noticed that in the configure options it says:
-cocoa …………. Build the Cocoa version of Qt. Note that -no-framework
and -static is not supported with -cocoa. Specifying
this option creates Qt binaries that requires Mac OS X
10.5 or higher.
Or will there still be an option to use cocoa but with a standalone app?
Morten,
Thanks. Is that in addition to or instead of the patch further up? I haven’t actually got 10.6 here, so I am having to rely on the generosity of strangers to test the results – and this makes for a slow build-test cycle!
The two patches together appear to fix the problem in Qt 4.4.2. Thanks!
To clarify: the second patch fixes the QComboBox issue, while the first patch (“fromMacCGImageRef”) addresses a similar issue in QWizard.
Brett: As far as I remember there were some Objective-C-technical reasons for why static linking won’t work. I plan to take a second look at those, but we might be able to support it. If not (and in the mean time), I recommend taking a look at macdeployqt (http://doc.trolltech.com/4.5/deployment-mac.html#macdeploy) and distributing your application as an app bundle with Qt as private embedded frameworks,
Hmm, looking forward to qt 4.6 I have done quite a bit of testing to day, and Im not able to build my projects. I get a lot and I mean a LOT of framework related errors, as well as the #warning “Support for this version of Mac OS X is still preliminary”. Even if I make a simple skeleton UI project and don’t alter anything, it just wont build. This is the precompiled version of the QT SDK latest 4.5 build.
@Brett: Qt ships with a tool called “macdeployqt” that will take an .app bundle and embed the appropriate Qt frameworks and plugins into the bundle, strip all of the binaries, create a config file to handle pathing, and optionally generate a .dmg file for distribution. It works with Qt/Cocoa just fine, and the net result is what appears (to the end user) to be a single file that can be drag/drop installed.
Rahmi: Well you know how build issues go, one root cause error can trigger lots of output. Did you try the “CONFIG+= x86″ fix as suggested above?
Nice that there are patches, but what am I supposed to do with them?
It all looks like unix to me – or something else I’m not familiar with. Can I do something with them on windows? If so what? Can you provide a link to some sort of guide.
Bob: The patches are for Mac OS X, since the bugs in question only affect the Mac.
Silly me, I was thinking all “cross-platform”. Okay, how do I apply them on the Mac after I’ve got my program working in windows. Or do all Mac programmers know how to do this – it being such a techie OS and all?
Morten, in fact i did not see that one, thanks for pointing it out for me. And off-course that would solve my problem hehe. Personally it’s not critical for me, it’s not commercially used code or anything anyway. I Just like to experiment with programming technologies, and I personally think that Qt extends C++ in a way that makes it more comparable to java or C# for that matter, since you get a proper framework on top of it, and it’s all good because it’s portable, while .NET is a Microsoft solution (don’t like mono (imho)) and Objective-C is for Apple as apples are made for worms. So it makes it very simple for me with QT and then I can even build my solution on multiple computer architectures in C++
. Java is cool but more on the server side, since GUI in java kinda sucks somewhat (imho). And ruby is nice for all the smaller things in life (imho) and a language I have come to love as well. There I said it!
I can confirm the above fix solves the install on Snow Leopard problem – where is hangs/fails when doing “Validating Packages” early in the install. To solve, first time you run installer uncheck the Qt Docs option under Customize – then re-run and install just the docs.
Annoying but it works…
Rick
@Richard, unchecking onyl the Qt Docs is not enough. You also need to uncheck samples.
Comments on this entry are closed.