Slashdot Mirror

>> You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html [trolltech.com]

Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:

Wrong in what way? Forgive me, if my comment was not as clear as it should have been, but I am not wrong in this case. The point was, that this problem is still there, as detailed in the mailing list posting, if you don't use Q_SIGNAL, because you doubted the correctness of the mailing list posting. The point was not that it was added in 4.4 and not previously. You said that it was added in 4.1 and I am in no position to doubt that.

http://www.qtsoftware.com/developer/changes/changes-4.1.0

>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.

I never said, that the problem is not solved. You told me so in your previous post and I don't doubt it. I don't care about the timing either. I just pointed out, that 4 years is a heck of long time to fix such a problem.

>> Never missed this feature

Ah yes,the old "I don't use this feature therefore it's useless".

Yeah, a really good answer. It there any better reason to use this? I won't use it just because it is there. I am sorry, but I will not continue this discussion. This is slowly degenerating into a flamewar and I do not see any benefit for either of us if this continues. Have a nice evening.

>> You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html [trolltech.com]

Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:

http://www.qtsoftware.com/developer/changes/changes-4.1.0

>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.

>> Never missed this feature

Ah yes,the old "I don't use this feature therefore it's useless".

According to Alexandra from this blog post, it does include Qt Solutions code. This is also good news!

>> Does it use templates - no

Sure it does, all the collection classes are templated.

Sorry, my fault, I was not precise enough. Having only templated collection classes is hardly something to be proud of.

>> Does it use standard collections & iterators - no

True, although I like the api of the Qt collections much better than the std ones.

ok, personal choice.

>> The standard C++ string?

The standard C++ string class is horrible for GUI applications. It just sucks. No convenience functions, no unicode. Blah. Thank god for QString.

>> you cannot even construct a QString from a std::string without using c-strings

Sure you can: QString QString::fromStdString ( const std::string & str )

Ok, my bad, I only check the Constructors. What you say about UTF-8,.. is also true, since also GTKmm uses a different string class.

>> Qt hardly uses any exceptions

This one is true. I agree that in certain situations Qt should definitely add some exception support.

>>It is still featured in the wikipedia entry about QT, and therefore still seems to be valid.

Haha. Wikipedia says it so it must be true :)

You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html

>> And it seems to have appeared in QT 4.4 (please correct me if I am wrong)

Actually it was first an option in Qt 4.1. Not sure of the exact date, probably early 2006.

Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.

>> It basically a marketing page.

So.. what about the rest of the points on that page? Introspection and all that good stuff comes from moc.

I don't know what you exactly need, but this might be an option for you if you want Introspection: http://en.wikipedia.org/wiki/Typeid The other major point on the page is creating connections to UI produced from XML files ("GUI is dynamic") I imho frankly don't see much point in doing this. The translations are not in the UI anyway, so why bother to construct the UI from an XML file during runtime? Never missed this feature and its no problem doing something like this with templates during compiletime.

I sure appreciate it a lot more than that warm fuzzy feeling of being more pure to the C++ language.

Please be more specific what other good stuff comes from moc and gives you a warm and fuzzy feeeling? I cannot get a warm and fuzzy feeling from programming C in C++.

> I don't really see the point in using a language, when you don't actually use pretty much anything of this language.

Templates are hardly the only feature of c++. Can't you make your point without completely over exaggerating everything?

Point taken, sorry, my fault, but I am not exaggerating everything. A few examples: .) Does it use templates - no. .) Does it use standard collections & iterators - no. .) The standard C++ string? no, you cannot even construct a QString from a std::string without using c-strings. .) Qt hardly uses any exceptions (apart from exceptions thrown by "new" and those are not QT exceptions). No templates, no exceptions? So I think I am not that far from the truth. Nevertheless sorry for the exaggeration.

> especially when they pollute the main namespace.

You're linking to a post that is 7 years old? Qt lets you choose between using 'signals' or using Q_SIGNALS. KDE uses latter, specifically to avoid namespace problems.

It is still featured in the wikipedia entry about QT, and therefore still seems to be valid. Please correct the (german) wikipedia entry if you feel that this is not valid anymore. The english wikipedia entry boils basically down to the same conclusion. Q_SIGNALS is a new name for the same old concept: C-macros. The advantage is of course, that it won't pollute the namespace anymore. And it seems to have appeared in QT 4.4 (please correct me if I am wrong), that means somewhere in Mai 2008. So that development is pretty recent and therefore not really something to be proud of.

> Moc is imho simply a hack for something the language can deliver itself by now.

Not at all. Read: http://doc.trolltech.com/4.4/templates.html

I have read it all. And some things on this page are plain wrong: example: "Our approach goes far beyond anything you can do with templates. For example, we can have object properties. And we can have overloaded signals and slots, which feels natural when programming in a language where overloads are a key concept." It basically a marketing page.

Another big advantage that that link doesn't mention is scripting support. Qt binds very nicely to javascript, python, etc.

So does Gtk. You can wrap C++ templates with SWIG, but this is not the way templates are meant to be used and therefore more complicated. But it is possible.

C++ templates don't allow for introspection and calling functions based purely on a string name. (At least, afaik. Correct me if I'm wrong)

You are right, that is a shortcoming of C++. Meanwhile lots of compilers support "typeof". The library Boost.Typeof should also be able to help under certain circumstances. The question for me is: Do I really want to call a function based on a string name? I never came across a situation where I needed to do that. There were always more robust ways so solve the problem.

> I don't really see the point in using a language, when you don't actually use pretty much anything of this language.

Templates are hardly the only feature of c++. Can't you make your point without completely over exaggerating everything?

> especially when they pollute the main namespace.

You're linking to a post that is 7 years old? Qt lets you choose between using 'signals' or using Q_SIGNALS. KDE uses latter, specifically to avoid namespace problems.

> Moc is imho simply a hack for something the language can deliver itself by now.

Not at all. Read:
http://doc.trolltech.com/4.4/templates.html

Another big advantage that that link doesn't mention is scripting support. Qt binds very nicely to javascript, python, etc. C++ templates don't allow for introspection and calling functions based purely on a string name. (At least, afaik. Correct me if I'm wrong)

Fun small world :) mem mapping was a feature I added to Qt 4.4. I even wrote a blog entry on it on labs.trolltech.com http://labs.trolltech.com/blogs/2007/10/15/file-mapping/

I think I added the labs.trolltech.com RSS to my startup page shortly before after that happened, but after your post ;-)

Keep up the good work! It really is like having extra staff compared to the "bad old days" when we'd have to keep up with shifting OS requirements on our own.

Wow, it might even take me less than 10 min to learn and I actually learned it, but I don't really see the point in using a language, when you don't actually use pretty much anything of this language. C++ has evolved, the basics of QT havn't. Perhaps nuissance is not the right word, perhaps annoyance is better, but Moc is imho simply a hack for something the language can deliver itself by now. Yeah, perhaps I am a C++ purist, but I seem to be not the only one who thinks that C-Macros should have very little place in a C++ program - especially when they pollute the main namespace. E.g. see http://lists.trolltech.com/qt-interest/2002-08/thread00000-1.html

Fun small world :) mem mapping was a feature I added to Qt 4.4. I even wrote a blog entry on it on labs.trolltech.com http://labs.trolltech.com/blogs/2007/10/15/file-mapping/

Really? I guess someone should tell that to trolltech as they refer to these and other constructs as "C++ extensions"

http://doc.trolltech.com/4.0/moc.html

Additionally, the list of what you can and cant do in a signal/slot block is quite extensive. Even MFC, abortion that it is, is not nearly so screwed up.

I especially like the quote, "Less importantly, the following constructs are illegal. All of them have alternatives which we think are usually better, so removing these limitations is not a high priority for us."

Translation: we are not up to the task of fixing our crap, so screw it.

Like I said, I'll stick with ANSI C++ and let you ankle biters muck about with the moc.

similar in that they are both canvases, but not similar in functionality or scope at all. check out this blog post:

http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/

it's pretty insane. =)

That is factually incorrect: KDE applications can be (and are) released under a number of Free software licenses, including the BSD license, LGPL, GPL, MIT, X11, etc... you can see the licensing policy here: http://techbase.kde.org/Policies/Licensing_Policy ... you can also purchase a license from Qt Software and build proprietary applications. Qt itself has quite a permissive set of license exceptions as well: http://doc.trolltech.com/4.4/license-gpl-exceptions.html

So what really changes here is people not being required to purchase a license to do proprietary development and the people in the FOSS world who felt that was such a problem that they wouldn't touch Qt can now rest easy and use it.

In the case of Qt however there are many many special license exceptions which make this not true at all: http://doc.trolltech.com/4.4/license-gpl-exceptions.html

The only thing the LGPL'ing maintains is allowing licenses outside that list and since most of the open-source ones are on that list (including the BSD-style licenses) this generally is just applicable for proprietary programs.

Don't forget:

• Qt has Jambi (Java version)
• Qt has the bindings generator (ECMAScript (JavaScript))
• Qt has various bindings to other languages like Qyoto(C#) and Python

Actually, thanks to http://doc.trolltech.com/4.4/license-gpl-exceptions.html, there were no licensing incompatibilities with Qt and the Apache license.

Companies sell, eg transfer, software developed with Qt all the time, it's what is made for after all. Obviously the license allow it.

Not what I meant by 'transfer'. You can copy the software, but not transfer the license. In other words, you can distribute your product, but others are not free to fork your product and redistribute it. The forkers would need to purchase a license as well.

No need for GPL, you can freely use Qt with a wide range of open source licenses like Apache/BSD/etc Please check your facts. http://doc.trolltech.com/4.4/license-gpl-exceptions.html [trolltech.com]

I am aware of this, but not entirely sure about what it means. After all, you can already link GPL code with BSD code (that's how the BSDs use ext2/3 code, for example). That's because the BSD license is compatible with the GPL, which means BSD can be relicensed to GPL - the overall project is then considered as GPL. The same is true for almost all the licenses in the list there (except perhaps for Apache, last I heard).

In other words, at worst Google would need to GPL the entire app. But even so they could dual-license their own code, under the GPL and the BSD, so they could still say the code was BSD in a sense. And at best, they could just release it under the BSD, as it's compatible anyhow. Yet, in both cases they are releasing a product with a lot of GPL code in it - Qt itself - which means it can't be forked in a non-GPL manner (there are other implications as well). This is something that I believe Google wants to avoid when possible. With the Linux kernel, it isn't avoidable - there is no replacement. But GTK is a respectable replacement for Qt, and isn't GPL (it's LGPL). The same thinking goes on in a lot of other places, leading to high adoption rates for GTK. Again, Nokia can stop this, and I wish they would, simply by relicensing Qt under the LGPL.

Qt is nice, but its licensing prevents Google from using it in this way. To use Qt, Google would need to either pay for a license,

This would be no problem. Fact is, Google already does exactly this for other products.

but it wouldn't be transferable to others,

??? What are you talking about? Companies sell, eg transfer, software developed with Qt all the time, it's what is made for after all. Obviously the license allow it.

or Chrome would need to be GPLed. Google goes to great effort to license it's code under the Apache/BSD/etc. licenses whenever possible, as it considers this better for it's business (and that's a reasonable position to take).

No need for GPL, you can freely use Qt with a wide range of open source licenses like Apache/BSD/etc. Please check your facts. http://doc.trolltech.com/4.4/license-gpl-exceptions.html

Get a clue, dude. You are certainly allowed to develop non-GPL apps with GPL Qt, you just have to use one of the other free licenses listed as exceptions .

He did say "all non-GPL activity". If I understand correctly, the GPL license of the QT toolkit requires all derivative works to be distributed under the same terms, i.e. the GPL.

In contrast the LGPL license of GTK and wxWindows still requires you to contribute your chances to the library but allow you to license your own work however you want. Just linking isn't considered a derivative work under the LGPL, as long as you can still modify the LGPL portion.

So with an LGPL'd library, you can write an application and sell it under whatever license you want. With QT you have to use the GPL or you have to pay for a Q Commercial License. And that's not the worst of it:

You must purchase a Qt Commercial License from Qt Software or from one of its authorized resellers before you start developing commercial software. The Commercial license does not allow the incorporation of code developed with the Open Source Edition of Qt into a commercial product

So if you have a free application that's popular, and you want to release an enhanced edition for a small fee, you can't do that if you've chosen QT. It's a bizarre rule, I can't figure out why they'd want to stop people from giving them money.

None of this matters for the software freedom purist. Personally, I'd prefer everyone just use the GPL. But there are many who won't, for any number of reasons, and for them QT is less attractive because of its licensing.

And windows is somehow less restrictive than the GPL?
Windows restricts your personal use of the software, does not provide source code at all and prohibits redistribution of the binaries you do have...

You won't pay for a qt license, but were perfectly happy to pay for a windows license? That's quite a double standard right there...

Also take a look at:
http://doc.trolltech.com/4.4/license-gpl-exceptions.html

It seems you can write code under various licenses and link it to qt...

http://doc.trolltech.com/4.4/license-gpl-exceptions.html

"Oh, and before some idiot comes in with "hurf durf we don't want your PROPRIETAAAAAAAARY code!!!111""

the worst thing that can happen when you pre-emptively call other people idiots is showing that you're not so much better yourself in the process.

as you can see here:

http://doc.trolltech.com/4.4/license-gpl-exceptions.html

all the licenses you list are just fine, and then some. enjoy.

The Linux community should stop focusing on making cool Linux programs (for now). The community should devote most of its new effort to creating a development environment that makes it trivially easy to port a Windows or Mac program to Linux.

Actually, it's almost there. Qt4 is really a great library, and not just for UI - it covers other common stuff such as XML parsing, networking, database connectivity, and so on. It really is in many ways analogous to what Java or .NET can offer, but for C++, and cross-platform. Then we have Eclipse CDT for a pretty decent C++ IDE (code completion still not on par with Visual Studio, but the visual debugger is okay - about the level of VS2003). And then you can install the Qt Eclipse integration plugin and get the visual UI designer, wizards, and integrated documentation.

On the whole, this bundle is light years ahead of any version of Visual Studio when used for MFC development (primarily because MFC is crap as such), and is close enough to Visual Studio + Qt/Win32.

So, developing desktop apps on Linux, today, is not hard at all. The problem is 1) finding enough people who are willing to pay for what you make in a market that small, and 2) getting your app to flawlessly install and work on all the various distros out there without too much hassle.

That's like saying that since cars have existed for over 100 years it is impossible to get a patent on a new development for a car.
Looking at the claims, this patent is (unsurprisingly) not trying to claim the use of 3-D technology in a computer GUI. Instead, look at independent claim 1:

1. A graphical user interface, comprising:a viewing surface;a back surface axially disposed from the viewing surface to define a depth;one or more side surfaces extending from the back surface to the viewing surface;a visualization object receptacle disposed on one or more of the side surfaces; and one or more visualization objects disposed within the visualization object receptacle, the one or more visualization objects corresponding to one or more system objects.

      The Apple application is for the use of a room-like setting where there is organization of visual elements along the "floor", "walls", and "ceiling" of the room. This is definitely different than looking glass, about the closest thing I've seen would be a demo from Qt on a Wolfenstein + desktop elements interface: see video here. However, it is unclear if the Wolfenstein demo actually anticipates the claims of this patent on two grounds: 1. the use of a static room could be different enough from the use of a maze, and the Wolfenstein demo does not stack & arrange elements like Apple is claiming) and 2. The Apple invention likely predates the WolfQt code.
    Additionally, as is often the case with Slashdot, the readers do not understand the difference between a granted patent and a patent application. This is ONLY an application, and as any patent practitioner knows, what you originally apply for is often much different than what you eventually get granted as a patent.

      Finally, before everyone in here panics that Linux will be illegal in 2 weeks or some other nonsense, just look at the subject matter that Apple is patenting: It's a stupid room with windows pasted on the wall! Who cares!! Even if Apple gets the patent, just don't go out and copy them and you'll be fine. The attitude of panic on here is actually indicative of a deeper fear. It's not that patents "stifle innovation", but instead that patents mean you can't just make a direct knock-off of some other UI which is what really freaks some people out.

Not only is Qt under the GPL, you can also link to it if you use any of a whole bunch of licenses.

Well, the now Nokia-owned former-Trolltech Qt Software's Qt toolkit is being ported to symbian as we speak (with a pre-release out already). The OpenMoko project is also switching to Qt, and since Qt 4 is a superb multi-platform toolkit, it might get ported to other mobile platforms as well. So in the future, perhaps using only Qt would suffice. That were great, because I think Qt 4 is really amazing! :)

Qt+Webkit:

• Both support JS,
• Are both Open Source (Commercial Qt apps can be linked against the OpenSource version)
• Both are compilable on just about every platform.
• Qt provides the ability to embed a Qt custom control into WebKit, and expose it to JS for scripting. You can even use Java with it if you're a byte-code purist.

It seems the Qt+WebKit combo is only in need of convenience functions to make it more appealing.

Qt+Webkit:

• Both support JS,
• Are both Open Source (Commercial Qt apps can be linked against the OpenSource version)
• Both are compilable on just about every platform.
• Qt provides the ability to embed a Qt custom control into WebKit, and expose it to JS for scripting. You can even use Java with it if you're a byte-code purist.

It seems the Qt+WebKit combo is only in need of convenience functions to make it more appealing.

The laundry list of limitations in Qt3 driving the move have long since faded from my memory (though I seem to recall Vista support being a fairly large motivator.) But apart from that, ongoing commercial development requires active support, and Trolltech's support services have long since dropped support for Qt3.

Porting from Qt2 to 3 was a breeze, compared to the move to Qt4. The automated porting tools didn't do much for us, and the Q3Support layer-- while it gave us a good stepping stone-- eventually had to be ripped out almost entirely because we kept hitting all sorts of esoteric bugs that couldn't be solved without porting the code all the way.

To be fair... I like Qt a lot, and it's still my first choice for multiplatform GUI development. (Before many of the platforms sank into obscurity our app suite built from a common C++/STL/Qt codebase onto Windows, Linux, Solaris, HPUX, AIX, Irix and OSF, which still impresses the crap out of me. :) )

when it comes to banging out a GUI .exe for windows users to use quickly, I don't think there are better choices.

I've got a Q and a t who think otherwise. Product page: http://trolltech.com/products/qt/ Wikipedia: http://en.wikipedia.org/wiki/Qt_(toolkit)

I find the Qt documentation leaps and bounds ahead of MSDN.

I wish Google or someone would come out with a phone which is based on a completely open OS like Linux and where people can write their own programs and so on for it.

Someone already did, Openmoko started shipping the Neo FreeRunner back in July. There are already a whole wack of competing distributions for it. The current release produced and supported by Om is 2008.09 (which is bugfix version of 2008.08) the phone stack for this is QTopia

Right now the whole thing is pretty rough and ready, kind of reminds me of Linux 0.9 back when you had to download a whole load of floppy images... But there's something horribly geeky and thrilling about ssh'ing into your own phone.

Well, it shouldn't be too hard to build something basic for a netbook -- since Trolltech(Nokia) have ported Webkit to Win CE.

This one looks promising. I might give it a try.

If I can get that working with qt I'd be pretty happy.

gvim + CeGCC + qt => good enough for tinkering with. (if it works)

Wouldn't each individual application need to be recompiled as well in order to access those functions?

I'm not an expert on binary compatibility but I think the answer to that is no. It would not change the API in an incompatible way, so I think drop in new libraries and it's done. Not that recompiliing is a big issue for open source apps anyway...

That is not the response from the few developers I've talked to who actually understood my explanation. They seem to think it would be a lot of work. I suppose that is subjective though.

Well, it wouldn't be little work but for a KDE-only solution it sounds to me pretty much exactly like the Plug&Paint example where you'd dynamically load "service" plugins from a global directory which would show up in a service menu to manipulate the application. Technically it would be a drag-and-drop installation but plugins are pretty tricky about compiler versions so you'd want one compiled for your distro. It's probably more a question of getting permission to since you'd have to mess with pretty basic library objects.

What, you want a Visual Basic for X11?

What is needed is a COMPELLING, modern, cross-platform, open-source, GUI, business application development environment.

Like the one Google Earth uses? Qt4.

The truth is that "Free Software" is still on the bottom of the need-to-be-compatible list, as of now. Plus, for some people the fact that it is free makes them hate it (strange, but true).

News update: Qt (Not QT, but Qt) is now completely GPLed (v3). People type in QT like it's a damn acronym or something; makes me ponder why they never get it straight.

Echo the parent with the following variations:

1. Multi-platform targets with common code base. I build on X-Code / VisualC / Gnu command line, and whatever else comes around. Making Qt based code compile warning free in all environments takes about 1% additional effort, and shows up enough bugs to pay that effort back threefold.
2. E-mail is a given, sacrificing an hour of time for weekly face to face is also priceless, the formal meeting is usually done in 15 minutes or less, but the after-meeting sessions can run from 5 minutes to all afternoon, and that's where most of the problems are solved. We buy everyone lunch as an appeasement for calling the meeting (and also to get them to do a little work during lunch one day a week... nobody seems to mind the trade.)
3. We use SVN too, dedicated box in the closet, I think the hardware was destined for the scrap heap until we made a SVN/Trac server out of it, only cost is in electricity to run it - if that's a concern, think about running your server on something like the Asus EEE desktop PC when it comes out - with 3 guys, you don't need a killer server (and, looking back, the EEE desktop kicks a $10K 20 year old server around the block.) I have also successfully run Trac/SVN service on a MacMini (though I'd recommend booting it into Linux if I were to do that again).
4. We're looking at continuous integration, haven't done it yet with the excuse that the team is too small to take time out to set such a thing up.

You want to solve the linux fragmentation problem? Well, uniting the two dominant desktops is a great place to start. I've been around a long time so I understand that historic reasons for there being two toolkits. Quite simply, "in the beginning," there *was* no clear winner between Qt and Gtk. They were both immature and unproven.

But, as Bobby sez, things have changed.

Gnome moving to Qt is one of the best ideas I've heard in YEARS! Qt is commercial, better documented, and was DESIGNED to work everywhere from embedded devices to Macs. I've personally worked with both toolkits and as a Cocoa developer, well, Qt is just better.

A quick search for "Gtk Embedded" reveals that my suspicions are correct. The first result is some obscure article in Linuxjournal from 2002! The same search for Qt takes you to Qt's embedded systems portal, full of documentation articles and so on.

http://www.google.com/search?&q=Gtk+embedded
http://www.google.com/search?&q=Qt+embedded


But this isn't just with the embedded side of Qt/Gtk---it's with everything. Go on, pick a topic and do an honest comparison. Want to install your Gtk application on Windows? Get ready to install Cygwin! Want to install A Qt application on Windows, or perhaps a Windows CE phone? No problem: http://trolltech.com/products/qt/features/platforms/embedded/windowsce

I see a lot of comments doing a lot of whining about "Qt Applications are Unstable!!" Qt is easier to deploy consistently and for this developer works more like every other standard GUI toolkit. Gtk is and has always been an absolute nightmare. This anti-Qt argument is one of the stupidest things I've ever heard, something akin to how Java is evil because it is allegedly slow. Here's a tip: next time someone tells you about Java being slow, ask them if they've ever heard of SwingWorker. If they have, ask them to explain how/why it exists. :)

>What about Java? You've got AWT (which is old and ugly), Swing (which is newer and stands oWhat about Java? You've got AWT (which is old and ugly), Swing (which is newer and stands out on any desktop) or Swing (which generally looks native, but which would generally also require you to bundle the JAR with your app, making the download considerably bigger in a lot of cases).ut on any desktop) or Swing (which generally looks native, but which would generally also require you to bundle the JAR with your app, making the download considerably bigger in a lot of cases).

For Java you have at least in the GNU/Linux world the same options as for Mono:
- GNOME: gnome-java
- KDE: Qt-Jambi
- Windows&MacOS: You can use Qt too

CPL and EPL licenses were added by Trolltech to the list of OSS licenses that can be used with Qt-GPL around the same time Qt was released (also) as GPL3 and before the Nokia buy was announced. AFIK, there's no current reason why SWT couldn't have a Qt backend now.

If that isn't enough, Trolltech will also provide QGtkStyle which will draw using native GTK widgets in the same way it uses native Cocoa/Carbon on OS X to make all Qt/KDE 4 applications have a Gnome look and feel, including things like the order of the dialog buttons.

Isn't there anything like the automated snap to grid UI layout tools like Interface Builder

KDE makes heavy use of QT which does have an interface builder. It's quite advanced compared to VC2005's MFC dialog editor, supporting niceties such as defining dynamic resizing behavior.

Why do the UI elements and widgets look like they are straight out of the damn stone age

QT renders controls itself. On windows and on OS X, QT apps blend in seamlessly unless you manually change QT's current theme. This is means that QT and KDE are capable of mimicking these standard widgets exactly. So, I have to wonder whether you have any idea what you're talking about. It sounds like you're just saying shit, kid.

Why had this taken so long? KOffice is built with Qt, a robust cross-platform gui toolkit, http://trolltech.com/products/qt/.

Being a enterprise developer using Qt, the worse that I've had to deal with is some linking issues with dynamic libraries and GUI adjustments when porting to windows from linux...

Perhaps the "KDE" portion of the code is harder to port than the "Qt" portion?

Microsoft is many, many times more developer friendly than Apple. For example,

http://trolltech.com/company/newsroom/announcements/press.2007-06-19.6756913411/?searchterm=codebase

At least the windows API has been stable for a LONG time. You can get code that was running on Windows NT to continue to run, mostly. Or at least have a reasonable way of porting it. Stuff doesn't suddenly disappear in Windows.

This is good news for developers. For some reason, users think that Apple was is better. I guess people only care about the latest-greatest app instead of having an inhouse or custom made application working for a decade or so, then Apple may look better.

Qt let's you do this. It comes with a Ecma-262 engine (i.e. javascript) that integrates with the rest of Qt in your code.

The Greenphone was ditched in favor of better options. The current development platform of choice is the Neo1973, the same platform used by the OpenMoko folks. Nokia hasn't yet announced a new development platform (i.e. one that they actually make) for Qtopia Phone Edition.

As to portability, that's one of Qtopia's biggest merits. It was so extreme that before the Greenphone was nixed, people were finding better support on other platforms (since Trolltech had no idea of how to design cellphone hardware). The only reason they even made the Greenphone was to jump-start the Qtopia Phone development community and (probably) as the second big step to position themselves for a buyout by either Motorola or Nokia. (The first step was the IPO in Norway.)

Someone else already did this as well. :-)

Everyone who wants to is explicitly granted that right.

However, there is economy of scale and for the most part things go forward fastest with fewer forks. So it behooves us for a few vocal suits at Nokia to get treated for their apparent R-CIS before it gets worse and in case it is contagious. It can strike anybody, but suits seem more succeptible.