I find this odd considering that Autodesk is not known (to me) for:
- making cheap products
- being so broke that they can't spend 1.2k$ on a developer for a toolkit they know saves them time (hence money)

P.S: Is it possible to type html in comments or no? Encoding gives me only plain text, but a little bit lower there's a list of valid html tags.

A couple of years/releases ago Autodesk started making a big deal of how they were shifting the customizable GUI of Autocad from thier textfile based DCL to MFC. Maybe they are starting to realize that MFC is a dead end with MS pushing .NET (and WinForms, its GUI framework), and are exploring alternatives that will also give them the cross-platform capability that, IMO, they foolishly abandoned in the rush to a Windows-only product. AutoCAD used to run on a few unices and its UI framework (Menus, Toolbars, Dialogs, Command Line, Status Bar) was, and I suppose still is to some extent, completely customizable by text files. QT would be a great complement to thier ObjectARX c++ programming interface.

I like the Troll's concept of proprietery/free double licensing under *nix. They need money to live.

But if I got it right, my GPLed Qt/*nix app cannot be compiled by others under Windoze/BeOS/MacX without paying fees. Is that right? If so, why this asymmetry? Isn't double licensing good for all platforms?

> But if I got it right, my GPLed Qt/*nix app
> cannot be compiled by others under
> Windoze/BeOS/MacX without paying fees. Is that
> right? If so, why this asymmetry? Isn't double

Yes, that's right. Well, if my memory serves me right, it's because of free software community on free Unix clones (btw, AFAIK Qt for proprietary Unixes is also not free) and because they use and like free software.

No, you didn't get it quite right. You can take the Free Qt/X11-version and port it to any platform you want (Windows, Mac, whatever), because it's licensed under QPL/GPL.
The "official" Windows and Mac ports that are made by Trolltech are not licensed under QPL/GPL, and you probably won't even get your hands on them without showing the money first.

Yes, but he has to port it. Which is more than just fixing few Makefiles and is probably the reason that KDE project for Win uses Cygwin (to make Windows look as much as Unix as possible) and why there's no free Qt edition for Windows.

You can get Qt licensed using the GPL, but anything you do with it must also be released under the GPL (good for students, not for companies). Under this someone could port Qt to Windows, but the Windows port would have to be under the GPL, and so any Windows programs using the port would have to be under the GPL

or

You can get Qt under their proprietary license, and then release your software under any license you feel like.

Looking at that Aqua QT Designer is almost scary; I keep thinking that it's a faked screenshot.

But, to a certain extent, all OSes seem to be going POSIX/*nix based, with even Windows vaguely heading in that direction. It would be very interesting if KDE/Qt became the "write once/run anywhere" environment that Java always promised to be. (Sure, there is a compile for each platform in there, but it's a painless one).

But there are things like the new administration system. Its hard to coordinate different linux distros but its harder to maintain complete different systems. You need _some_ developers, more discussions, more coordination...

Another point:
If you take a look at QT3 I see some danger:
With all the different ports and the new features it is not so interesting for the commercial programmers to write native KDE-apps but QT-only.
This is the point, where I say, ok TrollTech should use the QPL for _all_ systems, if the user wants to write free software. This would be KDEs chance to present this free desktop or some of its apps. But I *think* we are not strong enough for being such a big player. So lets face Unix and maybe embedded systems and stay community-based.

>> Looking at that Aqua QT Designer is almost scary; I keep thinking that it's a faked screenshot.

> It's real, it runs pretty fast and it magically uses the common Mac menubar.

Just in case anyone was wondering about my starry-eyed post above, I *don't* think the screenshots are fake (you can stop emailing me, especially the three Gnome trolls that wanted proof to "topple the joke" (?!?)), just that it was so impressive and integrated it looked like a concept shot... I wanted to jump in and play with the controls.

As for the rest, I never said it was a *good* idea to port KDE to every platform... and I'm not now saying it's a bad idea. It seems Qt is going everywhere, and it's something to mentally chew on; that's why I was wondering if any core developers had thought about it (since it's up to "those who do").

I had done a search several weeks ago looking for OSX in the devel mailing lists to see if anybody was thinking about a port. There was no mention in any of the lists I checked. And I will admit that part of it is because if I had the money right now, I'd snap up a Titanium PowerBook. Drool, drool. But I'd want to have Konqueror and a few other KDE apps for comfort factor (switching back and forth), while still running MacOS for the Video editing apps.

You wrote: "But I'd want to have Konqueror and a few other KDE apps for comfort factor (switching back and forth), while still running MacOS for the Video editing apps."

No disrespect to the excellent Konqueror, but why wouldn't you use OmniWeb 4.0 for browsing on Mac OS X - it is arguably the World's best browser in typography terms, the longest established (under development for 8 years, and predates Netscape)?
Will Shipley, the developer discusses it here:

You wrote: "But I'd want to have Konqueror and a few other KDE apps for comfort factor (switching back and forth), while still running MacOS for the Video editing apps."

No disrespect to the excellent Konqueror, but why wouldn't you use OmniWeb 4.0 for browsing on Mac OS X - it is arguably the World's best browser in typography terms, the longest established (under development for 8 years, and predates Netscape)?
Will Shipley, the developer discusses it here:

I was wondering how hard it would be to cut X dependencies out of KDE and port Qt to GGI using KGI drivers for hardware acceleration. ICE would be the biggest problem, as far as I can see, but it doesn't sound impossible.

Hasn't the Xfree86 4.X driver model been modularized (so that card makers can provide binary only drivers)? Would it be practical/advantageous to create a minimal layer between these drivers (source or no source) and a toolkit such as QT?

Yes, the architecture in XFree86 4 provides for loadable drivers that can be in binary form (this is how Matrox distributes their HAL drivers now). The idea though, for the KGI project, is to provide a clean interface to hardware drivers without being specific to a particular display implementation (like an X server). That would be adventageous to video-driver writers because their efforts could be used by an X server or SDL or Berlin etc...

I was thinking that a GGI port would be adventageous for Qt/KDE because of the _potential_ performance boost that would be brought about via KGI and hardware accelerations like BLT's and ROP's not to mention ease of access to alpha channels, true transparent term sessions, fade effects, anti-aliasing blah blah blah. Mind you that that KGI project is in alpha and, to my knowlege, has only one card supported ~:|

XRender with DRI is supposed to be offering all those features too but I find that there are a lot off people who still would like to se an X'less desktop (especially me after XFree hardlocks my stand alone box and I have to hammer the reset button and fcsk!).

One guy _has_ decided to build an operating system from the ground up. Furthermore, he has nearly finished! Check out AtheOS at www.atheos.cx. Only problem is QT is not available for AtheOS. Now that's a port I'd like to see.

I think that now Trolltech every major UNIX, Windows, Mac and Embedded covered, the next step is to develop a Qt port of AWT/SWING for Java. Once that is done, I think most bases are then covered.

I would like to express great thanks to all the guys and gals at Trolltech. They make a great product and work very hard for it. If it were not for Qt and Trolltech I would not have learned so much about GUI coding, and it has been a real education for to learn about Qt and how to code a GUI app. One thing that many people seem to forget is that not only are you getting a great piece of software with Qt, but you are getting a great opportunity to educate yourself and learn a lot. This combined with the general goodwill of the developers makes Trolltech a very approachable company.

I hope that with all the fininacial difficulties that are being experienced by Linux distros and companies, that they keep afloat. I am particularly keen on Trolltech, theKompany and Mandrake to succeed. Keep up the good work, and thanks a lot. :-)

---------->
If it were not for Qt and Trolltech I would not have learned so much about GUI coding, and it has been a real education for to learn about Qt and how to code a GUI app. One thing that many people seem to forget is that not only are you getting a great piece of software with Qt, but you are getting a great opportunity to educate yourself and learn a lot.
<----------

Throw in a mention of KDevelop and you have my experience exactly. I knew how to write Hello World and how to read other people's code but it was the Qt/KDE libraries, tools and documentation that enabled me to step out on my own.

Hi, I would be interested if someone had a copy of one of those cease and desist letters they could send me or e-mail me, so I could check out what exactly it is that Apple are asking people not to do.

Historically, Apple's lawyers have had no problem with you emulating the Mac look-and-feel on the macintosh, but they'll send cease-and-desists if you make Mac look-and-feel available on platforms other than Mac. That was the case back when I worked for Visix, yet another cross-platform gui toolkit company. (see e.g. http://www.byte.com/art/9507/sec9/art8.htm). Visix kept tighter control over its source code, though, so a compile time NO_MAC_LAF flag meant something. It will be interesting to see how trolltech handles this.

I was a Mac OS 9 user. I heard of some $130 product called Mac OS X, but I decided to get Linux instead, because the LinuxPPC distribution was $20 and I didn't have to wait for March 24. Now I use KDE. (I could have chosen GNOME, but it didn't look as pretty, and I don't have an orange iMac for no reason...)

Anyway, I know most Mac OS X programs use an API called Carbon. So I would guess that Qt for Mac was also Carbon. Carbon programs work in Mac OS 8.6 and later, too, so Qt for Mac would also work in Mac OS 9 (and probably 8.6).

If it wasn't Carbon, it would have to be either something called Classic or Cocoa. Classic is the old API for writing a program in old versions of Mac OS. If Qt for Mac was Classic, it would work in OS 9 and OS X (but it the OS X Classic emulator). Classic doesn't do protected memory, and since the Classic and Carbon APIs are so similar, it makes since to use Carbon.

Cocoa is a so called "object oriented" environment. I thing this has something to do with OpenStep (I remember that Apple acquired NeXT) and the Cocoa API is so different from the Classic or Carbon ones. Cocoa programs don't work in OS 9, so if Qt for Mac was Cocoa, it wouldn't work in OS 9.

Bottom line: most Mac programs in OS X work in OS 9, so Qt would probably work too (my guess).

I think that the worst part about OS X is its $130 price tag (OS 9 was less than $100) and also that it is a very different OS from OS 9.

I have a Mac and based on my discussions with others in this arena it will be some time before there is a critical mass of people using MacOS X. It still really isn't done, they are releasing updates almost weekly. I'm very excited to hear that Qt 3 works with OS 9 and X, but I'm wondering what wizardry you used. Is it native for both or are you using the emulation layers?

To what extent does the KDE code rely on X11? I think it'd be wise to start taking out the X11 specific code from the core (Maybe this is already done? I haven't checked the code all that carefully; but if it was, I figure we'd have KDE for fbdev now) and put a layer between KDE and the display (manager).

We have a good start with QT. Even if we're not interested in porting KDE to other operating systems, we are, with any luck, going to get a better system to replace X sometime in the future. Better get ready for it!

I believe there is barely any X dependence in KDE, so they are in good shape. The desktop, window manager, and ICE are probably all that would need to be changed (IMO they should do something about ICE now though).

The reason you don't see an fbdev KDE is because Qt/Embedded doesn't support X applications, and I don't think it supports a custom window manager either (can anyone correct me?)

Here's a thought: What if someone wrote an X server for Qt/Embedded? Kinda like those win32 X servers. Find a way to use a custom window manager in Qt/Embedded and port Kwin. That might be pretty cool.