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

110 comments

  1. Not only is it good for Apple by dbrutus · · Score: 5, Insightful

    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.

    1. Re:Not only is it good for Apple by gnuadam · · Score: 2, Insightful

      Good point, except that the ui for the mac and for linux are likely to still be a bit different. Things like the "master" menu bar, and the dock are unique to mac, and so the version a mac user uses will likely still be different than the x version...

      That said, things can only get better...

      --
      You say :wq, I say ZZ. Why can't we all just get along?
    2. Re:Not only is it good for Apple by Anonymous Coward · · Score: 1, Informative

      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.

    3. Re:Not only is it good for Apple by gnuadam · · Score: 3, Interesting

      ...and in apple, there are designated places where one expects to find things like "Quit", and "Preferences", that are likely different on other platforms. I think apple did this on purpose, but it makes writing cross-platorm gui apps annoying because the mac version will always be a bit different. I mean you might get around it with compiler directives, or something like that, but it has to be considered.

      --
      You say :wq, I say ZZ. Why can't we all just get along?
    4. Re:Not only is it good for Apple by mccoma · · Score: 5, Interesting
      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.

    5. Re:Not only is it good for Apple by Anonymous Coward · · Score: 5, Insightful

      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?

    6. Re:Not only is it good for Apple by Anonymous Coward · · Score: 5, Informative

      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?

    7. Re:Not only is it good for Apple by rebeka+thomas · · Score: 2, Interesting

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

      It hasn't been missing, it's just been something Mac users wanted. Yes in that sense Open Source is missing a lot, but that is part of its advantage. When it is missing something and people want it, it gets written.

      However I will admit that it is exciting to see how things pan out when a creative Mac user brings a native GIMP port to the Mac. The lack of a Mac interface (whatever that is really meant to mean) by design stalwarts has been a sticking point for them to delay adoption of GIMP over other packages. Once that problem is solved there's nothing holding them back. The best of the worlds design community suddenly using an OSS package? You'll know we've come along way when that happens.

      Wonder if they'll imagine up another reason to stick with their proprietary hackjob fixes after that.

      --
      RST
    8. Re:Not only is it good for Apple by dbrutus · · Score: 2, Interesting

      MacGIMP was in development before this announcement.

      The mac community is the art critic of the computer world. It's not that something is not written and so you supply the service. It doesn't work that way. The OSS community is about having an itch and then scratching it. The mac community is about scratching it *in the right way* so that it's done quickly, efficiently, and with the minimum possibility of infection. It doesn't change your feature set so much as change every implementation of the feature set to match human interface guidelines and to elevate HIG to the equivalent importance to functioning code.

    9. Re:Not only is it good for Apple by dbrutus · · Score: 1

      Do you have a Mac/QT license? Have you looked at it to determine what it can and can't provide? I'd give the Trolltech people a little credit and give their product a whirl before you knock it as hopelessly inadequate. And if you're right, they're likely to hear from mac programmers soon enough so they can correct their errors.

    10. Re:Not only is it good for Apple by dbrutus · · Score: 3, Informative

      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.

    11. Re:Not only is it good for Apple by squiggleslash · · Score: 1

      Interestingly, Apple themselves have moved Quit and Preferences with the release of OS X, which means that Classic apps show them in a different place to native apps.

      --
      You are not alone. This is not normal. None of this is normal.
    12. Re:Not only is it good for Apple by mbbac · · Score: 1

      Apple didn't do it on purpose. Apple did it first. Everyone else based their operating system on the Mac OS with their own changes some of them to try to lock in users to their platform, some of them because they thought they were better.

      --

      mbbac

    13. Re:Not only is it good for Apple by Anonymous Coward · · Score: 0

      Have you looked at it to determine what it can and can't provide?

      It's can't provide NSUserDefaults. That's only available in Objective C and Java, and QT is C++.

      The point is that if you use QT to write a Mac application, you're going to either (1) create a pretty crappy application that doesn't take advantage of ANY of the Mac OS X core technologies, or (2) spend a ton of time and effort making your QT code talk to your Mac-only Objective C code.

      QT on the Mac is the wrong answer. Cocoa/Gnustep/Yellow Box/whatever you want to call it on Windows and UNIX is the right answer.

    14. Re:Not only is it good for Apple by dpbsmith · · Score: 1

      True... and what a pity that Apple threw away so many babies with the bathwater in OS X.

      Not that OS X is terrible, but the UI is NOT as good as OS 7 through 9... for no obvious reason. (I suspect internal rivalry between traditional Apple factions and NeXT factions).

      The OS X finder feels clunky, and very much as if was designed by someone working from a marketing features list, someone who didn't really grok the traditional Mac user experience.

      Candy-colored buttons on the window that give you clue, other than their color, as to what they do until you mouse over them... finder windows that no longer automatically update to reflect real-time changes in directory contents... don't get me started.

      It's water over the dam now, but it is still painful to those of us have known the Mac since 1984.

      Oh well, it's still good for UNIX-based OS. And, yes, I do prefer working in OS X because the "real OS" virtues do, overall, outweigh the "not-quite-a-Mac" UI.

    15. Re:Not only is it good for Apple by dbrutus · · Score: 4, Insightful

      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.

    16. Re:Not only is it good for Apple by dbrutus · · Score: 4, Insightful

      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.

    17. Re:Not only is it good for Apple by Anonymous Coward · · Score: 0

      if by first you mean were the first to steal the concept (from xerox) then of course you're correct.

    18. Re:Not only is it good for Apple by mbbac · · Score: 1

      They bought the concept from Xerox. Microsoft didn't. Apple was the first to bring it to market.

      --

      mbbac

  2. How ironic... by RalphBNumbers · · Score: 3, Interesting

    Who else finds it amusing that both the 1.0 version of Safari (Apple's port of Konquerer, to oversimplify a bit), and the GPLed Qt (a framework to let you run plain old Konquerer on OSX with aqua widgets), are both likely going to be released at the same conference by different companies?

    --
    "The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
    1. Re:How ironic... by Anonymous Coward · · Score: 5, Funny
      Wild guess here...

      Nobody.

    2. Re:How ironic... by Anonymous Coward · · Score: 0

      Whats wild about it? Things are moving for Apple.

      Safari 1.0(I won't go IE again).
      QT libs(mainly developer)
      Power970 in production(yea right)
      me as a customer(17" baby!)

    3. Re:How ironic... by IamTheRealMike · · Score: 1
      It's more amusing when you consider the size of KWQ, Apples mini-clone of Qt they wrote to port Konqueror.

      Still, they clearly didn't want to license Qt itself for whatever reason, and they don't want to make Safari free software, again for no real apparant reason, so this release of Qt means little for Safari anyway.

    4. Re:How ironic... by minus_273 · · Score: 1

      umm.. safari is free...i didntpay for it. Im not sure i know anyone who has

      --
      The war with islam is a war on the beast
      The war on terror is a war for peace
  3. The reql question is... by Anonymous Coward · · Score: 1, Interesting

    how big of a footprint does QT have on a machine and how long will it take to compile...

    Sorry... I have flashbacks of compling QT and had to come back the next day. That thing takes forever to compile.

    On a positive note, any sort of cross-platform libs are most definitely a plus. Maybe this will be a sign to other projects of mac support(native gtk for my lil Mac:-) I really hate loading up X11... especially since my problem with linux was X.

  4. Yeah Baby! by muonzoo · · Score: 3, Interesting

    This truly is wonderful news! There are a large number of client applications that use Qt for display rendering that really aren't fundamentally X11 applications.

    Several of these applications are used daily by our engineering team.

    Having a native (or at least X11-free) version of these tools is a real bonus for us; but in particular, it's a bonus for the less sophisticated users that would benefit from using applications as though they were OS/X native applications.

    Think about CEO or tech support people who don't (won't) want to run X11 just in order to look at that packet trace or 'jiggle that SNMP MIB'.

    I, for one, look forward to this, and will happily help port a few key applications to the Darwin / OS X platform.

    This, and portage all in one week! Good News For All!

    1. Re:Yeah Baby! by Anonymous Coward · · Score: 5, Informative

      Neither Gimp nor etherreal are Qt but GTK applications.

    2. Re:Yeah Baby! by hobbit · · Score: 1

      A little birdie told me that actually, GIMP uses the GIMP Tool Kit.

      --
      "Wise men talk because they have something to say; fools, because they have to say something" - Plato
    3. Re:Yeah Baby! by muonzoo · · Score: 4, Funny

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

    4. Re:Yeah Baby! by tsnorri · · Score: 2, Informative

      There is, however, a port of GTK for OS X at http://gtk-osx.sourceforge.net/

    5. Re:Yeah Baby! by IamTheRealMike · · Score: 1

      Unfortunately that's a port of GTK1, which has been obsoleted and is rapidly being phased out on Linux. The next stable release of the GIMP, which should be happening in the next few months, will eliminate one of the last remaining major GTK1 apps (with xmms being the other one).

  5. What's more exciting... by dadragon · · Score: 4, Interesting

    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++

    --
    God save our Queen, and Heaven bless The Maple Leaf Forever!
    1. Re:What's more exciting... by Anonymous Coward · · Score: 5, Informative

      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.

    2. Re:What's more exciting... by dadragon · · Score: 1

      When I say I'm not so good with Obj C, I mean I'm not so good with Cocoa, and also not very good with Obj C's inheritence and object declarations. The methods are easy enough, and I've made one or two Cocoa wrappers around apps that I'd already written to update a blog using PostgreSQL on a remote server.

      I'm still learning the Cocoa standard library for Mac OS X.

      --
      God save our Queen, and Heaven bless The Maple Leaf Forever!
    3. Re:What's more exciting... by am+2k · · Score: 5, Informative
      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.

    4. Re:What's more exciting... by Anonymous Coward · · Score: 0
      Cocoa is very much like the original java libraries (no suprise since java was influenced by objectice C and OpenStep).


      Apple has pretty good documentation on their web site for all the classes.


      I find the foundation kit does everything the C++ STL does, but in a more intuitive way.

    5. Re:What's more exciting... by TheRaven64 · · Score: 2, Funny
      I find the foundation kit does everything the C++ STL does, but in a more intuitive way.

      You make it sound like being more intuitive than STL is difficult...

      --
      I am TheRaven on Soylent News
    6. Re:What's more exciting... by Anonymous Coward · · Score: 0

      What is it that you can do exactly with Objective-C that you can't do in C++???????

      OOP speaking.

    7. Re:What's more exciting... by Anonymous Coward · · Score: 1, Informative

      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.

    8. Re:What's more exciting... by Jeremy+Erwin · · Score: 1

      Of course, you do realize that any language that uses "slot:" and "signal:" directives isn't C++.

      The C++ standard is big. Really big. I'm sure that had Qt's engineers thought about the problem, they would have been able to use templates in new and interesting ways to get the same effect.

    9. Re:What's more exciting... by Jeremy+Erwin · · Score: 1

      Objective C introduces the type "id" which allows you to send messages between objects without the sender object much caring about the type of recipient object.

    10. Re:What's more exciting... by Anonymous Coward · · Score: 0

      Sorry. If you want an answer to that question, you're going to have to put *eight* question marks in a row. Seven just won't cut it.

    11. Re:What's more exciting... by am+2k · · Score: 2, Informative

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

    12. Re:What's more exciting... by Anonymous Coward · · Score: 1, Insightful

      You can send messages similarly in raw C++ using libsigc.

      A better criticism would have been that ObjC supports dynamic dispatch which in a liberal sense allows run time introspection, manipulation and use of methods an object provides. Java provides the same power with the reflection API. And dynamic dispatch is something dylan advocates like to brag about.

      Raw C++ doesn't provide dynamic dispatch capabilites, and neither does libsig being C++ based. But Qt use the meta object compiler (moc) and Q_OBJECT to extend C++ adding dynamic dispatch capabilities such as runtime introspection of 'properties'.

      This is useful for doing things like taking an xml user interface file and creating a dialog (ala QWidgetFactory::create). ObjC does something similar with .nib files.

      There are some techniques ObjC provides that Qt/C++ do not, such as runtime manipulation of an objects class hierarchy, but these generally aren't useful and aren't discussed much.

    13. Re:What's more exciting... by Anonymous Coward · · Score: 0
      With all due respect, that code doesn't look more or less readable than C. Actually, those long hard-to-memorise function names vs the short, sweet Unix equivalents -- I mean WTF is a:
      NSFileHandleConnectionAcceptedNotification
      when it's at home? -- makes it look more like Win32 API programming.

      I know C and Smalltalk, so I'm not complaining about the syntax btw. My idea of "easy" would be something like:

      [[[NSServer alloc] bindToPort: 80] acceptConnection]]
      Your version just looks like the same old C calls.
    14. Re:What's more exciting... by IamTheRealMike · · Score: 1
      For comparison, here is the equivalent code in C using glib/gnet (which could be compared to a lower level version of the networking parts of cocoa).

      GTcpSocket *sock;
      sock = gnet_tcp_socket_server_new_with_port(A_PORT);

      v oid incoming(GTcpSocket *server, GTcpSocket *client, gpointer userdata) {
      /* do something here */
      }

      gnet_tcp_socket_server_accept_async(sock, &incoming, NULL);

      Note that this will use SOCKS if available, and integrate with your main loop.

      Personally, I find the C version far more readable, though obviously familiarity plays a part in that. I also defined a handler for incoming connections, which I can't see in the ObjC example.

    15. Re:What's more exciting... by Anonymous Coward · · Score: 0

      So the question really is: C++ does not provide these thins because they can be implemented by the programmer, right?

      So they are doable.

    16. Re:What's more exciting... by Anonymous Coward · · Score: 0

      Man, you guys are dumbasses. You're sitting here arguing about the relative capabilites of programming languages! Ladies, they're both Turing-complete, okay? You can do anything with either of them.

      The correct answer is that it is not possible to call the Cocoa frameworks from C++. Cocoa is available only through Objective C and Java interfaces.

      Now cut it out.

    17. Re:What's more exciting... by Anonymous Coward · · Score: 0

      I also defined a handler for incoming connections, which I can't see in the ObjC example.[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(acceptConnection:) name:NSFileHandleConnectionAcceptedNotification object:nil];

      Notifications are more powerful than callbacks. Try invoking a callback on another machine across a network connection.

      Besides, glib/gnet is C, and is therefore procedural instead of object-oriented, making it simply unsuitable for serious programming projects.

    18. Re:What's more exciting... by Anonymous Coward · · Score: 0

      I also defined a handler for incoming connections, which I can't see in the ObjC example.

      [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(acceptConnection:) name:NSFileHandleConnectionAcceptedNotification object:nil];

      Notifications are more powerful than callbacks. Try invoking a callback on another machine across a network connection.

      Besides, glib/gnet is C, and is therefore procedural instead of object-oriented, making it simply unsuitable for serious programming projects.

    19. Re:What's more exciting... by Anonymous Coward · · Score: 0

      I mean WTF is a NSFileHandleConnectionAcceptedNotification when it's at home?

      Urr? Are you an idiot? An NSFileHandleConnectionAcceptedNotification is a notification that a connection has been accepted by an NSFileHandle. Duh.

      Actually, those long hard-to-memorise function names vs the short, sweet Unix equivalents

      Yes. Yes, you are an idiot.

      My idea of "easy" would be something like

      That's because you're an idiot.

    20. Re:What's more exciting... by IamTheRealMike · · Score: 1
      Uh, you define "serious programing project" as something that invokes callbacks across network boundaries? So the Linux kernel isn't serious? Gnome isn't serious? Windows isn't serious?

      Object remoting is rarely used. And you can obviously do that as well if you like using sunrpc or CORBA.

    21. Re:What's more exciting... by Anonymous Coward · · Score: 0

      So the Linux kernel isn't serious?

      Well, since you mentioned it...

      Gnome isn't serious?

      Gnome is the ultimate waste of time.

      Windows isn't serious?

      It tries to be and fails.

      Object remoting is rarely used.

      That's because interfaces for doing it have historically sucked. But combine Distributed Objects with Rendezvous and you've got instant ad hoc distributed computing. No user intervention required, and the programming tasks are trivial.

      And you can obviously do that as well if you like using sunrpc or CORBA.

      The reason hardly anybody uses RPC or CORBA is because they suck. Rendezvous/DO does not suck. Which is why it's becoming more and more widely used every day. Hell, there are Rendezvous/DO *text editors* now. Check out Hydra.

    22. Re:What's more exciting... by printman · · Score: 1
      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.
      That's exactly what FLTK does, BTW, and it is already more free than Qt (LGPL) and runs on multiple platforms.
      --
      I print, therefore I am.
    23. Re:What's more exciting... by SeanAhern · · Score: 1

      it is not possible to call the Cocoa frameworks from C++. Cocoa is available only through Objective C and Java interfaces.

      What about the Objective C++ compiler? I thought the whole idea was that you could make Cocoa calls (written in Objective C) from inside your C++ objects.

  6. This unifies OSX with Linux/BSD/Solaris by mnmn · · Score: 4, Interesting

    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)

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    1. Re:This unifies OSX with Linux/BSD/Solaris by baywulf · · Score: 2, Informative

      Why not this version?

      http://www.trolltech.com/download/qt/noncomm.htm l

    2. Re:This unifies OSX with Linux/BSD/Solaris by gi-tux · · Score: 3, Interesting

      Because it is version 2.30 and doesn't support so many of the things that would be nice. I was looking at doing a project that I wanted to do as OSS and use QT for it so that it would work on Linux and Windows. However, I needed database access into grids, etc. Great QT 3.x supports that with no problem. Ooops, only QT 2.3 for Windows.

      I sent TrollTech an email asking if the 3.x version of QT was going to be released for Non-Commercial use. The answer was basically no as that is how we make our money and we can't kill the goose that is laying the golden egg.

      Now that begs the question of will the shutdown non-commercial for Linux if it becomes a big player on the desktop? I know that they say that they won't do that, but they were big into the non-commercial license for MS-Windows when it released.

      --
      I have no sig, does anyone have one to spare?
    3. Re:This unifies OSX with Linux/BSD/Solaris by TomorrowPlusX · · Score: 1

      It doesn't matter -- the source is open. If -- and I doubt it -- *if* trolltech shuts down the non-commercial version for X11 people have the right to fork and maintain any previous open version on their own.

      And, obviously, if it comes to it they will.

      --

      lorem ipsum, dolor sit amet
    4. Re:This unifies OSX with Linux/BSD/Solaris by Anonymous Coward · · Score: 0
      So, what you're saying is, "I really think TrollTech deserve to make a lot of money.. even while I'm here without a job and adequate funds for survival."

      You pro-"free"-market masochists really confuse me sometimes. Especially when you're considering a company which has made a lot of profit via the popularity of projects created by volunteers.

  7. Qt apps don't BEHAVE like Mac apps! by anarkhos · · Score: 1, Funny

    Qt apps on OS X behave exactly the same as Qt apps on any other platform. They behave like Win3.1 apps.

    --
    >80 column hard wrapped e-mail is not a sign of intelligent
    >life
  8. Re:does that mean by andy666 · · Score: 3, Funny

    i guess that answers my question...how ironic.

  9. Apple and KDE by ickoonite · · Score: 4, Interesting

    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

    1. Re:Apple and KDE by dadragon · · Score: 3, Insightful

      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.

      GTK > QT for commercial development. The reason is cost. GTK is LGPL, so you can link commercial stuff to it without a problem. QT is GPL, so you need to get a licence to use it commercially.

      The Mac is a very commercial oriented platform, just like windows, so commercial development may well decide GTK is the way to go.

      --
      God save our Queen, and Heaven bless The Maple Leaf Forever!
    2. Re:Apple and KDE by Nicolay77 · · Score: 1

      Don't forget the wxWindows license:
      It's like lgpl but it puts absolutely no restrictions on redistribution of binaries, commercially or otherwise.

      That's even more free.

      --
      We are Turing O-Machines. The Oracle is out there.
    3. Re:Apple and KDE by printman · · Score: 1

      FLTK provides these benefits as well, is C++ based, and it smaller too!

      --
      I print, therefore I am.
  10. KOffice vs. MS Office v. X by theolein · · Score: 5, Insightful

    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.

    1. Re:KOffice vs. MS Office v. X by Anonymous Coward · · Score: 0
      Nice troll, (currently has a +4 score). However, someone might believe you, so I had best set the record straight
      • KHTML was written by the KDE team, not TrollTech (K* = KDE, Q* = Quicktime [trolltech])
      • Apple hasn't done bery much work on KHTML. They haven't needed to.
      • AppleWorks is a piece of shit. They haven't done anything with OS 8 either.
    2. Re:KOffice vs. MS Office v. X by theolein · · Score: 1

      Uhm, Quicktime is Apple's baby. I think you're mistaking QT with Qt (small t and big T). Trolltech's toolkit is Qt.

      KHTML was not written by Trolltech but is dependant on the Qt toolkit.

    3. Re:KOffice vs. MS Office v. X by bsharitt · · Score: 2, Insightful

      Even if Apple doesn't officially endorse KOffice, just having it there is a big help in itself.

    4. Re:KOffice vs. MS Office v. X by Anonymous Coward · · Score: 0

      I got news for you...KHTML is still far behind Gecko in terms of compatibility.

      It's behind, sure, but not far behind. But does it really matter? It's better than IE/Mac, and that's what most people have been using. What's important from Apple's perspective is that it was easy to port, easy to make a component (Gecko, dispite claims to the contrary, is NOT easy), and 'good enough' in all other areas.

    5. Re:KOffice vs. MS Office v. X by Anonymous Coward · · Score: 0

      Uh, check the guy's posting history. Nary a troll in sight. ACs on the other hand...

      As for your points, you're totally fucked in the head.

      # KHTML still depends on Qt.
      # Apple gave a hell of a lot back to the KHTML people.
      # AppleWorks is shit, the parent poster didn't say otherwise. Who the fuck are you disagreeing with?

  11. Arg! Arg! Arg! by TomorrowPlusX · · Score: 5, Funny

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

    --

    lorem ipsum, dolor sit amet
    1. Re:Arg! Arg! Arg! by Anonymous Coward · · Score: 2, Funny

      after all that and we don't get a link to your project! :)

  12. Jammin' by Fished · · Score: 4, Interesting
    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?

    --
    "He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
    1. Re:Jammin' by IamTheRealMike · · Score: 1
      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.

      The vast majority of free software is written on Linux and then ported to other platforms. If you think being able to run KDE/Qt on a Mac will change this, then I'd point you towards the presence of KDE on Windows - how many new developers did that bring to KDE? AFAIK none.

      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?

      Unlikely. Apple aren't working on KDE for one. Secondly, I doubt many people will use KDE itself, rather perhaps they will use a few of its apps. But then again, perhaps not. I know many people (and I am included in that) who don't use any KDE apps at all on Linux. No real bias or anything, it just so happens that the apps we use on a daily basis aren't based on Qt.

      In short, it will mean about as much for Linux as any other port of software to other platforms will - basically jack all.

  13. Can anyone tell me... by Durin_Deathless · · Score: 1

    Can anyone tell me if this is over the top of Cocoa, so yo get the Cocoa services and the like for no extra code?

    --
    You should use AdiumX on your Mac.
    1. Re:Can anyone tell me... by Fished · · Score: 2, Informative

      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
  14. I could be wrong ... by Fished · · Score: 1

    I could be wrong, but wasn't StarOffice at one point based on Qt? Could this be used to speed up the openoffice port? (This is such a wimpy question that I'm foregoing my +1 for it.)

    --
    "He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
  15. nothing about kde *looks good* by Anonymous Coward · · Score: 0

    it is heinous kluttered krap

  16. Now I get it ! by MarkCollette · · Score: 2, Interesting

    All along we've been hearing all these _rumors_ about the WWDC being so big because of the 970, but now we know the _truth_, which is that Qt/Mac will be released under the GPL. Now I'm going to get my plane tickets ASAP!

    I assume that OS X 1.3 will now be released under the GPL as well.

  17. KOffice by pkretek · · Score: 1

    So guys I want to see a ported KOffice binary by Friday 27th! 5 Days should be good enough for everyone.

    I hope it will be as fast as it is on KDE... Who will want to have mac OpenOffice when you can have koffice? I do not really want to wait 5 mins for OpenOffice to launch. and it is soo ugly...

    1. Re:KOffice by Anonymous Coward · · Score: 0
      For the moment I'm afraid I'd have to recommend coughing up $100 for the MS Office for Mac student license. It'll have paid for itself by the end of the week in time not-lost through incomplete/unimplemented features.

      Although, having said that, koffice is showing lots more promise than BloapenOffice. Like Mozilla, OO appears to be driven by a team of extremely enthusiastic geeks with extremely fast machines who like to layer abstraction after abstraction, and who forget that some people just need something that works, and quickly.

      I'm damn happy Apple chose the khtml engine.

  18. It can't provide NSUserDefaults... by Millennium · · Score: 1

    ...however, it can provide CFUserDefaults, which are basically the same thing (NSUserDefaults actually layers on top of CFUserDefaults now). So that's a wash.

    Cocoa is being reimplemented on top of Carbon; the work began in Jaguar, and while it probably won't be quite finished in Panther, it should be a lot closer. I see this as a Good Thing, because it gives them the opportunity to add Carbon's greater variety of controls to Cocoa, while forcing them to patch the gaping OS-integration holes currently in Carbon. Everybody wins.

    1. Re:It can't provide NSUserDefaults... by Anonymous Coward · · Score: 0

      Cocoa is being reimplemented on top of Carbon

      What?

      That's completely, utterly wrong.

      Cocoa is built on top of CoreFoundation, which is a toll-free (i.e., binary identical across languages and architectures) bridge between Cocoa and Carbon. Neither one is implemented on top of the other. Both are implemented (mostly) on top of CoreFoundation.

    2. Re:It can't provide NSUserDefaults... by bsartist · · Score: 1

      Cocoa is being reimplemented on top of Carbon

      Untrue. Both Cocoa and Carbon are built "on top" of a layer called "Core Foundation" - that's the "CF" in CFUserDefaults, CFString, CFDictionary, and many other low-level constructs.

      --
      Lost: Sig, white with black letters. No collar. Reward if found!
  19. totally free.. by Suppafly · · Score: 1

    I wonder how long it'll be until trolltech gpl's the windows version and finishes the conversion from proprietory to opensource.

  20. IS trolltech IP still owned by SCO? by goombah99 · · Score: 2, Insightful
    at one point, recently, SCO owned trolltech. they wrote off the organization but did they write off the IP? Might want to think about that before using Qt

    see this article in Forbes. They point out that SCO's parent comapny has twice before bought small compaines (e.g. SCO) then sued larger ones for the IP. For example they sued Microsoft and won. They sued another company that settled. Now they are suing IBM and will probably win even if no one in the linux world can beleive it. They owned troll tech: the SCO kiss of death of IP legitimacy.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:IS trolltech IP still owned by SCO? by Anonymous Coward · · Score: 0

      *clue* The parent post is bullshit, SCO has never owned Trolltech. */clue*

  21. "KOffice suite has been ported" by Anonymous Coward · · Score: 0

    "KOffice suite has been ported"... where? Want to have it NOW! PRONTO! QUICK! SCHNELL!

    a.c.

    lol.

  22. Re:I dunno about you guys... by Anonymous Coward · · Score: 0

    U are teh scary. I must change my underwear. Twice.

  23. Still true... by Millennium · · Score: 2, Interesting

    Untrue. Both Cocoa and Carbon are built "on top" of a layer called "Core Foundation" - that's the "CF" in CFUserDefaults, CFString, CFDictionary, and many other low-level constructs.

    That is true. But CoreFoundation only goes so far; there are still certain things, such as most UI controls, which are still implemented using two totally different codebases for Cocoa and Carbon. Apple is working on unifying these; that is what I meant when I said that Cocoa is being reimplemented on top of Carbon. In the process they're cleaning up much of the Carbon stuff too; they have to, in order to make sure that Cocoa still works as before.

    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. Jaguar's Cocoa implementation of things like NSButton now layer on top of Carbon's HIView.

    1. Re:Still true... by Anonymous Coward · · Score: 1, Informative

      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.

  24. SCO DOES OWN TROLL TECH! by Anonymous Coward · · Score: 0
    Quotiing from the forbes article:

    Caldera bought shares in two other Canopy companies, Troll Tech and Lineo, and later wrote off the Troll Tech investment but sold the Lineo shares at a profit, according to SEC filings. In 1999, Caldera sold its own shares to MTI, then bought those shares back last year, according to SEC filings.

  25. Observe the word 'Besides'. by Anonymous Coward · · Score: 0


    We meant that quite apart from notifications being better than callbacks, object-oriented languages are better than procedural for serious programming projects.

  26. Dear Father O'Gay: by Anonymous Coward · · Score: 0

    Dear Father O'Day:
    Thanks for your letter. Being Catholic myself, I know exactly what you're talking about! It has always been our plan here at Apple Computer Inc to revolutionize personal computing with our high-quality and highly gay products.

    I'm happy to answer your letter by letting you know that YES we will be releasing an entire hLife ("homo-life") software line. You'll be able to recognize it in stores by the small stylized logo depicting a large cock entering a tight anus with an Apple logo on it. ("Suddenly it all comes together" indeed!).

    Anyway, I hope you and other members of our community will join us on our mission, and purchase the exciting new hLife boxed set. Only the boxed set comes with translucent cock rings!

    Sincerely,

    Harry Rodman
    Vice-president
    Homosexual Liaison Services
    Apple Computer, Inc.

  27. Only on Slashdot... by hobbit · · Score: 1

    ...would such a comment as the parent of this be modded "interesting"!

    --
    "Wise men talk because they have something to say; fools, because they have to say something" - Plato
  28. Re:I dunno about you guys... by Anonymous Coward · · Score: 0

    Hey dipshit, that "OSS crap" is already on your iBook. You're running OS X like a good zealot, aren't you?

  29. Use wxWindows !!! by Nicolay77 · · Score: 1

    If you want to use a multiplatform library that works superb in windows and makes standard C++ (without moc extensions) shine that's is.

    Qt may be good, but is native only in Linux, and in windows wx is way better (you have the source, it's not dual-licensed like qt).

    And the socket based server is a childs play in wxWindows too (event driven sockets). See the sockets sample.

    --
    We are Turing O-Machines. The Oracle is out there.