On Jan 5, 2006, at 7:17 AM, Brant Sears wrote: >> [referring to Qt and wxWidgets cross-platform libraries]
>> If you want to create a "real" Mac application, you will have to use
>> Cocoa or Carbon.
>> Only if your application is really unique you may get away with a
>> cross platform framework. Otherwise you will most likely lose out
>> against the (Cocoa or Carbon) competition.
>
> I'm not knowledgeable enough to argue a position on the Qt vs
> wxWidgets
> comparison (there's plenty of discussion elsewhere) but I will
> correct some
> inaccuracies implied in Andreas's post. wxWidgets/Mac is built on
> Carbon;
> there's a Cocoa version (wxCocoa) available, albeit still in
> development;
> and the wxWidgets apps I've seen (e.g., Audacity,
> http://audacity.sourceforge.net/) sure look like "real" Mac apps.
>
>
>The Qt framework on OS X is also built on top of the native OS X
>frameworks. Apps built with Qt are "real" Mac applications - at least
>they certainly look and feel like "real" Mac apps. And, if you need
>it, there are Qt interfaces that expose the underlying GUI objects
>and event system. Of course, this is somewhat moot if you don't care
>about cross-platform. I say somewhat because the signal/slot
>mechanism in Qt is so cool that it alone is enough reason to use Qt.
>Combined with the wealth of other Qt features (networking, XML,
>databases, QSA, etc.), I think Qt is an outstanding choice,
>regardless of platform. Having written lots of apps in X/Motif,
>native Win16 and Win32, MFC, and Java (AWT and Swing), switching to
>Qt almost 5 years ago was one of the biggest leaps in productivity
>I've ever had.
I like Qt. Everything you say about it is true. However, there are a few things you lose by writing a Qt app instead a Cocoa or Carbon app. Qt has a "skin" system that allows you to create an application with Qt "widgets" skinned to look like native widgets. They disable the aqua skin on any platform other than MacOS X so as not to anger Apple Legal. However, the controls that you see are not native controls. For instance, if you use the Accessibility Inspector on a Qt application, you will find that the disability system only sees the window - not any of the controls. Other systemwide facilities might not interact correctly with a Qt app (e.g. possibly AppleScript).
If I was trying to write a professional app for a wide audience (e.g. the Mac shrink wrap market), I might avoid Qt for this reason. However, I have used it on other kinds of projects and it is very nice.
Qt is being used for a number of commercial Mac apps. Perforce P4V (their GUI app) and Adobe Photoshop Album are two examples.
The Mac version of Qt is actually an exception to the usual method of widget emulation now -- most of the Aqua-looking UI elements actually are real native widgets (eg, buttons, pop-ups, radio buttons, etc.) with their C++ API as a wrapper, and it seems they're moving more in this direction with each release. I spotted at least one Trolltech engineer at the last WWDC, so I know they're at least thinking about these issues. That said, a cross platform library is forced to stick to the common elements offered by the platforms it supports. You lose certain things like spell checking in text fields and built-in brushed metal windows. You can add certain things like support for double-clicked document icons in the Finder by just using Carbon calls and putting them in #ifdef blocks but its true, a true native Cocoa app has a certain magic that's hard to emulate with a cross platform library.
In our case these challenges were made up for by the ease of having a single code base to work with. I do 90% of my development on PowerBook and once in a while compile and debug on Windows. Most of the time the changes I make on the Mac side just work on the Windows side. Being able to stick with our native language of choice, C++, is also a boon. It'd be much more difficult to develop if we had a C# version of our app and an Objective-C version on the other side, and harder to find developers with that cross section of skills as well.
The license could be a bit tricky if you're not sure ahead of time whether your app will be Open Source or commercial (you would violate the license to start off with the free version and then switch to the commercial version later). In that case I'd probably look at wxWidgets. I'm curious to see wxCocoa's progress. Last time I checked it was in its very early infancy.
There are a couple of options for using Qt with Xcode. One is to use qmake, which automatically generates either a Makefile or an Xcode project for you based on a config file you create. This is a great way to get started. For a more complex project with multiple external libraries you'll probably end up creating an Xcode project by hand, using their generated project as a guide.
Gunnar |