Cross platform development for Windows and Mac OS X I’ve been fascinated by cross-platform programming for more years than I care to remember, and my interest has recently been sharpened by the acquisition of a number of Apple Macs – both Intel and PPC (PowerPC). This article focuses primarily on some technical aspects of Qt, Trolltech’s cross-platform C++ toolkit which, as you …
..is whether these cross-platform apps run natively on all the systems - I've only seen Qt apps running under Mac OS X using X11 - less than ideal considering most users don't even know what X11 is, let alone how to install it.
Granted, it's very simple to install, but it's extra effort on their part that some people just aren't interested in. A hell of a lot of Mac users want to just grab an app, drop it in /Applications, and it Just Work (tm).
I remain unconvinced about the notion of cross-platform development, in that there is a lot more than separates Mac, Windows, KDE and Gnome than their widget set.
For instance, on OS X you've got AppleScript and Automator as front ends onto OSA, and as far as I understand it there is no bridge from Qt4 to the OSA events.
And of course there is the issue when you drag a file into a window and find that it doesn't accept it, even though the program can edit it if you open via the File menu. (To be fair, that can happen on native applications too).
Looks indistinguishable is one thing, feels indistinguishable is another.
Hi Drarok - thanks for the comments. Applications created with Qt do indeed run natively on all the platforms of interest. There is a X11 version of Qt available (Qt/X11) but I've never used it, and nor do I wish to. :-)
As you say, one of the key things for Mac users is to be able to just take an app, double-click it from the Finder and have it run. Or drag it into the Applications folder, and it just works. I can confirm that you can do exactly that with a Qt-built application.
Dave
I'm not sure why anyone would want to build cross platform GUI apps in C++ any more, especially when Qt is not free and open (over 5000 euro for a single development license to cover 3 platforms).
Do it in Java, and if you're nervous about Swing L&F, you can always use Eclipse RCP or similar.
You know, I used to think that Objective-C was weird and I could not get my head around it at first. But that was more to do with Apple politics than the language itself. You see Apple have a deal with O'reilly to publish Apple Developer Centre recommended titles, just a pity that O'Reilly's 'Learning Cocoa with Objective C' is such a poor book. Ditch it. Throw it away, no DON'T sell it on eBay because you'll just mess up some other poor sod's life. Instead, get a hold of Aaron Hillegass' excellent 'Cocoa Programming for Mac OS X' which gives a much better understanding of Objective-C - you'll love it really. Like programming in C# but without that weird detached feeling you get, like you can't really trust what is happening under the hood.
Hi Julian. For years, I was equally unconvinced about cross-platform dev. Many of the available tools used a 'lowest common denominator' approach and looked uniformly awful no matter what platform they were running on. But that's not true of Qt or other modern toolsets such as wxWidgets.
> I remain unconvinced about the notion of
> cross-platform development, in that there is a lot
> more than separates Mac, Windows, KDE and Gnome
> than their widget set. For instance, on OS X you've
> got AppleScript and Automator as front ends onto OSA,
> and as far as I understand it there is no bridge
> from Qt4 to the OSA events.
True, of course, and Qt does try to implement platform-specifics where it makes sense to do so. For example: http://doc.trolltech.com/qq/qq18-macfeatures.html.
> And of course there is the issue when you drag a file
> into a window and find that it doesn't accept it, even
> though the program can edit it if you open via the
> File menu. (To be fair, that can happen on native > applications too).
On the Mac, Qt uses Carbon to receive drag/drops from the Finder or other applications. On Windows, it uses OLE. You get a "native" experience whatever platform you're using. More here: http://doc.trolltech.com/3.3/dnd.html
> Looks indistinguishable is one thing, feels
> indistinguishable is another.
Feels pretty indistinguishable to me... ;-)
Dave
I have Hillegass' book which -- I agree -- is better than the O'Reilly book. But....I still think Objective-C is weird. Even when it's not being weird, it's always being verbose. By the time I've finished typing "NSMutableString", I've forgotten what I was trying to do in the first place. :-)
Language aside, the same is true of the Apple dev tools. In Delphi, or C++ Builder or even [whisper] .NET, I can double-click a button on a design-time form and -- bang! -- there I am sitting in a freshly created event handler; all I have to do is type the code that I want to execute when the button clicks. Easy-peasy.
In fairness, I don't think the Qt Designer is as smooth or intuitive as Delphi, etc, but I do find it a lot more "obvious" than Apple's own tools.
Dave
At last someone else with the cojones to say: "Emperor Jobs is streakin' down Infinite Loop."
I vastly prefer Objective-C to C#, but Interface Builder wrecks everything: it's the most confusing and counterintuitive tool I've ever used, and most of the books about it are either useless or even more confusing. It doesn't help that it's Apple and must therefore be above criticism (I despise XCode in general.)
Qt Designer is sweet. If I could get the money for Qt either personally or at work (I have ethical issues with the GPL: I don't touch it, ever) I'd have standardized long ago.
Nice to know I'm not the only one who feels that way.
For what it's worth, I'm quite looking forward to Leopard and Objective-C 2.0. From what I can see, there are some big improvements not only to the language (at last ---- properties!!!) but also to XCode and Interface Builder.
Yeah, I'd still prefer Delphi on the Mac, but.... :-)
Dave
The big catch with Qt is that it doesn't support C++.
No, I'm not talking about MOC. I'm talking about the standard language and the standard libraries.
Your code works with std::strings. Not Qt, it wants QStrings. Your code works with the STL. Not Qt. It doesn't like start/end iterators, it's QVectors or QLists.
And forget it if you want to throw an exception. Just look at the Qt source if you don't believe me:
QSomething* s = new QSomething();
(BTW, if you're a C++ programmer and don't see what's wrong with that line of code, get an ISO-standard compiler, get Boost and catch up on Guru of the Week. Your C++ will be both Modern and Exceptional in no time.)
If you're writing a GUI program that is just really a user interface, you can probably cope. But as soon as you need another C++ library which assumes an ISO C++ platform, you'll need to start writing layers of code to insulate Qt from it.
Oh, and all this applies threefold to KDE, but that's another rant.
> The big catch with Qt is that it doesn't support C++.
> No, I'm not talking about MOC. I'm talking about the > standard language and the standard libraries.
I disagree, QT is an "extension" to c++ and you can easily use string, std::vector, QStrings, and c strings in the same code with no trouble at all.
Thanks for the further info on QT. Perhaps the issue I have is more with 'cross-platform developers' then, than the toolsets they are using.
(For instance, it is trivial to make a Java app show it's menu bar at the top of the window on Windows/top of screen on OS X. The fact that many do not do so is indicative of what I see as the issue).
For what it's worth, I'd agree with you on the verbosity and obscurity of some of the Obj-C/Cocoa libraries. I didn't find Obj-C that weird - probably because I have no C++ to unlearn, wheras I do have historical Smalltalk experience.
And there are some powerful features in there, like late-binding, posing, and dynamic typing / runtime type inspection. (The same stuff that made Smalltalk a great idea but performance nightmare in the 80s).
I would imagine that the combination of the NextStep framework and Interface Builder was pretty revolutionary back in 1995 - a lot of the structure seems, to me, similar to QT, right down to the separation of the interface into an XML file read at runtime (admittedly NIBs are not XML, but can be converted to/from quite easily as they are heirachical).
However, I'd agree that some of those method names are so damn long, and IDEs have come a LONG way since then.
I understand there was an attempt, at some point, to modernise the syntax, which is what is needed (and what's with the whole idea of having NS at the beginning of classnames/methods to specify them as NextStep rather than a namespace qualified notation?).
Of course it fell on dead ground - existing developers not wanting to change, and any new developers coming in learn from existing developers.
Not taken a look at the Ruby and Python bridges, which may be an easier road in (no messing around at the C or C-derived level at all). F-Script looks another interesting way to play with Cocoa.
As someone else has said, it's perfectly possible to use STL alongside Qt. In fact, the standard 'configure' script will build the libraries with STL support *by default*. If you don't want STL support, then you have to use the -no-stl flag when configuring the system.
Implementing exceptions in a cross-platform manner is, I believe, more challenging, but if you want to throw/catch exceptions in your own code, it's not a problem.
Dave
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
