Slashdot Mirror

That has been an evolving thing which was sorted out before Nokia was involved.

Nokia bought TrollTech in 2008. Qt was released under the LGPL license in 2009.

it became clear that Mr Stallman and others refused flatly to read the qt licence changes when there was an attempt to make it more compatible with the GPL.

Straight from the horse's mouth:

Thanks in part to the discussions held here by the freshmeat community, Trolltech has decided to release the next version of Qt under the GNU General Public License. In today's editorial, Eirik Eng and Matthias Ettrich explain the reasoning behind their decision.

We have been in contact with Richard Stallman (President of the Free Software Foundation) on the issue, and he has been kind enough to offer his help and analysis. He has also sent us comments from Professor Eben Moglen, Professor of Law & Legal history and General Counsel for the Free Software Foundation.

That's from the article written about the decision to release Qt under the GPL, by the people who made that decision. If you use Google, you will also find plenty of mailing list threads where people are discussing the QPL's incompatibilities, and Stallman participated in some of those threads.

Yes, I understand that some people in the Free Software community considered a modified QPL to be compatible with the GPL, but disagreeing with them doesn't mean that you haven't read the license, and just because TrollTech attempted to make changes to make the QPL compatible, it doesn't mean that they were successful. Sometimes bugfixes don't fix the entire problem. Complaining about the bug after an incomplete fix doesn't mean you haven't run the software.

(I should probably keep this in a text file on my desktop, it's a "batch of advice" which I frequently have to re-write, and it doesn't change much)

I mentioned the term "modern C++" above, though really it's better to call it "sane C++". By this I mean C++ that won't drive you nuts trying to figure out what went wrong, when something inevitably *will* go wrong. Practices that make programs more safe, and introspective.

If you already know C++ (the foundations, I mean), it'll be easier to shift to STL-dependent C++. If you're completely new to C++, these resources will still be very important, but you'll need to learn the lower-level stuff in parallel, so you can understand how STL containers/templates are built from the inside (which is important when you need to choose which ones to use).

A website that should very often sit in the background while you're coding/learning: C++ FAQ Lite. Following these rules will make it much easier to design and maintain your programs.
Another very useful website: cplusplus.com. It's a huge reference site, with a lot of examples.

The books I'd recommend:
Accelerated C++ -- higher-level to lower-level approach.
C++ Coding Standards -- similar to the C++ FAQ Lite in the nature of the advice, but covers more ground and is probably better organized.
C++ Common Knowledge -- This is for a few months down the line, delves into some nuances.

Software:
Windows: Visual Studio C++ Express -- You can force it to stick to ANSI C++. It's still the best IDE for C++ on windows (IMO).
Linux/Mac: Eclipse, probably Eclipse IDE for C/C++ Developers. Remember though that you can tweak Eclipse into just about anything.

If you're writing end-user applications, keep in mind two frameworks: Qt and wxWidgets.

Quick note about Boost: If you can create a structure using some combination of STL components, do that before resorting to Boost. Boost is highly abstracted, and you should only use the parts which would otherwise be extremely complicated to create from scratch (like regexp).

Where? I can't find that phrase either on this page or this page.

Isn't Qt owned by Nokia, not the symbian foundation?

Do you have a problem reading? From the GP:

Nokia own both Symbian and Qt

Where in his post did he say that Qt was owned by the Symbian foundation?

It doesn't say anything about open sourcing the symbian version of Qt.

The Qt for S60 Technology Preview is available under a special technology preview license, GNU LGPL version 2.1 and GPL version 3.

http://www.qtsoftware.com/developer/technical-preview-qt-for-s60

Yeah, but you have to miss just one of those deletes, and boom

For deletes that you can't put in the obvious "proper" RAII place (class destructor), you now just wrap in a tr1/C++0x::shared_ptr and stop worrying...

Not everything is in Qt

Damn close though: Networking (http, ftp, sockets, ssl, etc), SQL, XML, WebKit, OpenGL, SVG, Multimedia... never mind whats in qt-core & qt-gui... have you browsed the Qt 4.5 docs lately?

import other libraries ... string ... hashmap

Just out of curiosity what libraries would these be?

Does anyone know QtJambi is doing? I heard that Nokia has stopped maintaining it since purchasing trolltech. Is that a big deal, or was it largely community supported to begin with?

I'm not really well-versed on the subject, but I did do some research earlier today, so I'll try and post what I found. It looks like you're correct, insofar as that Qt Software says it will discontinue Qt Jambi. However, in the same press release, they mention that they will host and help maintain a community-driven version, which (I'm guessing) is here. The site itself makes no mention of the project halting, and the front page shows very regular updates, including a FreeBSD port.

I really hope Jambi enjoys continued development. In my opinion, bindings libraries like Qt Jambi are absolutely critical, both to unlocking the power of a language as well as fostering a diverse tool set and developer base for FOSS platforms. Furthermore, when you combine a cross-platform toolkit like Qt with a cross-platform language like Java (or Mono, for that matter), the result is pretty cool. Developers just have to overcome the misconception that Java is for applets/J2EE/embedded, and that the UI face of Java is Swing. It's a language, like any other, with pros, cons, and fans, and (in my opinion) exceptionally suited for desktop application development.

GNOME needs to follow suit, and soon, if GNU/Linux is to ever gain relevance on the desktop. For anyone who doesn't believe me, see the First Principles of Interaction Design and how many of those principles are broken by having two different toolkits that behave slightly differently, but are expected to co-exist (KDE apps on GNOME and vice-versa). QT is the logical choice for the One True Toolkit as it has the best development tools of the GNU/Linux ecosystem.

What's that, you don't care whether GNU/Linux gains traction in the desktop market? That's funny, you're one of the ones advocating it to people, either fix GNU/Linux or stop advocating.

Qt is not just a gui framework. It provides a massive amount of extra stuff. Browse the documentation: http://doc.qtsoftware.com/4.5/index.html/

Note the WebKit integration, multimedia framework (Phonon, which was a part of KDE and later folded into Qt), OpenGL support, etc. etc.

Comparing it to GTK is like comparing a full-fledged desktop like KDE or Gnome to Blackbox.

Then there's the technical aspect that mono will always be running behing the microsoft C#/CLI version, and so your Linux mono application will generally not even run on Windows, or if it's running will be unappealing because it feels old to the MS user. Windows platform cli application almost never run on Linux, so that's not an advantage either.

So all in all we have here a technology that is offering nothing much, for a great future risk. No wonder we avoid it like Pfeiffers disease (or mononucleosis).

If one wants to develop great crossplatform apps, use Qt, it has all and more of the advantages, and none of the risks.

I'm a fan of verbose variable and method names, but simplistic symbol usage.

I find languages like C have far too many unnecessary symbols. Stuff like <<, >>, ->, ::, etc. could all be replaced by dots, plusses, etc., and the compiler could figure it all out. Apparently there's even a few IDEs (like QT Creator) that can automatically do it to make it easier on programmers more familiar with other languages.

Code should be readable.

function plotResults(int[] Results)
{
if(verifyLength(Results))
  {
  resultsGraph.reset();
  resultsGraph.plot(Results);
  }
}

Most languages can be coded in such a way, but I do find excessive amounts of symbols(C/C++) or keywords(Java) does cloud the cleanliness of the code a bit. And I myself am not in the "Genius OS coder" developer bracket, so having to remember what extra symbols C requires actually distracts me from the design of the program.

I do better in languages with less symbols. Javascript is my best language (I've completed whole 5000 line projects without a single error; once I'm done writing it, it works as predicted), and Java is next best. With Java I usually have a few errors per 1000 lines, always caught the next day when I look through my code with a clear head, unless it's UI code. (I have trouble debugging swing crap :P )

And C... oh hell, you don't want me writing C. I can debug it and spot errors just fine, but I can't write code that compiles for the life of me. I always forget something, which causes the compiler to spit out error messages all day long, or at least until someone bails me out by telling me what I forgot.

I guess our minds all work different. Although mine is very technical and doesn't have a problem understanding what the code is doing, it wants the code in a specific style if possible, and it doesn't want to write styles it doesn't like. (mostly C)

One last note - I recently overheard someone ranting about the usage of indenting in Python. All my code is properly indented, so it would be trivial to remove the {} brackets from my Java code, if Java supported it. Yet more evidence of what languages work for my mind. ;)

I have no idea why GTK+ is still around since Qt went LGPL.

Qt has better documentation than GTK+.

As an example, you'd be hard pressed to find a widget in the QT documentation that is not documented. GTK+ has rough around the edges documentation for it's Canvas.

I know that RedHat is putting a lot of weight behind Java technology as one of the first and foremost distros for the OpenJDK. I can attest that the QT Java bindings are way better than the GNOME bindings. It would make sense for RedHat to toss weight behind QT. Google already uses QT for Google Earth. And KHTML is, sorta, WebKit which is Chrome. It all makes more sense to put our weight in QT.

I've got nothing but love for the GTK+ people. Also, don't kill QT just because of the KDE 4.0 issue. They've made good on their latest desktop, but don't knock a good Toolkit because of the DE.

My two cents.

One major boost for Ovi applications development is the coming Qt support for Symbian/S60 porting.

Old Symbian C++ programming was a real pain, now porting desktop or mobile applications, games, widgets, etc across a range of different devices should be really easy. I see many productivity advantages for the developers who opt for Symbian/Ovi, something Apple won't have for its iPhone.

Neigh everyone mentioned either vi or emacs (I know they can run on Windows, but they are not acceptable as an IDE and all ya'll need to get with the times), a few said Eclipse (wtf Java?? yeah it has plugins, but it isn't a C++ IDE dammit!), and DevC++ is just dead.

I recently tried out the Qt Creator and I love it. It feels new and snappy, works well, and emulates Visual Studio's dialog creator (in my opinion, being Qt and not MFC, kicks Visual Studio's bug-laden ass). I haven't been able to really squeeze the useful juices out of Qt yet, but the potential is evident.

Visual Studio Express is great, and if you want to do MFC than thats definitely the way to go, but if you're just programming as a hobby or for personal projects then I suggest giving Qt Creator a try

For Qt/KDE development [...] FireFox (on-line documentation browser).

Use Qt assistant instead. The class index function is much faster than navigating through the links with the browser.

I'm essentially a beginner in C++ programming and at least for that language I found extremely easy and straightforward doing projects on Qt Software's free IDE. Even if you don't implement their toolkit in your projects, you can still have a stable and unbloated environment to do some serious coding.

There is only one caveat, afaik, with Qt Creator. It's still in version 1.1.1... this means it probably misses some features (or has some not so obvious bugs) which shall probably be covered in later major releases. Nevertheless, if you bind Qt's capabilitities (ie, signals and slots) to your C++ projects there is no better IDE to unleash your productivity!

You can have more information and download your free copy here.

Two options that have not come up yet. KDevelop 4 is shaping up really good, but I do not think it is actually working on win32/64 yet. The other is Qt Software's offer Qt creator which is also getting a good deal of praise. The latter is probably extra good if you use Qt... and if you don't, I would recommend at least looking at it, since it is a very nice LGPL library.

Yes it is ordinary, that's the damn point behind the outrage:

http://doc.qtsoftware.com/3.0/qlineedit.html#setValidator

Oh would you look at that, "...place any arbitrary constraints on the text which may be entered." And on a toolkit that came out eight years ago, no less.

download a copy of Visual [C++|C#|VB] and you can do all kinds of fun stuff.

I prefer the Qt SDK - yeah, it works on Windows (as well as Visual C++ does), and after you've invested 3000 hours learning the tool, you're not locked in.

I used to ask the same question. I now work for a small startup. Most of us develop on Linux, a couple on Windows, and a couple on Mac. If we could afford to do a linux-only version, we would. But in order to have any kind of marketshare on the desktop, we need to output a Windows version.

The mac and linux versions mostly "just work" and simply need testing. But about a month before release, the entire team needs to stop what they're doing and get the Windows version fully working and tested. Windows development is a resource hog (in terms of people). In some ways, Windows is just different, but it seems in many ways, Windows is deliberately incompatable with anything else at the source code level. Windows makes it as difficult as possible to be cross-platform.

As a result, we get the Windows version out and working before we have time to test the Linux and Mac versions. It kinda sucks to spend that much time and resources on a Windows version. It's either that, or re-route our development resources to Windows-only and ignore the other platforms. Of course, we don't want to do that.

Just develop your applications using a Qt/C++/gcc framework.

Fast, native code, easy, powerful, free (LGPL) and cross-platform.

http://en.wikipedia.org/wiki/Qt_(toolkit)

http://www.qtsoftware.com/products/developer-tools

VLC, Scribus and VirtualBox are good examples of cross-platform applications developed using Qt and Qt creator:

http://en.wikipedia.org/wiki/VirtualBox
http://en.wikipedia.org/wiki/Scribus
http://en.wikipedia.org/wiki/VLC_Media_Player

If that doesn't appeal, then use Lazarus

http://en.wikipedia.org/wiki/Lazarus_(software)

Only potential problem with that is that you would have to write in Pascal. For me personally, that would be a bonus not a problem.

Peazip is a great example of cross-platform software developed using Lazarus.

http://en.wikipedia.org/wiki/Peazip

AFAIK all of these examples of cross-platform applications bring out versions for Windows, Linux and Mac at the same time.

Unfortunately, it's an area that still requires a lot of education. It's in the interest of the established proprietary vendors such as Microsoft to associate "commercial" with "proprietary" or "non-free" since one might infer that you can't use FLOSS for commerce.

However, what I find particularly dismaying is how common it is for developers of FLOSS packages to use "commercial" to mean "proprietary." For example, Qt which offers a "commercial" version and Magento, which has a section of their site for "commercial" extensions. I find Magento's use of the term especially ironic, since Magento itself is Free Software designed specifically to facilitate commerce. I'm not sure if examples like that are unintentional confusion over terms, or deliberate muddying the waters because they don't fully believe in the value of FLOSS.

I am thinking of IDE integration, and I can't tell the difference between that (commercial) vs the VS add-in (free).

From the FAQ:
http://www.qtsoftware.com/developer/faqs/121?hotspoturl=None

Binaries availability: Commercial Windows and Mac customers will have access to a package containing a prebuilt Qt library supporting commercial compilers such as Visual Studio .NET.

But if like you said you can just build the binary libraries yourself, why would you bother with QT commercial? For support? To save some time?

I don't get it.

And KDE isn't exactly the only software project relying on Qt. Here is a semi-official list of software projects using Qt. I do believe that software projects like Mathematica is a nice example of how widespread Qt is and how seriously it is being used.

boost::thread has a different design concept than QThread. I would appreciate if Qt
would introduce a Functor-style API for Threads.
Like QtConcurrent?

Well, it's a good thing you can distinguish between good and bad software. Maybe you can even employ that skill when choosing which to use. And if you choose Free, Commercial software, you can't lose, right?

But seriously, if you don't have to pay any money for the privilege of installing and running some piece of software, that's one less thing you'll loose if it turns out to be a bad choice. I don't care how much bad software is out there (of any license or cost). I only care about the good stuff. If you avoid all gratis or libre software because a large percentage of those categories is of poor quality, you might as well avoid the web because such a high percentage of websites suck.

QT *IS* LGPL: http://www.qtsoftware.com/about/licensing

Check out Qt Creator http://www.qtsoftware.com/products/appdev/developer-tools/developer-tools. Version 1 was only released a couple of months ago and it is already very impressive!

Another example is Trolltech's Qt, "taxing" the "sin" of producing non-free software.

Somebody has not been keeping upup. Qt is now LGPL.

For what it's worth:

I graduated in 1990 and immediately found work in C programming, which evolved into a C++ job around 1996. When I have looked around for work, Java seems to be much more "rapidly employable" than C++, but the few C++ jobs that are available tend to pay better.

Learning programming in the 80's, of course I started with BASIC, and Fortran was just a slight twist of phrase away... I still encounter Fortran occasionally, but it's pretty widely acknowledged (even by the people who still use it) as dinosaur speak. Any serious new development around me tries to get out of Fortran as quickly as possible.

Java was "the way of the future" in 2003, I'm not sure the future is here yet, and I'm not sure Java will ever "perform" on-par with C++. I program in Qt these days, and it is delivering the cross platform promise, in C++, as well as Java ever has.

If I were 20 again, I'd probably focus on Java, but, being where I am, I certainly have no regrets and don't think I'll give up my C++ unless I have to.

The good old symbian myths:

- No c++ exceptions, below the rebuttal:
http://developer.symbian.com/main/downloads/papers/Exception_Handling_in_Symbian_OS-v1.02.pdf

- Descriptors: yes, they are weird, but they do make sense:
http://descriptors.blogspot.com/

- Standards: Open C, pips (posix compliancy), S60Python. Is hard to build an OS on a language which was not standard when it was being designed.

- there are more runtimes than symbian c++ (if that is too hard for you):
http://blogs.forum.nokia.com/blog/hartti-suomelas-forum-nokia-blog/2007/05/17/slides-for-the-s60-runtimes-presentation-on-svsig

plus: QT for s60 is around the corner and will remove some of the pain for developers.

http://www.qtsoftware.com/developer/technical-preview-qt-for-s60

about the debugger: I still don't see the problem with carbide.c++ 2.0 and trk to debug symbian phones. You can also go fancy an use lauterbach or any other ICE that you like. Also you can use the emulator for 90% of app developement, so unless you are making something tied to the HW your target debugging should be a breeze (if you know what you are doing).

and about android: Please go on an read the code, run a grep for "fixme", then another for "??" and another for "hack". I specially like the TI AT command workarounds in the their telephony RIL reference implementation. This guys have put it together with gum and tape, product quality my ass.

Yes, they have good ideas, they are not reinventing the wheel and is easier to use (sometimes), but feature wise, production quality wise, android is not just there...yet.

Mod parent up. Symbian is a truly horrible OS to develop for.

True, but if you don't like its core c++ api, you can develop applications for it in Python or (soon) Qt both of which have a much nicer api.

And there's the PIPS API allowing you to port POSIX C apps and libraries to Symbian (most recent S60 apps use it).

Starting with 5th edition, you can also use Flash Lite. And, of course, there's still Java, too.

  Not only that, but there are many different versions (V9, V9.1, S60 3rd Ed, S60 FP1, S60 FP2, 9.4, 9.5 and that's just the recent ones) and they are mostly binary and source incompatible.

You're making confusion between Symbian and S60.
As a developer, you only care about the S60 version. Since 2004, we've seen only two major S60 releases, 3rd edition and 5th edition.

Software written for plain S60 3rd edition should work on any 3rd edition device. Feature packs add, well, new features, so if you want to take advantage of these features, of course you'll be able to do so only on those devices which provide them.

Note that most people here are talking about Symbian C++, which is the way it is because it came into being when C++ was very new and didn't regular C++ had various features is has now. If you spend the time to learn (eg training) how it solves the various problems inherent in early C++, then it is quite easy to appreciate it - in my opinion anyway. The problem is that it's similar to regular C++ in many ways, which makes the differences very annoying and sometimes surprising.

Also note, you can develop on S60 using many different languages - Open C, Open C++, Python, Java, various web languages, and those are just the ones that come to mind. So, you don't even have to suffer Symbian C++, if you don't want to. I've no experience of those though.

I guess Qt for S60 will be available in due course. That's a platform/toolkit people usually think well of...even on slashdot.

And for those like me who were quite excited with the new licensing and wanted to use it with java... Don't think of it...

Qt Jambi - a port of Qt to the Java programming language - has been discontinued in order to focus resources on the Qt cross platform application and UI framework. Qt Jambi will be maintained for one year after the March 2009 release of Qt Jambi 4.5.0_01, and will be made available upon release under the LGPL license

QT Programming Language Support

Yes, learn QT and help out with KDE. I haven't done much programming with QT, I am confident when I say it's a lovely, powerful and compelling environment to program in. Its cross platform capabilities cannot be under estimated. VLC was created using QT.

So go ahead, learn QT, help out with KDE and make subsequent releases even more formidable.

Thanks.

Yes, learn QT and help out with KDE. I haven't done much programming with QT, I am confident when I say it's a lovely, powerful and compelling environment to program in. Its cross platform capabilities cannot be under estimated. VLC was created using QT.

So go ahead, learn QT, help out with KDE and make subsequent releases even more formidable.

Thanks.

Yes, learn QT and help out with KDE. I haven't done much programming with QT, I am confident when I say it's a lovely, powerful and compelling environment to program in. Its cross platform capabilities cannot be under estimated. VLC was created using QT.

So go ahead, learn QT, help out with KDE and make subsequent releases even more formidable.

Thanks.

Yes, learn QT and help out with KDE. I haven't done much programming with QT, I am confident when I say it's a lovely, powerful and compelling environment to program in. Its cross platform capabilities cannot be under estimated. VLC was created using QT.

So go ahead, learn QT, help out with KDE and make subsequent releases even more formidable.

Thanks.

Same here. The language looks fairly nice, but right now with ACE, Boost and Qt in my C++ toolbox, I'm doing alright. And I already develop, test, and deploy code that runs on MacOSX, Linux, Solaris, and supposedly Windows -- I have not actually tried there, but ACE, Boost, and Qt have abstractions that attempt to isolate developers from the OS. I'm curious if my Qt OpenGL stuff would work. I love using my Apple laptop for development. I'm more of an GNU Emacs fanboy than Apple (though I did buy a chunk of Apple back at $18 pre-split), so I do everything there, including having multiple shells open in it for command-line use. I even have a Platypus script that I can drag files onto and edit in GNU Emacs. I just take my GNU Emacs customization files to other platforms so I always have the same editing environment.

These are the first ones that came to my mind, but you could try one of these, or this one, or this one, or this quite small one.

GIMP and Paint.NET aren't as good as Photoshop
Inkscape isn't as good as Illustrator
VLC isn't as good as The KMPlayer
Songbird isn't as good as foobar2000, Xion, Winamp or iTunes
Jahshaka isn't as good as Premiere or Media Composer
Blender isn't as good as Maya, 3D Studio or LightWave 3D
GCC isn't as good as Visual Studio

Try comparing apples with apples.

GIMP 2.6 and later is as capable as Photoshop. It now has 32-bit colourspces even. Considering that Photoshop is about $800, and GIMP is $0 ... you are really going to be scratching here to find a reason why one should use Photoshop in preference.

If you don't like the GIMP UI ... try Krita.

> Inkscape isn't as good as Illustrator

Debateable. Inkscape is pretty good, and getting better all the time.

> VLC isn't as good as The KMPlayer

Ok ... so use KMPlayer then. It is available for Linux.
http://kmplayer.kde.org/

Oh sorry ... did you mean this one?
http://kmplayer.en.softonic.com/

Meh. A Winamp clone. They are a dime a dozen.
http://en.wikipedia.org/wiki/Audacious_Media_Player

> Songbird isn't as good as foobar2000, Xion, Winamp or iTunes

OK, you don't like Songbird? ... so use Amarok then ... the very best software for your media collection ... and it supports iPods.
http://en.wikipedia.org/wiki/Amarok_(software)
http://amarok.kde.org/
http://amarok.kde.org/en/screenshots

> Blender isn't as good as Maya, 3D Studio or LightWave 3D

You are kidding, surely? Blender is the best by far ... I have heard however that because of the exceedingly poor support for OpenGL on Windows, Blender doesn't run very well on that platform. So do it like Pixar and others do it ... run Blender on Linux.

> GCC isn't as good as Visual Studio

How do you figure that? GCC is the premier compiler set in the world. It targets more architectures, and handles more software langauges, than any other compiler.

Did you mean an Indetgrated Development Environment, perhaps?

Try Eclipse then.

http://www.eclipse.org/

Or perhaps something like Kdevelop in conjunction with Qt designer is more to your taste:
http://www.kdevelop.org/
http://www.qtsoftware.com/products/appdev

Really, if you are going to compare applications, at least choose comparable ones. Oh, and if you want to run decent applications at good speed, then it would help immensely if you weaned yourself off of Windows.

As for *good* open source games, try these:
http://ubuntulinuxhelp.com/top-12-best-games-for-ubuntu-linux-1-tremulous/

http://rangit.com/software/top-8-linux-games-of-2007/

Enjoy.

Except for the fact that you are still programming in C++ which is bloated, monstrosity of a language.

Except for the fact that you don't have to use C++ in order to use Qt.

Try Qt, which is about to go fully open source. It is much easier than C#, Mono, or Java.

Most people think of Qt as a GUI toolkit. They're not wrong, but that's like calling a Swiss Army Knife a "pocket knife." That's only one thing it does, and the characterization completely misses the point. Qt is an application framework. It fixes every gripe developers have with C++.

Qt promotes clean and well-developed code that is easily ported to Windows, X11 (Linux et al), Mac, and Embedded (Linux sans-X11). That's something even Java doesn't do well (have you ever tried porting between J2SE and J2ME? nothing works!), even disregarding the whole performance loss from the JVM emulation-like interpreting that goes on.

The LGPL relicensing of Qt coming this spring will change the entire programing language landscape. Nokia is moving in to crush Java. C#/.NET and it's mediocre OSS implementation in Mono aren't even on the radar.

I cite the LGPL announcement because that's the kiss of death, placing Qt firmly above GTK (GTK being an incidental casualty on the way to said crushing of Java). With Mono relying so heavily upon GTK#, that puts it behind the game already (the Qt# project is cited on the Mono page as completely dead).

Recall that Nokia is a phone company. They need not make money from the software. Freeing and promoting Qt (and getting it to supplant J2ME) merely feeds this primary function. And while they're at it, they're sweeping in a wonderful set of perks for software engineers in and out of the Free Software community, on both embedded platforms and desktops.

Why don't you go for Qt 4.5 beta? It's available both under GPL and a "special beta license" (dunno what that means). When Qt 4.5 is officially released (about March '09), supporting LGPL, you already playing with it.

I've been working with it for about a year and it's really nice. It feels somewhat bloated sometimes and I really dislike the Visual Studio integration. Qmake could be better. But, overall, I believe is the best framework for C++. It's really nice to work with.

I know it's probably just bad luck, or some ignorance on my part, but I gotta say that I bloody hate Qt. There are loads of applications I would like to run that use it, but every time I try to compile one I go through the same soul destroying and ultimately fruitless process.

@ Canonical: Your download and version explanation system is a shambles. I don't want loads of versions and licences to read. I dont want Java script required to get it. I want a simple installer that works on my Debian system or a bog standard ./configure + make all process.

Why do you make your software so hard to use?

Look at this webpage: http://www.qtsoftware.com/downloads/opensource

** Application Development or Device Creation. **

WTF? What is that all about to someone who just wants to run an application that uses Qt?

** Choose platform and programming language **

Why the hell am I even looking at this when I just want to run an application?

I know my comment will be burried for saying this, but this kind of crap is what we all know is wrong with open source software. The front end delivery is done by geeks and bean counters who don't actually use the products as end users.

If you want Qt widely used you need to make it easy to get and install.

Until Nokia relicenses Qt to something like the LGPL - many of us would welcome that! - GTK will remain the library of choice in situations like this.

Actually, Qt 4.5 _IS_ LGPL You may wanna read this: http://www.qtsoftware.com/about/news/lgpl-license-option-added-to-qt

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

A more reputable confirmation of the March release date.

Interesting point.

Nokia DOES presume to tell you what you can do with your LGPL code. Read this quote:

"Can I switch from using Qt under the LGPL to commercial afterwards?

"Users of the LGPL versions of Qt need to comply with the LGPL licensing terms and conditions. Qt's commercial license agreement contains a restriction that prohibits customers from initially beginning development with the LGPL licensed version of Qt and then transitioning to a commercial version of Qt."

Wow! How do they know how you "initially" began development?

It seems as though some lawyer or marketing guy with no technical understanding got involved.

How does this affect the open source cross-platform GUI toolkit WxWidgets?

and don't forget a goodie - it makes porting MFC apps reasonably simple. Won't nobody think of the poor, recently-discarded Windows C++ GUI developers :)

(any excuse to get them to port stuff to Linux, now if we can just get a good kernel replacement for WaitForSingleObject...)