On the day of WWDC all people could think about was the new G5 PowerMacs, or Mac OS X 10.3 “Panther.” While most news sites drowned in WWDC coverage, and then the whole debate over benchmarks, it was quite easy to miss this little gem. Trolltech released Qt 3.1.2 for OSX last Monday.
In all honesty, this piece of news is what I’m most excited about more so than anything that went on at WWDC, this includes those shiny new G5 systems or even the 64 bit MacOSX. The reason for this is because I believe that the Qt library has the greatest effect on the way I develop software on the Mac platform, and perhaps other developers will see it this way too.
Background
I promise to make this a brief history lesson. I’ve been programming as a hobbyist for the past 5 years, the latter 2 years and to date I am programming professionally. I started out with Windows, teaching myself C++ and using MFC to design applications. Last year I had my first encounter with a modern Macintosh computer. I purchased an iMac2 flat panel in hopes of learning to develop for this platform. Between Carbon, Cocoa, and even Metrowerks’ PowerPlant, I found this transition more trouble than it was worth for just a hobby that I might not make a career out of. So I set it down for a year now. This past April and May I revisited Linux, in particular Mandrake and Gentoo distributions, and continued my programming endeavors with Qt. Coming from an MFC background, I found Qt to be a very smooth transition. Then in June I made a come back to the Mac platform by purchasing an iBook. What prompted me to do this was that I had upgraded my iMac to OSX 10.2 and finally it was in a usable state that I felt comfortable with, albeit some issues still existed. I tried to un-brainwash myself from years of Windows programming in order to accept Objective-C and Cocoa. But as soon as I heard that Trolltech was going to release an updated Qt library for MacOSX, I abandoned Cocoa altogether.
How to get it
Now to get down to business. To download Qt/Mac Free Edition, visit Trolltech’s website here. What do you get in this package?
– The source code to the Qt library.
– Documentation in HTML format (Qt Assistant is also included for additional documentation).
– Helper applications such as QT Designer, Assistant, Linguist, and command line tools such as qmake. qmake will be a very important tool, as you’ll see later on.
– Plenty of example apps and their source.
I didn’t actually have to wait for Trolltech to make this release, as Qt has been available for OSX for some time now. It can be obtained through Fink, but it does require that the user install an X server first. I did not bother to make this attempt because I didn’t see the need to since I have a Linux box right next to me. The beauty of this Qt/Mac distribution from Trolltech is that it DOES NOT require an X server at all! Qt/Mac uses Carbon internally the same way Qt for Windows uses an API native to Windows. Trolltech had made Qt version 3.x for MacOS in the past but only with a commercial license, and if there was a free edition it was from the 2.x version. That’s the significance of this new Qt/Mac release. It brings Qt for MacOS up-to-date and introduces the dual license structure: the free, GPL’ed, edition is exactly the same as the commercial edition in terms of source code.
Setting up
The installation document covers the procedure quite well, however there is one little problem that I encountered, and is repeatable. More on that in a minute. The first thing to do is obviously unpack the package. The install doc suggested I unpack everything into /usr/local/qt and that’s exactly what I did. But since this folder is outside of my home directory I had to use the “sudo” command in order to access folders owned by root. It’ll ask you for the admin password once and remember it for the rest of the Terminal session. But you do have to use sudo with every command that requires root privileges, and I did not know of a way to get such privileges in Finder so all file operations were done in Terminal. Compiling the Qt library is just as one would imagine, “./configure” then “make”. Somewhere in the Makefile it creates the symbolic links to the lib file but it doesn’t copy the sym-links into a location where it can be found by other software. This was the problem I spoke of earlier, after libqt-3.1.2.dylib was built Make proceeded to build all the other software that comes with this package – tools, sample apps, etc. Obviously they couldn’t link to libqt so make errored out. It’s possible to copy the libqt-3.1.2.dylib file into /usr/lib or just make a sym-link. The install guide also says you can place the sym-link in your home directory, placement of it in /usr/lib is only if you want all users of the computer to have access to Qt. After making the link I ran make again and it proceeded to compile the rest of the software. But as of that point I was ready to test out Qt with my own code.
Play time
I wanted to use Project Builder, obviously because it’s a neat tool, but the instructions that came with Qt/Mac were pretty vague about how to actually setup a project in PB. So you guessed it, I ran into problems. It would compile everything fine, but when it came to linking and creating the app bundle, I got an error message from the linker saying “missing symbols” and the symbols in question is “vtable for TestApp.” TestApp was my QMainWindow widget, it’s also the name of the bundle, and there’s a TestApp.o as well, so I’m not sure what went wrong. I’m not qualified enough to go further with this issue, but if anyone else has some insight on this matter, please share it. So how was I going to build Qt apps? I went into the “examples” folder and browsed the sample apps to see how things were done. There was a *.pro file in each sample, and upon further research I found out these *.pro files were input for qmake. I didn’t know this previously because I’ve been using KDevelop, which hides most of the build steps for me so I only focused on writing code.
Now I have to learn the command-line way of building software. So I used the example *.pro files as a template to setup my test project. Here’s one piece of advice I’ll share that I learned from my own mistake: If you copy the sample *.pro file and just change the header and source files it defines for your build, there’s one directive at the bottom that goes like this “REQUIRES = full-config”. Leaving it in the *.pro file and passing it to qmake will lead to problems, qmake complains about the “full-config” option saying it’s not found or installed. This only happens if your working directory is not within the /usr/local/qt directory. Once I moved my project’s folder into the examples directory side by side with the other sample apps, qmake was happy. Upon removing the offending line in my *.pro file, I was able to run qmake happily from my home folder. qmake takes the input *.pro file and generates a Makefile for you. The syntax is very simple, in Terminal change to the directory where you have your source and *.pro file.
qmake -o Makefile YourProFile.pro
Afterwards, execute “make” and it begins building your app. Any time you add more source files to your project you’ll need to add them to your *.pro file, run qmake on it to get a fresh new Makefile, then build your app. I do miss the comfort of having a nice IDE to code in, but this method works and gets the job done. If you go into the “bin” directory you’ll find QT Assistant, which has all the documentation right there for you, with full documentation on how to use qmake. Download a simple template project I’ve put together.
What does it look like?
Screenshot1 – in the bin directory where you install the Qt source you’ll find “qtconfig” which lets you setup global options that affect Qt apps. Shown here is the option to change the widget theme.
Screenshot2 – Qt apps can be themed and the skin can be changed at runtime on the fly.
Screenshot3 – one of the many examples that comes with the package, this one is a collection of examples. In this shot I show off my iBook’s 3D capabilities with glxgears!
Conclusion.
Cocoa is the native way of developing software for OSX. My own experience is that it’s very hard to unlearn C/C++ and adapt to the mentality and style of Objective-C. I’ve read comments from other developers in OSX forums who feel the same way. It’s probably best to start Objective-C with little or no prior knowledge of C/C++. Carbon apps are written in a procedural fashion but again, it comes down to how a programmer prefers to code, and this programmer doesn’t like procedural code… anymore. I have tried Metrowerks’ PowerPlant C++ framework, and I do not like it at all. It’s not as clean and elegant as Qt, and there’s no OpenGL wrapper last I checked. Qt DOES have an OpenGL widget that wraps 3D graphics functionality. I also want to point out that it’s not possible to build the Qt lib or apps that link to Qt using Metrowerks’ compiler. You must use gcc! My feelings towards Qt in general are all positive. The dual license structure makes it a great framework for people to learn and gain experience on. It also makes it possible to develop commercial applications when the time comes.
Be warned though, Trolltech’s FAQ clearly states that you may not use the Free Edition in development and then turn around and buy a commercial license at a later date and sell your software as a product. The Free Edition uses the GPL license and it is in effect from the time you begin development. Trolltech did Apple a big favor by releasing Qt/Mac. Linux developers who are already familiar with Qt will find a smooth transition into MacOSX development. Qt eliminates my concern about “is it worthwhile to develop for MacOSX?” by making it easier to write software for MacOSX and reuse knowledge and skills in a GUI library I’m already familiar with, plus source compatibility with other platforms that use Qt. Now I’m going to go make my own IDE to make it easier for me to write Qt apps in OSX! Because if I see the word “make” one more time…
Qt was already available for Mac OS X, all that’s changed is that it’s now additionally available licensed under the GPL.
Having access to the wealth of KDE application without having to use X11 will be nice for the OS X community. However, in a commercial environment this announcement changes little.
Has KOffice or any other interesting KDE apps been ported yet?
Apple, the GPL version of the software would be a nice thing to include with the OS. This would do more for OSX than the X11 client!
Yeah, it would be great if people actually port (and post at Versiontracker.com) native OSX applications of KDE (with the needed libraries statically linked, so people can easily install them on their Macs), applications like: Kontact/Kmail, KStars, Konqueror file manager (no reason for the browser), KOffice, Quanta, KDevelop, Krusader, Kopete, KEdit/KWrite/Kate, KVirc…
I use kate from fink on MacOSX.. I’d love a native version of it on OSX available through versiontracker..
Kate reminds me a lot of BBEdit, which has been one of the most loved and used editors ever for Mac users, but it has a few features BBEdit doesn’t have, such as code folding.
the ability to automatically put toolbars at the top of the screen, under the menubar. It’s much more Mac-like behavior, and always has been. Right now, from what I’ve seen, the toolbars appear in the same window, like in Windows or X11. They made the menubar behave perfectly, and Im not sure why they didn’t do the same with toolbars.
Qt was already available for Mac OS X, all that’s changed is that it’s now additionally available licensed under the GPL.
I did mention that in the article
RE: The only thing Qt/Mac needs is…
I don’t think I’ve ever seen native OSX apps with the toolbar at the top of the screen, menubar yes, but haven’t seen that done with toolbars. Can you give me an example when/where/what app you see that?
In regards to porting, I think it’ll be best overall to back port KDE apps to use Qt classes only rather than port all of KDE into OSX. Staticly linking KDE would over bloat the apps. I wonder if it’s possible to distribute Qt or KDE in binary form (shared library) for OSX because Mac users aren’t use to having to compile software.
Check out the second screenshot in the article, QT does this (BTW, using KDE on X, this is also possible…)
If you’re talking about the little icon to the far right, that doesn’t belong to the Qt app, it’s part of OSX’s menubar icon. That particular icon is “DockExtender” from CodeTek.
If you know Carbon, you could make your own toolbars the way you want them (I’m still unclear what pret meant) and Qt/Mac has facilities to handle Mac events. Implement a Carbon toolbar and use Qt to capture the Mac event for handling the message within your Qt code!
I hope Trolltech fixes their Aqua implementation. I don’t know if Qt for Mac gets its widgets using native UI or via emulation, but the widgets just don’t look right, they are not as polished as Mac OS X’s (including Carbon apps). For example, in this shot: http://www.ly-tech.com/qtmac/screenshot1.jpg you see that the background stripes are too strong compared to Apple’s, makes my eyes whirl.
Also I noticed that many Qt Mac apps for some reason they have their text too close to the left side of a pull down widget, looking like they are “glued” to the widget.
In my humble opinion, QT is an attractive toolkit because you can maximize your code reuse over a few platforms while retaining native speed. However, I don’t see any reason (other than personal preference I guess) to choose this over Carbon/Cocoa when developing exclusively for the Mac.
the descriptions for the 2nd and 3rd are swapped.
Also, it took a little while to unlearn C++ stuff when getting into ObjC, but you find with enough same code, everything will click.
I think biggest hurdle for ME was getting the hang of Interface Builder… I’m used to setting up GUI elements by hand. Oh, and the fact that Project Builder doesn’t have method name completion (theres a plugin however, that works so-so) which is a must-have with an API with such damn long method names! Does Xcode fix this?
> Does Xcode fix this?
Yes!. It has full code-completion.
Also, being an experienced C/C++ and Java programmer, I did not think Objective C was that hard to grab at all. In fact, most of the concepts are already used to some extent. The biggest problem I had was connecting with Smalltalk-type of syntax. I prefer the C/C++ syntax, but the ObjC style isn’t going to screw me anyway…
And, by the way, Cocoa rocks! The one thing I like the most is the easy way to make component resizing…its enlightening. Qt on the other had is also great. The only gripe I had about Qt was the build process and most importantly, making apps resize consistently was always a challenge since it had to be done manually. Has this changed? I used version 1.4, haven’t used it since.
“I wonder if it’s possible to distribute Qt or KDE in binary form (shared library) for OSX because Mac users aren’t use to having to compile software.”
Well when I used Linux Mandrake 4 years ago, there were pre-built rpms for most of the common software as long as you didn’t need to be on the bleeding edge.
I’m starting to think Trolltech did some custom Aqua look too. I’ll try to get a screenshot to demonstrate when I get home, but when you use QMessageBox::information() to display a message dialog box, the default button is colored in blue (just like default buttons in native Aqua) but this blue in Qt is much darker than normal Aqua buttons.
RE: screenshots, and more [EddG3]
I haven’t tested it fully myself, but there are layout managers that will resize components inside the parent widget based on how you want it.
Yes, Qt is modeled after the Aqua of OSX 10.0. Since then, Apple has made changes to their UI, it is now much cleaner than it used to, and Panther also has an updated UI at many places. It is now more refined.
I hope Trolltech will work on this issue.
Yes but let’s say I build the shared lib of Qt and posted on my website and said: “Hey OSX users! Download the Qt lib and put it in /usr/lib to enjoy Qt apps!” would that be possible? Obviously I wouldn’t claim ownership to it, but it also raises the question “is this download trustworthy” and of course I wouldn’t want to be held responsible for anything that might go wrong from someone using a binary I distribute. It’s tricky because users aren’t likely to build Qt themselves so developers would have to staticly link Qt into their apps. It’s a matter of finding a deployment solution.
Actually static linking doesn’t sound so bad afterall, it’s better than having to load a 8.5 MB library (Qt) into memory.
Qt 3.2 beta is out for X11, might be a while before we see it for OSX. From the looks of things Trolltech is being more supportive of OSX so I’m hoping they update their UI drawing, as you point out, to use features of the newer OSX. Maybe not 10.3 but at least the look and feel of 10.2.
> I haven’t tested it fully myself, but there are layout
> managers that will resize components inside the parent
> widget based on how you want it.
But you still have to code it right? In cocoa, you don’t code a thing, don’t need to use layouts (like Swing, for example, which has this plethora of layout managers), nothing. Just point and click and your application resizes flawlessly.
Ah but you have to do the “point and click” procedure for every new app you start. If I were to start a new app that resembles something I’ve done previously, I just copy paste source code and I’m done too!
Also, if you have the time to learn it, Qt Designer can do the same as well, you can drag and drop layout managers/helpers into a dialog and load it at runtime, or have Qt Designer generate the code for you. The output file is *.ui which I believe is in XML format to describe the form, and is loaded at runtime when the dialog is constructed. True, it’s not as plain and easy as project builder, but it’s cross platform compatible
The code you write never goes to waste.
License-wise, there would be nothing wrong with building a Qt/Mac shared library and hosting it. The GPL already comes with a “no-warranty” clause, so you’re not responsbile for anything that happens to other people’s machines unless you provide a personal warranty. If you’re worried about trust worthiness, do the same thing everyone else does: post md5sums of a known-good binary on a trusted website.
Ah but you have to do the “point and click” procedure for every new app you start. If I were to start a new app that resembles something I’ve done previously, I just copy paste source code and I’m done too!
The same can be done with the .NIBs for IB. Just drop the NIB from one project into the other and modify to your heart’s content.
I think the point anyone who has used IB is trying to make is that doing layout in IB is much easier than trying to do layout in code.
Yes, Qt is modeled after the Aqua of OSX 10.0. Since then, Apple has made changes to their UI, it is now much cleaner than it used to, and Panther also has an updated UI at many places. It is now more refined. I hope Trolltech will work on this issue.
TrollTech should be using native widgets ala SWT rather than trying to take the (traditional) Swing approach (ironically though, Swing does render with native widgets on OS X)
I hope TrollTech looks at the difficulty of maintaining an OS X look-alike/work-alike toolkit with Apple changing the style every release and realizes that hacking native widgets to fit into Qt’s layout and event handling framework is easier and a better approach in the long run.
I think the point anyone who has used IB is trying to make is that doing layout in IB is much easier than trying to do layout in code.
I agree! I like IB too but what doesn’t appeal to me is Objective-C and the Cocoa framework. It doesn’t make coding non-GUI functionality easier for me. But that’s just me and my thick head 🙂
Well it looks like Trolltech chose not to use native widget rendering in favor of allowing different themes/skins and look-alikes for different OSes as seen in the first screenshot. So they override the default widget rendering, their Aqua look is just another skin like the others. It’s probably more work to disable skining whenever the Aqua look is used, and I think that’s their reasoning for making their own Aqua look-alike.
This sounds a lot like my experience w/ the Qt-Mac demo: it took a while to get it to work at all, but then it worked great. The custom preprocessor issue bothers me less than using Objective-C. Metrowerks, BTW, makes command line versions of its compilers that might work as GCC replacements (for much faster builds, better code quality, and smaller size binaries.)
The Mac _desperately_ needs a full-featured, crossplatform development environment, supported and “commercial” enough to get past the PHB’s. I simply can’t write apps for Mac that have to be completely rewritten for Win/Linux: the company would probably opt to skip the Mac version entirely. Apple’s “Mac or nothing” development policy is backfiring in a big way.
A few niche players are starting to use Cocoa, but it’s going nowhere as long as it’s strictly Mac-only (GNUStep isn’t quite there yet.) PowerPlant semi-supports OS X and is crossplatform (at extreme cost, last time I checked.) A few other libraries exist but they have limitations, especially being “non-commercial.” And .NET clones (if they’re ever ready) bring a whole new set of issues.
Qt is the ultimate in respectable-ware and I’m watching again with interest. I wouldn’t have a problem developing before buying a license: realistically, that only prevents releasing/announcing. TrollTech actually benefits: we didn’t use Qt before because of the price, not the features. Having a working private demo might have shaken loose the money.
Right now a few of us have a private project using a Cocoa UI and pure C++ back end, to allow for porting. Using Cocoa at all is poor business that I justified on the basis of adding Cocoa and C++ integration/crossplatform experience on a large scale app to my resume. If it looked as though Qt experience was going to be at least as valuable, I’d dump Cocoa and switch.
Yeah, it would be great if people actually port (and post at Versiontracker.com) native OSX applications of KDE (with the needed libraries statically linked, so people can easily install them on their Macs)
Statically linking dynamically loaded libs could be a problem
TrollTech should be using native widgets ala SWT rather than trying to take the (traditional) Swing approach (ironically though, Swing does render with native widgets on OS X)
That would be awful lot of work for the standard widgets, as they currently build on the base widgets capabilities.
But it would be impossile for customwidgets, woulnd’t it?
If you look at what other companies are doing, take for example Alias|Wavefront’s port of Maya to OSX, they had to use Carbon because Carbon is a C API and as far as Mac programming is concerned, it’s the closest thing to their existing C/C++ code on other platforms. Even Apple admits that Carbon is old and not well suited for the OSX environment and they encourage developers to choose Cocoa over Carbon.
I can assure you that this release of Qt/Mac (v3.1.2) is better than past versions and demos. If you go here: http://www.trolltech.com/freesoftware/index.html and follow the link to http://sourceforge.net/projects/qmwedit/“>qmwedit ” in the needed source files and it built beautifully.
RE: RE: KOffice Yet
Statically linking dynamically loaded libs could be a problem
That only applies to the developer’s system. If I built Qt in a manner meant for static linking my apps would link Qt statically. For the end user, it would not load the dynamic Qt lib if that’s what they had installed on their system.
That would be awful lot of work for the standard widgets, as they currently build on the base widgets capabilities.
RE: Kevin
But it would be impossile for customwidgets, woulnd’t it?
Not necessarily. The QWidget class can be made as-is, and custom widgets can be derived from that. But existing widgets like push buttons, listboxes, etc., thier corresponding Qt class can subclass QWidget but overload it to call back into Carbon’s widget creation so what you end up with is true Carbon widgets managed by a Qt class. Doing so will result in the loss of skinning/themeing which we have on other platforms.
I think it’s actually a good idea that Trolltech did it the way they did, make their own Aqua theme rather than use pure Carbon widgets. Think about what would happen when you try to compile/port an app that makes use of skinning/themeing. It wouldn’t work right if that feature was not built into the Qt lib.
Please don’t use HTML when creating links. Just post the URL with spaces around it, it is written clearly below the posting form.
tly: you don’t understand. A KOffice component is a dynamic library. So, if you wanted to link statically, you would have to link all your KOffice components in one large blob.
Explaining further: KWord is a library, and the real application is a container that loads the KWord component.
Really, turning KOffice (or most of KDE, really) into static binaries would:
a) Be a lot of work
b) Make it incompatible with the version the authors work on (you would have to redo it each time a change happens)
c) Really silly technically. KOffice apps have lots of common code, which is in shared libs for good reasons. The shared lib allergy seen in osnews is really a peculiar phenomenon.
Exactly.
If you would statically link every viewer for a MIME Type into Konqueror it would be huge.
And there are plenty of MIME types.
It would get incredibly huge!
And, as Roberto wrote, a LOT of work, unpleasent work
Not necessarily. The QWidget class can be made as-is, and custom widgets can be derived from that.
I mean, spezial custom widgets that use the QStyle API to look like a standard widget, but having some extended functionality that cannot be achived by subclassing the standard widget.
Say something stupid like having a Scrollview on a button.
The widget would look like a button on all platform other than OSX if QButton would use a native widget there.
Now that you mention it, I remember reading in the Qt docs which states that if an app needs to use plug-ins it must be linked dynamically. So thank you for clearing that up. And I agree, linking everything staticly into one big blob is very unattractive 🙂
To Kevin: regarding custom widgets. I hear what you’re saying, and I even defended the way Qt makes their own Aqua look-alike widget set.
I said:
I think it’s actually a good idea that Trolltech did it the way they did, make their own Aqua theme rather than use pure Carbon widgets. Think about what would happen when you try to compile/port an app that makes use of skinning/themeing. It wouldn’t work right if that feature was not built into the Qt lib.
So yeah, maybe Trolltech could have done a better job artisticly to mimic Aqua, but it’s as good as it gets.
I am not really up to speed in OSX innards, but Qt seems to draw its Aqua widgets using Appearance Manager
http://www.trolltech.com/products/qt/mac.html
And it seems Appearance Manager is part of OSX, not Qt
http://developer.apple.com/documentation/Carbon/Reference/Appearanc…
And since it seems it’s supposed to draw just like Aqua:
”
The Appearance Manager coordinates the look of human interface elements in the Mac OS. You can use the Appearance Manager to adapt any nonstandard interface elements in your program to the same coordinated look as the rest of the Mac OS. The Appearance Manager also provides many standard human interface elements, such as focus rings and group boxes, that can eliminate the need to create and maintain your own custom solutions.
”
I am not sure what’s the problem here 😉
Could be a bug in Appearance Manager, coule be one in Qt. Someone who knows this stuff would have to look.
That is an interesting statement at the end of the article. I am still the owner of the software I develop and I am free to re-license my code at any time. A library cannot force my code to be GPL if I can offer it without any other GPL components. So I am not sure how TrollTech intends to enforce a license on MY software once I buy a commerical version of thier library (unless they are doing that as an add-on to the GPL). Even then, I could probably re-license MY code to a 3rd party that has an existing commerical Qt license under a license other then the GPL.
This seems pretty iffy to me.
I was browsing the Qt source code. Seems like widgets draw their backgrounds using Pixmaps or color palettes. Haven’t seen any Carbon code or references to Apperance Manager. Hmm…
I’m sorry if I wasn’t clear about the licensing. Once you buy the commercial lincense from Trolltech you DO NOT have to release the source code with your product.
Right now I’m rebuilding Qt according to the guide on KDE’s website, the first steps in building KDE. Wish me luck. Pushing the limits of my iBook 800 MHz.
There are two ways TrollTech can enforce their license. If you use GPL’ed Qt during development, your software has to be GPL complient while you are developing it. That means if you distribute the code (for example to testers and whatnot) that software must be GPL’ed. Under current copyright law, you cannot change a license retroactively. Thus, if you change the license, what happens is that everybody’s GPL’ed copies are still valid. Any future changes to the code base, however, do not fall under the GPL.
The other way TrollTech can enforce their license is by simply refusing to sell you a commercial one. Presumably, the contract for the commercial license stipulates that you do not use the GPL version of Qt for development. If you breach that contract, they are entirely within their rights to deny you access to the commercial version.
Interesting – the article just had a typo (or I mis-read it).
And actually, if you give out binaries to a closed and small number of testers, you are not required to give out the source under the GPL. It has a clause for that exact situation.
I can only understand someone using QT for an OS X program if they already have an application written with the framework. However, for new programs, no matter if you know C, C++, or any other language, Cocoa is certainly the way to go.
The tools are fast and easy to use, and the language is very well documented, along with the framework itself. There is no better way to create blazingly fast OS X-native programs with beautiful 100% aqua-compliant interfaces than using Cocoa with Interface Builder and project builder.
It is correct to say Qt/Mac uses the Appearance Manager to render most widgets. QMacStyle is where the Appearance Manager / QStyle glue code lives, you will see in there drawing of (all available) primivites are implemented in terms of the Appearance Manager.
It is also correct to say Qt/Mac *was* based on Aqua in 10.0.x in the 3.0.x series, however with 3.1.0 release there was a new style so that Apple (read Appearance Manager) is doing the drawing for us (this means installing third party style, and running a Qt app will respect your new style).
I can only understand someone using QT for an OS X program if they already have an application written with the framework. However, for new programs, no matter if you know C, C++, or any other language, Cocoa is certainly the way to go.
But how do I justify to my boss that the app we are releasing on OS X can’t be ported to Windows or Linux because it uses a language that is rarely available on one platform and (from what I can tell) non-existant on windows.
Cocoa is great, don’t get me wrong, but one day I might want to port my app, maybe not soon, but Cocoa will stop me doing that ….
Being a big fan of Qt, I started pondering a rebuttal to Marc Weil’s post. Then I realized something. As much as developers appreciate the idea of developing for MacOS with a safety net that their apps can be ported to a different OS in the future, what Apple really needs is more developers making “OSX only” apps. So in that respect, yes it would be good to advocate Cocoa. That’s only if you’re a die-hard supporter of Apple. In reality, most developers want to get more mileage out of their skills.
Without a port to Windows (or the completion of the Gnustep code) how on earth can Cocoa be a better solution to our problems if it is then so platform specific that a complete re-write is necessary when we want to port to Windows/Linux.
This, I think, is why you won’t see Carbon disappear too soon .. hence QT is a *fantastic* solution to the problem. You can make use of your hard earned C++ skills and still re-use the code on another platform in 6 months time. Learn yet another API and programming language for a single platform … ahh no thanks.
I will agree that Cocoa/Project and Interface Builder is the best tools for MacOSX programming. But from a business point of view of independent software companies, it’s more along the lines of what Anonymous is saying. Apple won’t attract new and different developers by having a development environment so radically different from the rest of the world. Software developers won’t care how easy PB or IB is to use. When you’re looking at MILLIONS of lines of code (Maya racked up something in the neighborhood of 12.5 million lines of code) Cocoa is NOT the answer.
One thing I will complement Miscrosoft for is backwards compatibility. The Win32 API and MFC have been criticized by many, but hey, I can write code and it’ll compile on all Windows OSes from 95 to XP. Granted some care needs to be taken but it’s not as Carbon/Cocoa and Classic environment. Furthermore, the same code written for desktop Windows OSes can be easily ported to WinCE which is exactly what I do for a living. I purchased a license to an XML parsing C++ class that compiles on desktop Windows as well as WinCE with NO code modificaton at all.
I’ve now spent a few hours playing with Qt and building a few little apps using their Designer.
Building in the Terminal isn’t so bad (up arrow + return, come on), except for being so sloooow (gcc). I notice they have data files for PB & CW, but no info. A build system for CodeWarrior would be killer; I did one for iShell a while back that worked well (ditched MPW and Visual C.)
The Designer is clunky and doesn’t look very good compared to a “real” MacOS app. It is vastly superior to Interface Builder in terms of productivity & intuitive design, however, and comes with doc’s that are light years ahead of Apple’s. I actually feel more comfortable with Qt after 1 day than I do with PB/IB after several thick books and test projects.
Qt apps don’t generally look as polished as Cocoa, but they run fast. It’s wonderful to have the source available. I can tweak or even add native controls.
Bottom line: if I was doing free software it would be no contest, Cocoa is out of there. Since I’m not, and have a lot of code already done, I have to think about it a bit more. If I ever want to port… again, no contest. We’d make the license price back several times over before beta.
Has anyone thought how OpenStep once sold for $5K / seat and helped built a company worth $400M when Apple bought it? Look at it now (and it’s free.)
Unless you’ve got a lot of knowledge about KDE internals as well as Qt, you’re not going to have a native KDE yet.
See my blog entry at http://ranger.befunk.com/blog/ for more, but the short of it is, not all of the patches to make KDE build on OSX (even without Qt/Mac in the equation) are there yet. I’m working on it, and most of arts and kdelibs are in place, but there are some admin bits that are out of my hands that we’re still waiting on.
> And actually, if you give out binaries to a closed and small number of
> testers, you are not required to give out the source under the GPL. It has
> a clause for that exact situation.
That’s incorrect. The GPL does not have such clause.
Perhaps you are confused with the distribution of a GPL’ed work within an organisation. See http://www.gnu.org/licenses/gpl-faq.html#InternalDistribution
Cheers,
Waldo
Contrary to what people have said, GCC supports objective-C (as do other compilers, I’m sure)
So, if you write your code in Objective-C, theres nothing making it less cross platform.
I suspect most of the people posting to this thread haven’t actually done cross platform applications– or they’d realize that it is very common (And WISE) to do your UI in platform specific code and your functionality in whatever language you want.
Thus you can write your whole app in Objective-C, and if you’ve wisely used the MVC (Model-View-Controller) paradigm, the back end just needs a recompile, and you can create a Windows, or Linux UI for the front end relatively easily.
This is, in my opinion, a much better way to go for cross platform than using widget sets like Qt because Qt doesn’t seem like it would look right on the Mac. (Since Linux and Windows have almost the same UI the differences are less significant there.)
Rather than develop to a hode-podge UI that’s a compromise between Linux, Windows and Mac OS (which I’m not accusing Qt of), a cross platform strategy that has localizing the UI for each platform is a better way to go.
I’ve done this with video games I’ve worked on in the past, certainly other less platform intensive apps can do it as well.
Learn Objective-C– its the best language out there, really. And you can recompile your Objective-C code on Windows or Linux if you want to later.
Yes we know Objective-C is cross platform, what I and others here are saying is *Cocoa* is not cross platform. If you write a Obj-C app using Cocoa, you can not recompile it on a Linux system even if that system has gcc which supports Obj-C language. Do you see this now?
Correct me if i mis-interpret what you’re saying. You’re suggesting that developers seperate their apps into a presentation layer (the UI code) and the application layer (back end functionality). Then write the back end code in Obj-C for portability while reimplementing the presentation layer in the platform’s native UI libraries. That’s actually a lot more work! Why do something like that when Qt provides facilities for UI and back end functionality (file IO, database connections, memory management, data type conversion).
I see that you prefer Obj-C as a programming language and we’re not here to compare languages, we’re comparing different styles of development and 2 different code libraries for development.
A Cocoa app is sort of portable to unix via GNUStep (less any Apple-specific stuff); Windows is barely supported (alpha level last I looked). And since Apple doesn’t document their .nib file fomat, you can expect to do some recreating of UI (there is a translator tool that helps but isn’t complete.)
Apple’s version of gcc actually does Objective-C++, which allows you to mix C++ and Objective-C in the same function. This is a huge plus and makes coding much faster and easier than “plain” C (which Objective-C is.) I’ve heard rumors that Apple’s gcc sources won’t build an x86 compiler, and if it did, you’d still need Apple’s runtime, which isn’t quite like GNUStep’s. Supposedly Apple has presented the OC++ patches to gcc.org and they’ll get incorporated at some point…. Meanwhile, GNUStep limits you to pure C.
Objective-C isn’t a bad language; I’m constantly finding things it does better than C++, but C++ does a lot more that Objective-C doesn’t. It would be nice to have both, but if I have to choose I’ll go with C++.
Does anyone know of a non-gcc objective C compiler for Windows? or alternatively any objc compiler as long as it doesn’t require cygwin.
I can use a decent filemanager in OSX. I can’t stand the Finder, esp. since they’ve gone with that godforsaken metallic look which violates their own HIG.
I wonder how easy it will be to make kdesktop replace the Finder desktop (or at least overlay it)?
Sam is correct. Since 3.1 Qt/Mac uses the Appearance Manager which is part of Mac OS to render widgets.
Ok there is an exception the pulsing of the default button has to be emulated as there’s no support for that in the Appearance Manager (yes we filed a bug with apple about that). But for everything else we _don’t_ emulate, instead the Mac OS itself renders the widgets, according to the current Mac style (aqua/graphite/3rd-party).
IIRC the code is in $QTDIR/src/styles/qmacstyle.cpp
You can use Qt/Mac with Project Builder, you just have to tell qmake to generate a project builder project from a Qt .pro file.
IIRC the syntax is
qmake -spec macx-pbuilder yourprojectname.pro
Then open up the generated .proj file in Project Builder. Qt was even used as an example by Apple in xCode in one of the Developer Tools sessions in WWDC2003.
You can use Qt/Mac with Project Builder, you just have to tell qmake to generate a project builder project from a Qt .pro file.
Awesome! Worked the first time on the AClock example. No more gdb from the terminal!
I also tried generating a CodeWarrior project. Compiling is at _least_ an order of magnitude faster, amazing so.
I had problems:
– Access Path errors, not hard to fix (probably typos in Qt’s data files);
– Link failed w/ undefined symbols.
I believe the link problem involves the MOC not getting run: PB has some extra .mak files that seem to do this as a separate build step. qmake is generating an empty file called “aclock.mocs”.
Anyone know about this, or know someone w/ a paid license that wouldn’t mind asking TrollTech? If this is just a matter of running their tool, it would be well worth writing a CW plugin to handle it (done that before.)
Alternatively, has anyone experimented w/ adapting CW’s command line compiler & linker to PB? I could live w/ PB given the extra build speed.
How did you get CodeWarrior to even compile the source? When I setup a CW project and started compiling a test app, it quit on me, the output takes me into the Qt source to a place where it says the OS/platform isn’t supported, go *somewhere* to read about porting Qt.
I installed qt in ~ rather than /usr (change the environment variables to match.) Shouldn’t matter in this case.
I tried the first example, aclock, so I first cd’ed to there and ran
qmake -spec macx-mwerks aclock.pro
which produced aclock.xml + several new text files (see below.) The Makefile was NOT changed.
I did File / Import Project in CW 8.3 and showed it aclock.xml. I got an unexpected quit during import the first time but everything’s worked thereafter so I’m assuming it was a fluke. CW had been running for a while & I had another project open….
There were 2 access path errors in OpenGL.framework and AGL.framework. Not hard to fix (and not unusual.)
I did a Make and all the sources compiled (no errors and I got code/data values). Then the link failed w/ 7 missing symbols. All of them were QMetaObject-related (found them in files in the qt directory.)
One qmake-generated file, aclock.mocs, was added it to the “Qt Generated” section of the CW project, but it was empty. Looking at the PB project (do one, it’s easy), there are several scripts that do stuff w/ the MOC. My guess is that their tools need to run as part of the build (they generate extra source files, like aclock.mocs?) and it isn’t happening. I haven’t figured out how to fake it so far but it should be possible: I could even deal with a .command file to generate the .mocs file manually.
I think if you’re going to develop for the Mac and for other platforms, you should look at the way professional developers have been doing it.
MVC- – the Model View Controller paradigm is the way to go, and Cocoa supports this inherently.
Thus, if you develop your application on the Mac and then want to move to Windows, you’ll just need to re-write the front end to have a windows UI.
If you’ve done it correctly, this will take less time and less effort than, say, going with a cross-platform framework like Qt.
Judging from the comments in this thread, I suspect many of the readers are new to the Mac platform and / or entry level programmers. That’s ok, and if you are a Linux or Windows developer and you want to stay there and just support the Mac to some extent, then Qt is a good solution. You should recognize that your Mac customers will likley be mildly (or seriously) annoyed at the non-Mac LaF of Qt. Or that to avoid this you’ll have to do a bit of work.
Cross platform toolkits are not a panacea. The platforms are very different, and in order to bridge you have to make a choice: Make the programmer do less work and have every platform be sorta mostly supported, or have the programmer do more work to make each given platform well supported.
On the other hand, if you are experienced with each platform, or are trying to produce a commercial quality Application, %90 of the code you write should not be interface code– and the interface code should be very straightforward.
Thus, you should be able to easily write a windows native front end, or a Linux native front end to your application that was developed on the Mac using Cocoa and Objective-C. Odds are you can do it all in Objective-C or Objective-C++.
It is my experience– and I’ve used a lot of cross platform toolkits– that when you’re looking at supporting multiple platforms, this is the way to go.
Cocoa and Objective-C are a different paradigm. I think that many of you should investigate it further before writing it off. I think you’re missing the point. And some of you definately have missed the fact that even though Cocoa is the best example of MVC I’ve seen on a platform, that doesn’t stop you from using the same paradigm on other platforms.
In all seriousness, for the app I’m considering working on next, its my intention to write the Mac version using Cocoa, and then at a later date port to Linux and Windows by re-writing just the View part– just the UI. I looked at Qt for this purpose, and other than their onerous (and expensive) licensing terms, the fact that this approach would not actually save me time is a big factor in my decision.
Look carefully at this, if you want to develop a commercial or commercial quality product.
IF multi-platform support with minimal effort is your goal, then RealBasic would be a good way to go. … but if you’re primarily a Linux developer, and you’re shipping GPLed code, then Qt can helpl. IF you’re a big corporation and you want all platforms versions of your app to look the same, then the disadvantages of Qt are actually advantages.
But if you want the mac version to be appreciated for its UI by mac people, I believe you’re going to spend more time tweaking Qt than you would save by re-writing the front end in Cocoa.
For an example of what I’m talking about, look at the screenshots in this article. None of them look like the Mac.
Yeah, they have aqua style widgets, but they are not right. The layouts don’t follow apple HIG (which are very different than Microsoft, and I’m not sure Linux has them, certainly the Linux style is very different.)
This means either you use Qt widgets and do custom layouts for the Mac, or you ship an application that looks like a Windows app with an aqua sheen. Mac users have had enough of those apps from bad ports in the 90s (which led idiot software companies to say “See! Our non-mac app quick and dirty port to the mac that looks like hell didn’t sell well! The mac isn’t profitable!”. They are now wary of this.
Taking a button and using the windows widget on windows and an aqua widget on Mac is not enough– the placement of the button, the feel of it, and the functionality are all platform specific.
I know people tend to be really happy with the gui toolkit they’ve invested a lot of time to learn. I suggest anyone who thinks that they wouldn’t be better off with Cocoa and Objective-C should spend a day learning Objective-C (that’s how long it takes to learn) and then a couple days building Cocoa examples until you have that “Ah HA! Now I see it!” moment and truely grok what Cocoa is and MVC. Then you will be in a very good position to evalutate Qt.
You could probably do this in less time than it takes ot get proficcient in Qts classes.
But if you’re not willing to make that effort– at least look at the screenshots of Qt apps on the Mac. None of them look like the Mac- they all look like Windows apps with a whitewash. IF you’re used to Windows (eg: Linux, same UI) then you may think they look “Maclike” but go to the apple website and look at some of their screenshots and compare.
The differences are significant. And those differences have to either be overcome by development time, or just left in, undermining the quality of your app. IF you do the development time, you’ve obliviated the benefit of Qt, and if you don’t you’ve lowered the quality of your app.
I know people tend to be really happy with the gui toolkit they’ve invested a lot of time to learn. I suggest anyone who thinks that they wouldn’t be better off with Cocoa and Objective-C should spend a day learning Objective-C
I’ve spent more than a day learning Objective-C and you’re right it’s nice. At the same time the Java guys are saying *exactly* the same thing, but I spend 6 years with Java .. I feel differently.
Also following your own argument, why don’t you spend a day in a single language and try using QT to see what you can do. Sure it won’t follow the HIG for you, you’ll have to do it yourself. Check out how long it will take you to get it compiling on Linux and Mac *with minimal effort*. And this is the point, MVC is very nice and tra la la but you still have to write the view, in reality because of the way the different kits work you’ll probably have to either re-write the controller or come up with some bastardisation of the MVC pattern.
My boss doesn’t like it when he has to pay me more to do something slower rather than quicker, with no discernable benefit.
I just finished digging through the (XML) CodeWarrior project file that qmake generated.
There are commented out entries for 2 extra file types: the .mocs file I was wondering about, and .uics (related to Designer?) They are both mapped to a compiler named McMoc, which does not seem to exist in the Qt distribution (so I couldn’t install and try it.)
I now believe that a custom compiler plugin is the key to gettting Qt and CW to play together. Could someone w/ a paid up license, press credentials, etc, ask TrollTech about this and let us know?
Last year when I did the Qt demo it mentioned that CW support was on the way. given that CW is much faster and slicker than PB, and Designer is incredibly easier to use than IB, and making a custom UI takes 1/100 the effort of writing a new UI layer, this could really help to sell me a license.
Haven’t tried CodeWarrior yet, will have to reinstall it.
I started a test app and tested the qmake -spec macx-pbuilder as suggested by Don Sanders and it built perfectly! It generates the moc_*.cpp files which get compiled into moc_*.o objects.
Paul:
Since you were testing it with the aclock example, I did something different that the aclock.pro might not have had. I created a folder “obj” and in my *.pro file I set:
OBJECTS_DIR = ./obj
MOC_DIR = ./obj
Project Builder put the *.obj files in the Build folder anywaus but my moc_*.cpp files did in fact go into ./obj
Don’t know if it makes a difference or not, maybe you could give it a try with the aclock example again and see if it works for you? I had no problems with access paths or link errors.
Don’t know if it makes a difference or not, maybe you could give it a try with the aclock example again and see if it works for you? I had no problems with access paths or link errors.
I tried it again w/ the action project. PB works perfectly (I got the obj directory) but CW still has the same 2 path errors and won’t link. The file action.moc stays empty.
It ought to be possible to generate action.moc somehow, by manually running a tool from the Terminal. Haven’t figured out the details.
I’m still thinking that the mysterious McMoc is the key, and that it is an unreleased but hopefully-coming-soon plugin to fix the build process for CW.