Slashdot Mirror
Qt Released For OS X
AxsDeny writes: "It looks like Macslash is also reporting this, but Trolltech is now offering Qt for OS X. Long live cross platform development." Doesn't look like there's a Free version, but there is a non-commerical license called the "Qt Academic License," which "Allows schools and universities to acquire and use Qt for free in relevant courses."
To a good article at Kuro5hin.
Best Slashdot Co
I've always been impressed with cross-platform initiatives. Especially the ECAs big project to get Eggplant code on every system available. Including embedded devices!
Eggplants!
Ace
Actually Cocoa is based on Objective C, which is an object oriented language based on C, but is significantly different than C++. There's also Objective C++, but I don't know anything about it.
yeah, if you read through it says that it uses the native Aqua interfaces as well as sets apps up to use the Aqua interface.
zork% mv *.asp
283 files eaten by a grue
The wxWindows folks also have a Macintosh port that I believe also uses CARBON. From what I understand they are doing a great job. For python people, wxPython is just fantastic.
You can write a GPL app and link it to non-free applications. What you cannot do is link to a GLPed library and release it with a non-free (well, non GPL) license. If the library is written under the LGPL you -can- link a non-GPL application to the LGPL library though.
If your above stated take on the license was true it would be impossible to write a GPLed application for any OS which isn't GPLed from the ground up. You can write a GPL app for Win32 or Solaris, right? Last I checked their standard C library wasn't GPL.
You know when you have to dig this deep into the site to find the pricing information, it's going to hurt when you get there.
http://www.trolltech.com/purchase/qtpricing.html
US$1550 for one professional license, US$1950 for one enterprise license?
I believe all the people that say QT3 is the bees' knees, but yikes. Guess I won't be experiencing that coolness for myself.
(Wistfully remembering the days when Think C was $99, and the early CodeWarriors were around $199)
-- http://frobnosticate.com
I've got a biggish Win32 program and wonder about moving it to Qt. How big an effort?
:)
Qt is quite a bit different from MFC, and I think porting would be more effort than simply rewriting it in Qt.
Any performance hits / gotchas?
Not really... don't pay any attention to the AC trolls who bitch and moan about moc (Qt's preprocessor)... it lets you do some really neat stuff that you simply can't do with normal callbacks. As for performance, I haven't noticed any speed hits using Qt as opposed to MFC.
Any features that we'll lose?
Nope. Anything that Qt doesn't support is EXTREMELY easy to add yourself... Qt is designed in such a way that subclassing a widget to add new features is a breeze, so you can make any widget do anything you want.
Qt also provides tons of utility classes, which make it simple to do stuff like asynchronous socket/file i/o and so on. It rocks.
Want to stop being dependent on MS before they collapse!
Heheh. Good plan
I agree that Qt is quite well put-together, but after working with it for a little while (I'm mostly a GTK/PyGTK fan) I've found it has an annoying flaw that really prevents me from using it effectively: its memory-management system is restrictive, and it only works in C++.
The "restrictive" part is due to the fact that Qt takes a simplistic hierarchical view of resource ownership - parent objects own their children, and delete them when they are deleted. This forces you to implement most of your own code as subclasses of Qt toolkit classes. Aside from being aesthetically icky, this can get you into trouble when the rest of your own code has different ideas about object ownership and lifetimes. At the very least you need to write extra adaptor code or invent weak references for Qt objects.
The other problem of course is that Qt "only works from" C++. I've long since left static languages behind for GUI development; Python and friends are the way of the future. Sure there are bindings like PyQt, but PyQt has some serious memory management problems (since Python objects are reference counted, and can't easily mesh with Qt's object hierarchy). The result is segfaults and/or memory leaks even for simple PyQt programs.
Using Qt was an interesting and worthwhile experiment, but I much prefer Gtk's more reasonable resource management scheme (which has been designed from the ground up to cooperate with scripting language bindings).
This is completely untrue. Objective C++ was included in MacOS 10.1. I'm using it as we speak. It allows you to mix Objective-C and C++ code freely in a single source code file. It works just as it should. It takes much longer to compile, though. Something about pre-processed headers, I think.