Slashdot Mirror
Trolltech Plans GPL Release For Qt/Mac
michae1m writes "Trolltech today announced that Qt/Mac will be released under the GPL (GNU General Public License) at Apple's World Wide Developer Conference (WWDC) 2003 in San Francisco on June 23rd (http://www.trolltech.com/newsroom/announcements/0 0000129.html). For some screenshots check out dot.kde.org/1055852609. This means many X11 Qt apps will be easily rebuilt for OS X without requiring X11, very cool."
The dock is, but KDE can do the 'master' (desktop) menu bar thing. It doesn't have the strict layout that MacOS X provides/requires, but it is available.
Neither Gimp nor etherreal are Qt but GTK applications.
Cocoa is nice, but I'm not so good with Obj C yet
Trust me. I speak the truth. You can become a freaking EXPERT in Objective C in a few days or a few hours, depending on how good at C you are. If you know C--the language, not all the fiddly little calls that make up the standard library--then you can be up to speed with Objective C in a matter of hours.
The best part is that you can forget practically everything about the C standard library when you're programming with Cocoa. You simply don't need it. The worst, the absolute mother-loving worst, is socket programming. Casting structs to other kinds of structs, converting from host order to network order... ugh.
Here's the code to establish a socket-based server in Cocoa:
NSSocketPort* socketPort = [[NSSocketPort alloc] initWithTCPPort:SOMETHING];
NSFileHandle* listeningSocket = [[NSFileHandle alloc] initWithFileDescriptor:[socketPort socket]];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(acceptConnection:) name:NSFileHandleConnectionAcceptedNotification object:nil];
[listeningSocket acceptConnectionInBackgroundAndNotify];
That's it. And here's the extra code to advertise that service with Rendezvous:
NSNetService* service = [[NSNetService alloc] initWithDomain:@"" type:@"_SOMETHING._tcp." name:@"SOMETHING" port:portNumber];
[service setDelegate:self];
[service publish];
Woo.
Why not this version?
m l
http://www.trolltech.com/download/qt/noncomm.ht
If you really want C++, you can also go for Carbon. It's possible to use Carbon Events and nibs for a semi-current development approach which utilizes Mac OS X's full capabilities.
Speaking of preferences, let us not forget NSUserDefaults. Mac programs that fail to use NSUserDefaults (or the analogous CoreFoundation interfaces) are instantly one strike down. So what's the point of using QT to write your user interface if it's (1) not going to look like Mac users expect, and (2) not going to work like Mac users expect? If it did one of those two things, I'd say maybe, but since it can't have either without dropping into Cocoa or CoreFoundation... why bother?
I usually work more on the administrative side but I do code in RealBasic, a cross platform competitor to VB (let them know you'd be interested in a Linux port, they're thinking about it). They do exactly that, having explicit quit, preferences, and regular menuitems which change locations depending on which MacOS is being run.
I don't know, but I would guess not. More likely, Qt is ported on top of coregraphics. Qt has never used native widgets, preferring to render widgets itself.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
There is, however, a port of GTK for OS X at http://gtk-osx.sourceforge.net/
I believe you can use this thing called Objective-C++. From what I understand, you can make Objective-C calls and use C++ to design your program. It might be a little faster than Obj-C, I guess.
Yes, but you still can't go C++-only in your app, because view elements' actions (see other postings for an explanation) can only be sent to Objective C-objects. You model can be in C++ though (which might be a good idea for cross platform apps). Speed isn't really an issue here, for Real Speed(tm) use C (which fits seamlessly into Objective C).
As an example of this, take Carbon's new HIView system, which it now uses for implementing button controls. This is, in fact, considered part of Carbon, not CoreFoundation.
Wrong again. HIView is essentially interchangeable with NSView, modulo a few minor tweaks. HIView is part of HIToolbox which is not part of Carbon. It replaces, in fact, Carbon's Control Manager.
HIToolbox is to AppKit as CoreFoundation is to Foundation: a lower-level programming toolkit on which the higher-level interfaces are based. Most programmers won't have to interact with HIToolbox in any real way.