WWDC, Qt, Carbon, 64-bit, and other buzzwords

Published Thursday June 21st, 2007
12 Comments on WWDC, Qt, Carbon, 64-bit, and other buzzwords
Posted in Qt

I had the privilege of attending Apple’s World Wide Developer Conference (WWDC) again this year. This is Apple’s annual developer get-together in San Francisco where you can find out about Apple’s future plans for Mac OS X, chat with fellow developers, and avail yourself of all the Apple engineers on-site. This was my fourth year there and I think I’ve gotten the hang of it. This year, however, I (and Trolltech) was in for a nasty surprise.

The previous year, Apple announced what its plans were for Mac OS X 10.5 (or Leopard). One of the new features was that Leopard was going to be 64-bit the entire way through. People keeping score at home should note that the C and C++ libraries were 64-bit in Tiger, but none of the GUI libraries like Carbon or Cocoa. Naturally, we knew that there were lots of people who use Qt to write scientific, visualization, and video applications so it seemed like a good idea to make sure that when Leopard was going to be released in “Spring 2007” Qt was there to run in 64-bit. We were in pretty fair shape, having already been on the new Carbon technologies introduced in 10.2, but there were still some things that had to be fixed up, and we had to modify the build system, but that’s doable. There were also many bugs in the 64-bit Carbon that we filed bugs against the ones we could get reproducible test cases for. At the end, Qt 4.3.0 was released with the ability to build on Leopard in 32-bit and 64-bit. If you felt plucky enough you could build it all “universal” and have a truly fat binary with versions for PPC, i386, PPC64, and x86_64. This would have been even more impressive, if there was a Leopard that was publicly available so people could take advantage of it.

So, here it was June 2007, we had released Qt 4.3.0, but Apple had delayed Leopard to October. Then, at WWDC, Apple announced that they would not be including HIView and Carbon windows, and other GUI parts of Carbon in 64-bit in their final version of Leopard. This basically contradicts what they said the previous year and makes a fair bit of the work that we did for 64-bit in Qt useless—leaving Qt with a hole for 64-bit support on Mac OS X.

Now, getting news like this hurts on several levels. First, there’s the personal level where there’s the work you’ve put in, re-writing classes, adding all the version branches to make things work (writing an #ifdef 64-bit, 10.4, and 10.3 is a interesting exercise), and getting the build system to work. Then there’s the fact that there’s lots of people who use your library to write amazing applications (I got to see some at WWDC and they were impressive). What can you do for them? Needless to say, it wasn’t the most pleasant information to hear.

The rest of the conference, between attending sessions and talking to Apple engineers, I encountered a lot of Qt developers (either in person or via email). This was really positive. I knew that there were quite a few developers out there using Qt on the Mac, but getting a chance to talk them in person is always great. The big question that most people asked was, “what is Trolltech going to do about 64-bit?” As a developer, I couldn’t really give a definitive answer other than, “I would be surprised if we don’t have some sort of 64-bit solution.” This seemed to ease the fear for these developers and they also seemed to indicate that they were willing to wait a bit for the solution to materialize. As a developer, I can appreciate that response.

Now that I’ve been back in Oslo, I’ve actually had a chance to talk to product management and it seems that we will indeed have that 64-bit solution. The official statement is here. It also includes some Q&A that should cover most concerns.

So, in the future you can expect to see a 64-bit version of Qt using Cocoa under the covers. That is, of course, assuming we still have something like HITheme available to draw our controls. Unfortunately, even now I don’t know what that answer will be (hopefully yes). When we know what APIs are actually available to us, we can start actually making some sort of schedule. Right now, it’s a bit unnerving. If we do get Carbon back in 64-bit, we are in much better shape of course 🙂

If you feel strongly about this, please don’t hesitate to get ahold of your local Apple contact (whether via WWDR or through the contact information in the link above). We already have, but to Apple, Trolltech is but a pebble in the water, but if all Qt/Mac developers let their voice be heard we are a much stronger force.

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Qt


Will Stokes says:

I can’t believe I didn’t notice this in the keynote. I’m glad the apps I develop today don’t require 64-bit support, but do have an interest in writing ones in the future that would. If Trolltech manages to make Qt use Cocoa behind the scenes, will it still be possible to use QStyle to render various UI elements like check boxes, push buttons, etc? What about writing delegates? I love delegates! They are one of the most awesome features in Qt4 (far more useful in my experience then all the StyleSheet support that has been the recent fad). Will we loose delegate support if using Qt to build 64 bit apps on OSX? This news is indeed a major pain. My guess is that Apple will bite the bullet and finish the 64-bit Carbon support eventually, especially since it was there, to some degree, in the builds before WWDC2007. I’m just hoping 64-bit Carbon support isn’t another Quartz 2D Extreme and will come in 10.6 or beyond.

Adam Higerd says:

Just to let you know, the link to the press release is malformed — you missed a colon, so Firefox translates it to http://www.http.com.

trenton says:

In theory you should have the same Qt experience on 64-bit that you would on 32-bit. That’s the “Qt promise.” Things like QStyle and delegates should work the same. 🙂

Giuseppe says:

I have a dream: Qt on Cocoa !
But this is another story 😉

trenton says:

Thanks for the note about the link, it’s updated now. It works now 🙂

Will Stokes says:

I’m not sure this is the right place to discuss this, but when Trolltech first constructed the Mac Qt port why did they choose to do so using Carbon instead of Cocoa, if indeed the latter is possible? It seems the writing has been on the wall for a while that Apple would like people to ditch Carbon and transition entirely to Cocoa, although things have never really been that clear, what with iTunes and the Finder being Carbon apps themselves.

trenton says:

It’s probably not the correct place, but I can give my spin on things. 🙂

I personally can’t speak to the decisions that were originally made for the Qt/Mac port (that’s a story for others), but I will say that it is much easier to wrap a C API, especially one that is similar to Windows or X11 than starting with Objective-C. Besides, it wasn’t like we choose the old compatibility APIs (except for using QuickDraw in Qt 3), we used the new APIs that were introduced for Carbon on OS X and APIs. Qt 4 used several technologies that were introduced only for OS X.

As for the “writing on the wall” argument, this is something that seems to have sprung up after WWDC to try and retcon the whole story. The message that I remember hearing was never, “we want to get rid of Carbon.” I doubt Microsoft would have even bothered to build their next version of Office if that was the real message. Rather, the message was, we won’t be duplicating APIs between Cocoa and Carbon and more APIs will be coming out as Objective-C (not Cocoa) only. You can check the Carbon-dev mailing list where this message comes several times in the two years or so. Of course, one can infer that this will /eventually/ kill the library. Besides there are APIs that would had to have been used in Carbon regardless since the equivalents don’t exist /yet/ for Cocoa (HITheme for example).

So, the idea was to try incorporate Cocoa into your applications. Even as a library, we did this too, QSystemTrayIcon was the first Cocoa class inside of Qt, several more followed for Qt 4.3. It’s this reversal on what they said last year where suddenly this whole message has broken down. Now it’s, consider incorporating a Cocoa window into your Carbon app in 32-bit and for 64-bit, hmm… well, it’s a simple re-write to use Cocoa. You want to re-write your application instead of adding features, right? 😉

I was always glad iTunes and Finder were Carbon, it showed that Apple actually made efforts to use the library and find bugs in it. Can the same be said about MFC?

Craig Ringer says:

This might be useful:


… from which it does look like much of the UI support in Carbon will be gone for 64-bit Mac OS X.

Sergey B. says:

Cocoa is ugly API
It’s very hard to write cover for Object C for C++ 🙁

It was great to run into you at WWDC. I think proof of your point was that when I saw you in the lab, 2-3 other Qt/Mac developers were there asking similar questions about 64-bit incorporation and using Qt with Cocoa windows. And I was just going to find an Apple person to ask!

George Yohng says:

If you ever get to redesign Qt GUI underlayer, please make sure it works in non-Qt applications, in, for instance, AudioUnit plugins. This is essential for our development (we are commercial customers of Trolltech) and when you said “You can probably expect Qt to use Cocoa in the future”, a little spark of hope lit that probably we won’t need to replace GUI parts in our software after all (that is in development and is supposed to be released by the latter part of the year).

trenton says:

Hi George,

It’s early to say anything for certain, but I would imagine that you would be able to interact with non-Qt views and windows (though it might be in different APIs). There are a lot of technologies that are available for Cocoa and it would be bad if you couldn’t use them with Qt. 🙂 Of course, you will be mixing the Objective-C and C++ yourself.

Commenting closed.

Get started today with Qt Download now