Last time I wrote here I was still a member of the QA team and I was announcing the launch of the qt-stable branch. Well, after two very successful years on the QA department I decided to change directions and I joined the platform team working on the Mac platform.
So, one of my first tasks required me to investigate a bug in full screen mode which only affected Cocoa applications. This led me to dig into the code and find some things that needed to be improved. While looking at that, I remembered that when developing the Cocoa port we reused as much code as it was possible from the original carbon port. This saved us a lot of time, however as time passed both ports started diverging and now the code has grown a little bit “confusing”. So, I started looking at the way of separating both ports completely and create completely different code paths for both of them. The more I looked at it, the more I realized that the task was not a small one and it would take quite a lot of work. Then I asked myself, why do we need to keep the Carbon port? After all, Carbon is the past in OS X and it has been completely replaced by the Cocoa framework. I talked to my manager, who told me this had been an ongoing discussion for a while, and the main reason for the Carbon port to exist is to support customers deploying applications in OS X 10.4 aka “Tiger”. Cocoa is available from OS X 10.5 (aka “Leopard”), before that the only available framework is Carbon. Doing some research on the Internet we found out that OS X 10.4 hasn’t been updated for about two years, and it seems very unlikely that Apple will release a new update after the last released version 10.4.11 (2 years ago).
Since we are aware that for some people Tiger support might be very important, we are reaching to you to find out the reasons why support for Tiger and/or Carbon are important to you. Could you please let us know the reasons this port and Tiger support are vital to you?
In case you are wondering, no decision has been taken yet so this is the time when you can influence the future.
Possibly related posts:
30 comments
I’m very glad the see the OSX team growing (as long as nobody left), your move is much appreciated.
We’ve moved beyond Tiger with our applications and require Leopard at least, all Mac-specific code is now Cocoa-based to get 64-bit support.
Right now, Carbon support is the only way to get proper translations working. On Carbon, you can create XX.lproj folders in the application bundle, and the system menus (e.g., “Quit Designer” in Designer.app) will be translated into the correct language.
This is not possible in Cocoa: Bug#4463.
If you’re part of QA and now Mac, can you address this bug?
http://bugreports.qt.nokia.com/browse/QTBUG-4463
Right now, I can’t use the Cocoa interface because our application is only partially translated!
We have customers that are still on Tiger and don’t feel the urge to move. For us, it would be a rather big problem if you dropped Tiger support in Qt 4.7. I’m instead fine with the switch to Cocoa as default, as long as Carbon is still available for Tiger builds.
You can see some interesting statistics in these following links:
http://www.panic.com/blog/2009/12/mac-os-x-stats-12-2009/
http://update.omnigroup.com/
As a programmer I would like to write code for the newest and greater operating system. The reality is that I have to fill my code with several #if#elif#endif to support different versions of the OS. And as you see in these statistics, today there are at least 30% of the mac-users that are stuck with Tiger.
Uhhhhh… Cocoa has existed since NextStep, has been a part of OS X since the very beginning, and has always been the recommended API to use. Cocoa very much *does* exist on Tiger.
Would it be possible to extend support for Qt/Cocoa to Tiger? This way you can drop Carbon and still retain support for Tiger.
I still have Tiger on my MacBook Pro, and I know quite a number of Mac users (especially, but not only, in school lab situations) who do not upgrade to the latest OS for whatever reasons.
If your Cocoa port does not work in Tiger, it would mean a loss of market penetration ability for my software, and some of my Phonon apps really are fare more useable/useful on Mac (Tiger or Leopard) than on Win/Linux.
Many of our users are academics that have labs full of older Mac’s (G5′s and even an occasional G4 iMac) that never upgraded beyond 10.4. It would be expensive for them to do so on their limited grant budgets and we’re concerned if we require 10.5 will lose out on sales.
As another reader pointed out, Cocoa has been supported on OS X from the beginning. Why is it Qt can’t use Cocoa on 10.4? Is this really that hard to do?
Long run (I dunno, maybe 2-3 years ago), of course I’d like to require 10.5 since that would also mean I could switch to GCC4.2. Right now I’m developing on 10.5 and 10.6, but must use the GCC4.0 compiler to provide support for our 10.4 users.
It’s also my impression that the Carbon variant of Qt is more mature/stable.
Hi, by “Cocoa is available from OS X 10.5 (aka “Leopard”), before that the only available framework is Carbon”, you meant : the Cocoa port of Qt is only supported from 10.5 (Leopard); for 10.4 and previous MacOSX versions, the only Qt port available is Carbon.
What are the points preventing you from extending Cocoa support to 10.4 (Tiger)? Are these points crippling?
For our project, Tiger support is inevitabile, and it will be like that until years from now. So if future Qt versions drop Tiger support, we will be stuck with current Qt Carbon version (and hoping for at least bug fixes) — even if some (or most) of the project’s users are on 10.5+.
First, to answer Flavio’s question: At some technical level, yes, it WOULD be possible. At a practical level, no; many of the Cocoa APIs needed by Qt weren’t implemented in Tiger.
Now, to add my two cents on the Cocoa/Carbon issue: The fact of the matter is that the Carbon port is currently much, much more stable. Running a Qt/Cocoa-based plugin ainside other applications has a ton of event handling issues — they’re steadily getting better and I’m glad to see that, but as of 4.6.0 (I haven’t tried 4.6.1 yet) there are just too many showstoppers keeping us from using Qt/Cocoa.
And as Giovanni said, lots of customers are still on Tiger and see no compelling reason to upgrade, especially those still using PPC hardware (since Leopard’s system requirements are higher).
In my industry, the upgrade was slow before the recent economy downturn. Now it’s even slower. Most of the Mac used by our customer are several years old and some are even still PowerPC. We had a hard time upping the supported OS to 10.4 just last year and I am not interested in fighting the same fight again. It can’t be won. They don’t have the money for payroll, let alone buying new Macs.
Please. Keep 10.4 supported, Carbon or not.
I would prefer that you dropped Carbon in all future versions. Keep Carbon compatibility in 4.6 and 4.6 patches but put all resources in Cocoa for the future, it will improve Cocoa quality and 64 bits is absolutely needed for our customers so we need the Cocoa port. Who knows when Apple will drop Carbon or even 32 bits in future OSX versions or even what happens with new Apple hardware… If Apple dropped Carbon completely, please do the same and spend the time where future is.
Why can’t you just have plug-able back-ends?
OpenGL, OpenVG, Cocoa, Carbon, Raster, etc.?
I’m afraid we’ll have to deal with 10.4 installations for quite a while too so if there’s no way to backport Qt/Cocoa to 10.4 we’ll still need Carbon for some applications.
The Carbon version is also still the more stable one. These are some of my Cocoa specific problems:
http://bugreports.qt.nokia.com/browse/QTBUG-7503
http://bugreports.qt.nokia.com/browse/QTBUG-6296
http://bugreports.qt.nokia.com/browse/QTBUG-7305
http://bugreports.qt.nokia.com/browse/QTBUG-5058
It’s mostly all basic UI stuff that causes unacceptable problems for the application’s users.
However it is very important to test applications against the latest Qt/Cocoa builds and find bugs like these because the day will finally come when Carbon is dropped. Until then those bugs will hopefully be resolved.
Furthermore using the Cocoa build also opens up many new possibilities as new Mac APIs are usually Cocoa only (try to set an Dock Application Badge with carbon).
As I see it, if you need to use an application for Tiger, you could stick with Qt 4.6. Moving forward needs some change, and if you don’t need to push your OS (or your clients), reasons aside, you might won’t also need what will come with Qt 4.7.
Summary is, go with Cocoa and no Carbon (like Adobe and others are doing with their products). If you need support for Carbon, stick with Qt 4.6.
Just my two cents.
Personally I don’t mind OS X 10.4, but what is important is 32 bit support and reliability, and presently Qt Carbon seems more reliable, this is why I use it. Reliability, reliability, reliability…
We have a large number of existing customers for our Qt based commercial applications who are still running OSX 10.4 on their old macs. In discussions with them recently they bring up really compelling reasons why they have not updated these older machines. Qt Carbon really needs to be supported at least through the Qt 4.7 release. The percent mix of our customer base who use OSX 10.4 is much to large to just ignore or exclude those customers from our application releases. I also strongly agree with the comments above about a focus on ‘reliability’.
My company would like to transition from Qt/Cocoa to Qt/Carbon, but so far there has always been a show-stopping bug in the Cocoa version that kept us from being able to use it.
I think with Qt-4.6.1/Cocoa there is only one show-stopper left, which is QTBUG-6444. Of course there may be other problems as well that we just haven’t noticed yet, so I think it would be good to keep Qt/Carbon around for a while longer… that way we still have a fallback we can use if Qt/Cocoa has a problem.
Gah, that should have read “transition from Qt/Carbon to Qt/Cocoa”, of course. :^P
A large number of our users are academics on limited budgets with labs of older Mac’s with G4 and G5 processors sometimes running 10.4 (I don’t believe G4′s can be upgraded to 10.5). As a result we’ve stuck with Carbon and the 10.4u SDK. Support for PPC’s is a must for some time (several years) to come. Support for 10.4 is also a must for us for at least the next few years. It’s too bad Qt/Cocoa can’t be made to work on 10.4. Finally, I have tried the cocoa port with Qt4.5 and found it had too many issues. I have not tried again with Qt4.6 in part because I know I can’t use it without 10.4 support.
Another reason for using Carbon:
It is the only way to get static (Qt) builds on MacOS.
Or did I miss something and static builds are already (officially) supported with Cocoa?
There should also be some clarification about how Qt uses Carbon and Cocoa. The flavors currently are Qt/Carbon and Qt/(Some Carbon and Some Cocoa). In other words, compiling with Cocoa support is just that. It does not eliminate the dependency on Carbon APIs.
For some time, Apple has been adding user interface items that are only available via the Cocoa API. This is an increasing problem for creating Qt applications that look and feel like the latest applications released by Apple.
The splitter widget is one case where the problem is easy to see. Qt uses the Carbon API to draw a QSplitter using HIThemeDrawPaneSplitter. This draws a splitter of controllable thickness. The problem is that this splitter always draws a knob (dimble). Modern OS X applications tend to use zero-width (technnically one pixel) splitters, and when that is attempted with Qt, the dimble is still drawn and little horrible.
To clarify a bit about the difference between Qt for Carbon and Qt for Cocoa: Both ports use Carbon and Cocoa API’s. The main difference is in event handling and window/view support, which is either fully Carbon or fully Cocoa. For other parts of Qt we use the best-fitting API, subject to availability. (Must be in 10.4 for Qt on Carbon, must be available in 64-bit mode for Qt on Cocoa.) So the Cocoa port is not necessarily about removing all use of Carbon.
We did have a brief look at extending Cocoa support back to 10.4, but spending resources on development (and maintenance) of Qt for Cocoa on that platform does not seem like the right prioritization to me.
The lack of HITheme updates needs to be addressed at some point, and we are actively researching ways of using the Cocoa components. I’ve blogged about one approach (using NSCells to draw some of our widgets) here: http://labs.trolltech.com/blogs/2009/04/17/mac-widget-style-addons/. Integrating with higher level components such as NSToolBar might also be a way to go, although that would move us away from cross-platform Qt to Mac-spesific Qt.
Concentrate on the cocoa port. Anyone who needs carbon probably won’t need the new features in the latest Qt releases (specific bug fixes asside). If you need it, stick with an older version of qt (this is complicated by the fact that side-by-side installs of Qt are not possible on the Mac because of the installer, although they can be built that way – this needs to be fixed so that installer is like the Windows and Linux versions).
Carbon applications are fairly obvious on OSX. They are 32bit only and use the old ‘classic’ cursors (the stopwatch instead of the beachball etc).
Personally I have to provide 10.4 compatible builds for my users, because some of them are still running a high number of workstations on that OS.
Sometimes It’s not the average “user” that makes you provide downwards-compatible programs. Often it’s the setup that customers/schools/a group of users has set up and is still using.
But I guess that by the time Qt 4.7 comes out the door, the number of still active 10.4 users has dropped further. Ironically nobody asked for a PowerPC build of our software yet, so it seems that even if some people are still actively using 10.4, they are already running it on a x86 CPU.
Is it time to cut Carbon emissions? Not yet in my opinion.
It nice that you decided to revisit this issue, but might I suggest that Nokia make the binary build of Creator distributed using Cocoa before you consider dropping Carbon? That was a task that I tried (and failed) to get that done while I was there as it meant killing Tiger support for Creator, which certain parties did not want. Now that an upgrade to Snow Leopard only costs $30, maybe those people might upgrade. The Cocoa port is missing accessibility as well and that makes this a premature thing to think about. Planning about how to get (and taking steps) to a Carbon-free world are good, but these two items (if not more) are showstoppers in my opinion.
And as for those who wonder why the Qt Cocoa port doesn’t work on Tiger, there are several methods that were added to NSView and NSMenu that were not there in Tiger and would make “porting to Tiger” a big pain for very little gain. At least that was my opinion. Now that there is an open repository, I’m sure I can be proved wrong.
/me crawls back into his research-y cave.
Good to hear from you Trenton! You make some good points. I readily agree, make us all guinee pigs by shipping QtCreator with Cocoa first. Once that’s working swell only then can you consider ditching Qt/Carbon. One minor point: while Snow Leopard may be cheap, it requires an Intel processor. Hence my G5 is still running Leopard. Please don’t accidentally require 10.6!
Some customers (textile designers) are still using Mac 9 software on their MacOSX computers.
As Rosetta is not installed by default on 10.5, many people in the industry are reluctant to do the move. (I am not speaking about Mac addict who are surfing on the bleeding edge OS version).
We definitely need both frameworks for now.
We plan to support only 10.5 in ~1-2 years.
Regards
Pointcarre Software (licensed Qt users)
At the Qt developer days I learnt that abandoning Carbon would also imply abandoning Qt3Support. Does that still apply? Since I still have left some Qt3 classes it would be a huge effort for me to rewrite some major parts of my main application which I currently can’t. This would leave me at 4.6 and I would have no reason to extend my support period to get newer versions.
I think when people don’t upgrade software if because his computer are old (hardware) or because existing bugs are not important for them.
Unless very big bug are found, I don’t make much effort to maintain support for older operating system.
(I’m very glad to know your new job in Nokia)
Comments on this entry are closed.