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."

Comments

Not only is it good for Apple

[dbrutus]

It's good for the projects. Free software gets introduced to an entirely new clientle, the kind of end user that is exactly what the OSS movement needs, one that is uber picky about UI, is very loud about it, and will nag and complain until the UI is fixed.

*That's* what's been missing from Open Source and it's arriving not a moment too soon.

Re:Not only is it good for Apple

[mccoma]

Apple has some very good reasons and research for the differences. Tog's book on interfaces gives some excellent insights into the process and reasons for the way things are on a mac. A lot of money was spent on the interface and the research did go to improve the user experience.

In a lot of ways, I wonder why frameworks don't deal with a meta-structure and then arrange menus to fit the platform. Admitially, a lot of resources are unique to a platform (icons of different sizes), but everyone has "preferences", customize the toolbar, copy / paste, find, program specific, application level (quit), and file level (open, close, etc.). Assign location at a "higher level" and let the framework do it jobs for the machine.

Re:Not only is it good for Apple

[Anonymous Coward]

I think apple did this on purpose

Yes, they did, but the short answer is that Apple has been doing it longer than anybody else. Any time somebody creates a new windows-and-mouse interface, you have to ask yourself, "Why did they choose to be different from the Mac way here?" Often the answer is, "To be like Windows," but that just raises the question of why did Microsoft choose to be different from the Mac?

Re:Not only is it good for Apple

[Anonymous Coward]

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?

Re:Not only is it good for Apple

[dbrutus]

Actually there is something called objective C++ which you might not be aware of which should allow you to take advantage of all sorts of Mac OS X goodies in otherwise C++ files.

I think that QT is not the wrong answer but rather the right answer to a question you aren't considering. There's likely to be a market for it for people who want Mac programs and QT software to reside on the same machine. Not having to have the overhead of X11 is a real plus and should be viewed that way.

Re:Not only is it good for Apple

[dbrutus]

What was transplanted into what *is* a distinct fight within Apple right now but each distinct body part (BSD, Java, Mac UI, NeXT UI, Applescript, etc) seems to be melding into a new, cohesive whole.

An example, on Mac OS X hints I saw how to create a software airport bridge that turns on at logon. The fellow was a unix hacker and got stock libraries, recompiled them and tweaked until he was happy. I look at that and say, hmmm, why not just run a login applescript to do the same thing (even if the app is not normally scriptable, UI scripting is out and you can script just about anything now).

I suspect that a lot of the features that were marked missing in 10.0 are no longer missing at 10.2. I expect the list to grow shorter as time goes on and 10.3 etc are released. At the same time I expect that UI advances like the services menu will improve and provide an overall *better* experience than classic MACOS. So where are we? I agree that we're overall better but even the down side isn't as gloomy as you paint. Apple has to wow with new product as it backfills bringing over old classic OS features it couldn't get to in time for 10.0. This slows the process down but it's a temporary price for an astounding OS transition.

Re:How ironic...

[Anonymous Coward]

Wild guess here...

Nobody.

Re:Yeah Baby!

[Anonymous Coward]

Neither Gimp nor etherreal are Qt but GTK applications.

What's more exciting...

[dadragon]

Is that KDE's KOffice suite has been ported to Mac OS X using QT/Mac. That means we have a free, good looking, and relatively feature full office suite on the Macintosh, and KDE may get even more help with the suite from Mac developers.

On a side note, I've been waiting for a good C++ development library for Mac OS X. Cocoa is nice, but I'm not so good with Obj C yet, and QT may be just the thing I'm looking for. It'll work on Windows and Linux as well, so that's an added bonus. I'd also like to see Cocoa bindings for C++

Re:What's more exciting...

[Anonymous Coward]

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.

Re:What's more exciting...

[am 2k]

I'd also like to see Cocoa bindings for C++

That's technically not possible, because C++ doesn't support delegates or even object messaging (like in "calling a method using its name as a string").

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.

This unifies OSX with Linux/BSD/Solaris

[mnmn]

Trolltech is a high-potential company with a bright future. The QT toolkit is the best thing around for clean fast and portable progamming. Trolltech is right to push QT to permeate across the world to reap its profits; they deserve it.

QT has given Linux alot. KDE became so big that GNOME had to be created as a free alternative before QT/X11 became GPLed. Now the Apple port will not only help apple applications, they will help Linux applications giving them more weight. Theres suddenly another big reason to shift your entire software project to QT despite any costs.

My only gripe is the really high license cost for a student. Ive built several applications in win32 but cant use them afer the 30 days. They relied heavily on printing so I couldnt port them to Linux. I even offered developers with the license to compile them for me for a small fee. I hope Trolltech sees this and if they really want to hide their code from pirates, provide a compilation service at a much lower cost for projects with low earning potential or value. I dont mind being the Toronto office manager of compilation services at all. Will even code for food(hey its 2003, not 1998)

Apple and KDE

[ickoonite]

Of course it's quite clear what we will see - some kind of marrying of KDE and Apple like we've all vaguely been trying to do with Fink/OpenDarwin and X11. Unsurprising, seeing as there's been all that Apple contribution to KHTML over the past few months.

There will, of course, be X11 seamlessly integrated into the OS, and KDE apps will run, in beautiful native Aqua, just as any other Aqua app, with an icon in the dock (maybe blocky à la Classic, but still).

Geeks will of course adore it, and as professed by Apple's marketing for OS X, geeks are one of their target user bases.

It will be very interesting to see what happens to GTK now. I was just really starting to love some of GNOME's eye candy, but QT/Mac has the edge, I feel.

iqu

KOffice vs. MS Office v. X

[theolein]

I am just speculating here, but this does open a path of thought for me in that Apple might have encouraged this action by Trolltech (wider audience, more traction in corporations, more traction amongst consumers etc). Apple's use of KHTML in Safari may very well a sign of things to come in the other area where Apple has been dependant on Microsoft: Office.

Quite a few people wondered why Apple went with KHTML instead of Gecko in developing a new browser and I think the answer was proabably because of the companies involved - Trolltech is not AOL/Netscape -, and that KHTML is much more lightweight than geckko could ever be, thereby giving Apple the same ability to offer developers the same HTML rendering API on the Mac as MS has done with IE on Windows. Apple could very well be considering doing the same thing with KOffice.

KOffice is way behind OpenOffice in terms of maturity and features, but KHTML was also behind Gecko in terms of standards support until Apple developers started adding to it. I think Apple's developers would very well be capable of adding the features to KOffice that it lacked, including MS Office document support. They might do this in a manner similar to what they've done with KHTML and webcore: creating "Office" i.e. word processing, spreadsheet and presentation API's, giving these back to the community and creating a closed product ala Safari that would be based on them.

This is wild speculation, but many people have wondered why Apple has done almost nothing Appleworks since OSX entered the scene. I don't think it was only fear of MS cutting off Office for the Mac that prompted this.

Arg! Arg! Arg!

[TomorrowPlusX]

I've spent the last 4 months porting a fair amount (> 15 kloc) of qt code to std c++ on the backend (removing *all* qt, and writing my own classes that map to qt's classes where needed) and rewriting the gui in native cocoa/objective-c.

And now I discover it was completely unnecessary!

Arg! :P

( on the other hand, it's been a good experience. cocoa is a beautiful API, and rewriting the backend in pure c++/stl has actually improved it, since the stl is really, *really* quite good. )

Jammin'

[Fished]

This is great news. For some time now, I've been hungering for some kind of structured document editor that ran under OS X's GUI. Now it looks like I will be able to easily get two: KWord (not sure how structured it lets you be, but it's supposed to be like Framemaker in many respects) and LyX (which has a native QT personality of late.) I will now die happy.

One thing that bears thinking about, however, is whether this release will drive the world of free software to be more and more Mac driven, and at least somewhat less Linux driven. It's fairly apparent that Safari is the driving force behind KHTML now -- with this release, will OSX become the driving force behind other elements of KDE? What will this mean for Linux?

Re:Yeah Baby!

[muonzoo]

Now that's embarassing. Next time I'll engage brain before mouth. Nah, this is slashdot. :-)