Qt Opens Source Code Repositories

sobral writes "Following the announcement of the LGPL license model, since yesterday the Qt source code repositories are open to the public together with their roadmap. The contribution model is online and will enable developers from the community to submit patches through a single click process, avoiding the previous hassle of sending in signed paperwork. The code is hosted at qt.gitorious.org and an instant benefit of this launch is that Qt Software has been working together with Gitorious maintainers for the last four months to improve Gitorious and all these new features are already submitted upstream."

Comments

Re:QT Looks Like Shit

[NoStarchPlox]

Yes, QuickTime is definitely shitty but what does that have to do with Qt?

Re:Should be a followup, actually

[skeezixcodejedi]

Ignoring the enormous benefits of a single codebase for Windows, Linux/BSD and Mac OSX of course. (Yes, people still make applications for desktops and notebooks .. not just netbooks, PDAs/smartphones)

Qt GTK

[Anonymous Coward]

I hope Gnome switches to Qt one day, its so much nicer than GTK.

Re:Should be a followup, actually

[NoStarchPlox]

You must be a bit behind the times as Qt no longer emulates a native look-and-feel but uses the native widgets of the platform.

Re:I'm at a loss for words.

[dwater]

> I'm at a loss for words.

The word you're looking for is 'too'.

QT is used on cell phones as well

[DomNF15]

I worked on the software for a Motorola unit that used Qt UI framework. What is interesting is that Moto moved away from Qt when one of their major competitors (Nokia) bought Trolltech (the company that makes Qt). Two years later they open source it, I don't quite get it...

Re:QT is used on cell phones as well

[NoStarchPlox]

Qt was open source long before Nokia bought Trolltech. The issue was that the original license they used didn't allow you to redistribute modifications and then the subsequent Q Public license, which was a free software license, wasn't compatible with the GPL. Then in 2000 Trolltech released it under the GPL. So I'm not sure where you got that Nokia open sourced Qt, since it had been open source for close to a decade before Nokia came along.

Re:QT is used on cell phones as well

[larry bagina]

Qt was Open Source in that it was GPL, however trolltech was dual licensing it. Being GPL, it was toxic to anything but GPL programs, which meant closed source (or even non-GPL open source) would need to pay for Qt.

Nokia relicensed Qt as LGPL which makes it usable by non-GPL programs.

Re:QT is used on cell phones as well

[NoStarchPlox]

Yes, I know Nokia tri-licensed it with the LGPL as an option. The point was that the GP was making it sound like it was closed source before Nokia came along which isn't true since anyone could freely look at the source for a decade before that.

Re:QT is used on cell phones as well

[salimma]

Qt had a license exemptions for the major open-source licenses, which makes the licensing situation really confusing. Since one of the exempted license was BSD, arguably their "holey" GPL license is effectively just the LGPL license, since you can write a wrapper around the parts of Qt that you want, BSD-license it, and write a proprietary app that uses it.

On the other hand, unless you jump through these hoops, there will be perfectly fine open-source licenses that are LGPL-compatible (but not GPL compatible) that you cannot use, either because its a minor license that Qt's lawyers have not seen, or because it's too new. It took a while for Qt to be GPL3 compatible, for example.

Re:QT is used on cell phones as well

[innocent_white_lamb]

Is the lgpl licensing retroactive to previous versions of QT, or just going forward?
 
Some compilers work with a previous version of QT and have no immediate plans to update to new QT versions. Therefore, does the lgpl QT licensing apply to programs generated with those compilers?

Re:Should be a followup, actually

[Anonymous Coward]

Symbian is dead? Having 47% of smartphone sales worldwide in Q4 2008 means you're dead? Really?

Re:Should be a followup, actually

[entgod]

You forget who owns Qt. Symbian is not really dying yet (come on, the biggest mobile phone manufacturer uses it in all its smartphones), if it were, it would mean that Qt were becoming more relevant as, you know, the day symbian dies is the day that nokia switches to linux (not the android kind).

Re:Should be a followup, actually

[vrai]

Yes - because web frontends are the silver bullet that solves all of our client-side needs. In fact, why bother having general purpose computers out side of data centres? Instead we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals. Luckily the infinite bandwidth and uninterrupted global connectivity on offer, combined with the well enforced WWW standards means that even the most complex of GUIs can be provided via the browser. Why do we even bother with proper operating systems when everything man could need from a computer can be provided via a TCP/IP stack and XULRunner?

Oh wait, because even the best web based GUIs are primitive and unresponsive compared to a well designed, well implemented local interface. With Qt it's possible to create a native GUI that runs on all major desktop platform (and even Solaris) with less effort than it takes to get even a moderately complex web interface running correctly on IE, Firefox, Safari, Chrome and Opera.

Web interfaces are excellent for simple tasks like email and feed reading; they are terrible when deployed in more complex arenas. Even when you take in to account proprietary, binary only workarounds like Flash and Silverlight.

Re:I'm at a loss for words.

[entgod]

Too late for what? Too late for it to become adopted? Have you heard of the K desktop environment?

Re:Die to unify

[noundi]

That horrible GNOME/GTK of yours drove Trolltech into relicensing Qt to GPL. Thus Qt, and even Linux, wouldn't even be close to where it is today without GNOME. Say what you want about Ubuntu, but it's a fact that FOSS (and in particular Linux) awareness has grown immensely due to its contributions, and I doubt Kubuntu is to thank for this. It's a question of flavor, and I like to have options. Both projects thrive from eachother and the constant "battles" drive devs to find out new creative ways in order to be "unique" and innovative. Sure there's an advantage to cooperation, but without competition there's no pressure.

Re:Should be a followup, actually

[Anonymous Coward]

Yeah sure...

>> Sales of Linux netbooks collapsed.

Proof? Sure lots of netbooks are Windows, but that doesn't mean sales of Linux models aren't increasing with the market segment.

>> Google is providing a standardized UI on top of Linux.

Incredibly immature project, and isn't even close to a competitor to Qt on anything but embedded.

>> Symbian is dead.

Well, there are millions of devices out there still with Symbian, but I agree it probably has little future.

>> Basically, there is very little need for a specialized UI toolkit like Qt

Qt is not a specialized UI toolkit. It is a general class library for C++ that happens to include UI classes.

>> now that there are both fewer platforms for it to run

Qt runs on more platforms now than ever before. I don't know what you're talking about. Symbian, WinCE, Windows 98 to 7, Linux (normal and embedded), and Mac (with Cocoa even). Name another platform that can do that.

>> and more mature competitors on the remaining platforms.

Like what? Each platform has their own thing, but unless you feel like implementing your interface 5 times, that's not really an option.

Re:Should be a followup, actually

[pherthyl]

You should tell my customers that. I've never received a single complaint about look&feel on my Qt4 software in 4 years.

Re:I'm at a loss for words.

[maxume]

Is that from Men in Black?

Re:Should be a followup, actually

[NormalVisual]

Qt offers quite a bit more than just an abstracted UI model. Being able to have a totally common codebase across a number of platforms for a given application (including lower-level network code, threading, non-UI graphics manipulation, file I/O, printing, etc.) is a great help.

The only thing holding me back from totally adopting Qt was the outrageous licensing cost, not anything lacking in the toolkit itself. With it having gone to LGPL now, that is no longer an issue.

Re:Die to unify

[Anonymous Coward]

Motif vs OpenLook: Sun capitulated to let Motif win.

Don't know why, but the phrase "Motif vs OpenLook," make me think of two retards wrestling in a vat of pudding.

Re:Should be a followup, actually

[Anonymous Coward]

Qt is not just a toolkit that replaces MFC, it's a whole set of libraries that can do much more (eg. containers, signals & slots, auto ptrs, sql relational mapping to objects, networkprotocols, and so on and on)

IMHO Qt is what Java promised to be, a truly platform independent development system. I love it, especially since they fully open-sourced it (before only on Unix platforms). And now with qtcreator, even the Visual Studio guys don't have an excuse anymore not to use it.

So, please don't say Qt is just a toolkit, it's much much more.

The first things to do

[master_p]

1) replace Qt memory management with TR1::shared_ptr (or boost).

2) replace Qt collections with STL collections.

3) replace Qt threads with boost::threads.

4) replace Qt signals and slots with boost::signals.

In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

Re:The first things to do

[Clith]

Qt's collection classes are API compatible with STL. So I would argue that it plays nicely already. I prefer Qt containers to STL containers because Qt's classes have been optimized. STL has some issues with performance.

Re:The first things to do

[Futil3]

Better than STL?

An STL implementation has a few things going in its favor:

STL implementations use best-of-breed algorithms.
The designers of STL implementations are, more than likely, domain experts.
Those domain experts were entirely focused on the mission of providing a flexible, powerful, and efficient library. This was their primary task.

But then again. (only) You know your own usage scenario, data types and platform. That knowledge can probably offer some profound short cuts and optimizations.

Re:The first things to do

[ultrabot]

1) replace Qt memory management with TR1::shared_ptr (or boost).

2) replace Qt collections with STL collections.

3) replace Qt threads with boost::threads.

4) replace Qt signals and slots with boost::signals.

In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

So it doesn't play nice with them right now?

You'll be waiting for Qt5 for that kind of stuff.

I think this will be about the time C++0x gets mainstream. Breaking Qt source compatibility before that is just not worth it.

Re:The first things to do

[pyrico]

1) replace Qt memory management with TR1::shared_ptr (or boost).

For the core purpose of Qt (GUIs), Qt's various memory models work very well. Every widget is a QObject and by default they fall into parent child releationships that include life-cycle management of your objects. Why would you want to mess up that clean model?

2) replace Qt collections with STL collections.

Another unnecessary generalization. I actually much prefer Qt's collections because A) they are implicitly shared (you can pass them around without getting deep copies) and B) they have one clean and very efficient implementation across platforms, so I don't have to worry about the memory and performance characteristics of a MSVC std::map vs a GCC std::map. Also they are much cleaner to work with and don't require hideous iterators every step of the way.

3) replace Qt threads with boost::threads.

Again, Qt threads will perform as good as native threads on each platform, something you can not guarantee with pthreads (with weaker windows support). Also, QThread and friends (QMutex, QSemaphore, QWaitCondition, QThreadStorage) are very C++ oriented and stylistically much cleaner than pthreads and even go beyond it in scope.

4) replace Qt signals and slots with boost::signals.

This is probably the most valid argument, and there is some legacy reasons why Qt had to throw a meta object compiler on top of C++ to get this to work 18 years ago. But in the mean time, that moc layer has paid off in gold. Now you the ability to get free introspection on classes of your choosing which is vital in making C++ suck less in well designed programs (i.e. can do automatic class instance serialization etc).

In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

In other words, Qt is a great one-stop-shop for cross platform development and I wouldn't change a single thing you listed. In fact, if you write your C++ code in stylelistic keeping with the Qt libraries, you avoid most of C++'s warts and can even enjoy the language.

Re:The first things to do

[mzs]

shared_ptr and QPointer don't play together so nicely though. Also QPointer tends be slower than shared_ptr when I only need what shared_ptr does. To get them to work together I end-up copying things between the two or just end-up not using shared_ptr at all.

Re:The first things to do

[PerlDudeXL]

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

boost::signals doesn't work across threads (this is docuemented in the boost API).

Throwing both Qt and boost APIs together would create an ugly mess.

Re:The first things to do

[harry1701]

The use of boost will greatly limit the amount of supported platforms and compilers. Replacing Qt collections with STL will kill the embedded branch, where code expansion counts. It'll also not be nice for the deskop - imagine loading a Visual Studio plugin while another plugin is loaded that uses another STL implementation -> boom, symbol clashes.

Re:The first things to do

[CortoMaltese]

I haven't really followed up on the recent developments of Qt or STL, but I was under the impression that Qt containers implement copy-on-write while STL ones don't. Correct me if I'm wrong.

I don't think it's an exactly clever idea to be unnecessarily copying containers in the first place, but no matter what it makes Qt to STL migration hard if the Qt applications are filled with assumptions on copy-on-write.

Re:The first things to do

[Brandybuck]

Qt is Object Oriented through and through, with only a hint of GP. There's no need to use functors. Threads are defined by subclassing QThread, not passing in a functor. Signal/slots are implemented as GoF Publish/Subscribe, not functors wrapping a member function pointer.

The fact of the matter is that most C++ developers just don't know function objects. I've been doing an informal survey for the past two years, asking clients about functors. My informal results seem to be that only one in twenty know what a functor is. They just aren't used much out in the non-academic world. I'm not saying this to belittle Boost, I think it's a great tool set. But one must recognize reality for what it is.

But don't worry about it! Nothing in Qt denies you the ability to use the STL or boost::signals or boost::threads. There are a few caveats of you try to mix thread types, but nothing fundamentally stops you from using them.

Re:The first things to do

[Brandybuck]

Almost, but not quite. STL containers tend to be optimized for speed, while Qt containers are optimized for size. There is an old Qt Quarterly that discussed the implementation of Qt's containers what was quite interesting. Go online and search for it.

Re:The first things to do

[oever]

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

Re:The first things to do

[master_p]

1) parent-child relationships are not enough in many cases where objects are shared across multiple domains.

2) nowadays STL is as efficient as it gets across all major compilers - plus you'll get big speed ups with the upcoming changes in C++0x.

3) I did not say anything about pthreads. I said 'replace Qt threads with boost threads'.

4) Introspection has nothing to do with signals and slots. Qt signals and slots are very limited in what they can do.

Re:The first things to do

[master_p]

Boost::signals doesn't need to work across threads because it can be made to work across threads with very little code. All that you need is a single template class which wraps the signal into a QEvent.

No ugly mess if whatever common functionality they have is removed from Qt.

Re:The first things to do

[master_p]

Qt works on Windows, Mac, Linux/X11, embedded Linux, Windows CE (according to Trollech).

Boost works on almost any modern operating system, including UNIX and Windows variants (phrase copied and pasted from boost site).

So I think boost works in more platforms than Qt.

Re:The first things to do

[master_p]

1) functors and lambdas simplify code greatly.

2) it's time for C++ devs to know about functors.

3) I can't bind functors with Qt signals.

Re:The first things to do

[ardor]

Without boost, you don't get stuff like bind, lambda, phoenix, enable_if, any, graph, GIL, xpressive, spirit, fusion, ....

I've heard the "massive amounts of code" gibberish several times. You *don't* have to import boost into your own project. Keep it an external dependency. Since a substantial portion is header-only, all that is necessary is another include path.

Oh yes, you may try to write all this code on your own, but unlike your homemade stuff, this has already been tested and is mature, thanks to the peer review in boost. This is especially true with boost.threads; any threading library must be very thoroughly tested. Do you have the time to do that?

Among the only libraries where I partially agree are signals and program options. Note though that signals has been superseded by signals2.

Re:The first things to do

[ardor]

Note however that when I showed C++ coders what function objects are, they liked it every time. It is somewhat strange at the beginning, but once you grasp it fully, you never want to put function objects, bind, lambda etc. away.

Re:The first things to do

[spitzak]

And replace the wchar_t Qt strings with stl::string!

Re:The first things to do

[21mhz]

In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.

As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cause bloat and are rife with non-obvious "undefined behavior" (a byword in the C++ standard).

There are reasons why Qt does not submit to all "foundations for developing C++ code these days".

Re:The first things to do

[pherthyl]

>> 1) replace Qt memory management with TR1::shared_ptr (or boost).

Why? To add another dependency?

>> 2) replace Qt collections with STL collections.

Collection classes are already API compatible. Feel free to not use the Qt ones.

>> 3) replace Qt threads with boost::threads.

Again, zero logic here. Boost is just another C++ library. It is not any more or less standard than Qt.

>> 4) replace Qt signals and slots with boost::signals.

Qt Signals have a lot of advantages over boost signals (and some disadvantages). Until boost signals can do everything Qt signals can, replacing them would be stupid.

>> In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

The STL doesn't provide anywhere close to enough for modern application development and it never will. So why should I use part of it when it will never be enough? I'd much rather use Qt for everything and have one consistent API that works nicely together and has fantastic documentation. I haven't used boost or the stl for anything serious in quite a while. For the development I do, the stl is obsolete.

Re:The first things to do

[Carewolf]

So you want to replace something simple and useful with something convoluted and useless?

Just because it is a standard doesn't mean it is better. Especially if it is something no one uses because it is incredibly crappy like STL containers. (Boost is really cool, but also convoluted).

Re:The first things to do

[PerlDudeXL]

yes, but QtConcurrent is more like a scheduler. QtConcurrent::run internally re-uses threads
and runs your given functor object.

I was thinking about something like QThread(Functor), without the need to subclass
QThread and implement a run Method (I'm aware about the exec() call in QThread::run).

Re:The first things to do

[larry bagina]

Again, zero logic here. Boost is just another C++ library. It is not any more or less standard than Qt.

We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) and will be in the new C++0x Standard now being finalized. C++0x will also include several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for TR2.

Boost is more standard than Qt.

Re:The first things to do

[moon3]

Point 4).. get rid of that (*****!) MOC compiler. You can't even debug your sources, MOC creates something else for you. Mandatory h/cpp pairs? We have been considering QT, but there is so much problems to run the thing..

Re:The first things to do

[ardor]

Now thats amusing. Overwriting an old binary with a newer one is hard to do now? I have written software that supports updates. I have yet to encounter any of the problems you mentioned. Yes, I frequently use STL and Boost in embedded environments. The main reason why I don't use them more often are the compilers, which tend to be g++ 3.x. (However, several large manufacturers already have g++ 4.1, so things are improving here.)

The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for their own errors. C++ is far from perfect, but not for the reasons you mentioned.

Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.

Better luck next time.

Re:The first things to do

[ardor]

No one uses STL containers?
Are we talking about the same C++?

Don't tell me you honestly use self-made containers.

Re:The first things to do

[ardor]

1) does not make any sense. The Qt memory management is both simple and absolutely perfect for GUIs, which naturally tend to be object oriented. Having parent object clean up their children is the right way to go.

4) Is not trivially possible, because Qt signals and slots and boost::signals do not cover the same functionality. Qt signals/slots allow for introspection, so it is possible to do IPC and RPC with them. In addition, they are thread-safe by storing Qt signal emissions on Qt's main loop.

boost::signals does not allow for any of these features. signals2 is thread-safe, but not in the way Qt signals do it.

2) and 3) are "nice to have", but not important.

What matters is the cost-to-benefit ratio Qt delivers (cost = time to integrate, study etc.) and if it translates into a net gain. Not one of these four points help achieving this goal. I personally use both Qt and Boost, and while I do want to see function objects supported as slots for example, I can live with moc, etc. precisely because Qt offers so damn much. And, as said, in the end, that is all that matters.

Re:The first things to do

[pherthyl]

That doesn't make boost more standard than Qt. The parts of boost that end up in the standard will be more standard than Qt (of course then they will no longer be part of boost).

Everything that is in boost is not a standard. If it was in the standard it wouldn't be in boost.

Re:The first things to do

[zander]

while you can't bind functors with Qt signals, you can mix boost and Qt signals without problems so there is no limitation.

Re:The first things to do

[21mhz]

Now thats amusing. Overwriting an old binary with a newer one is hard to do now?

Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.

Yes, I frequently use STL and Boost in embedded environments.

Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.

The sentence about "real exceptions" is entertaining as well. Good code avoids all of the problems you mentioned. Honestly, it is sickening to see how many people blame their language for
their own errors.

The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.

Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.

I did name the few that I feel are important.
Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid. It tells you something when workable implementations lag years behind the approved standard.

Re:The first things to do

[ardor]

Overwriting all binaries that depend on your library when the inlined implementation needs to change (e.g. because a security-critical bug has been found there), is.

Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.

Yes, I frequently use STL and Boost in embedded environments.

Your clients can congratulate themselves with the file size and memory footprint cost of all the inlined/instantiated code.

Indeed they can, since it is small, fast, and uses little memory. The trick is to use templates, STL, boost correctly. Besides, newer gcc versions reuse instantiated code much better then older ones.

And, finally, embedded devices of 2009 are lightyears ahead of embedded devices of 2004. It is becoming quite common to have more than 16 MB and 300 MHz for a web radio, for example. A lot of software stacks are huge, not because of boost, but because they include a lot of stuff, and don't care about filesize, precisely because memory costs are dropping.

The problem is, it's too easy to make these errors, unless you're a card-carrying member of the C++ Lawyer Bar Association. A lot of people have since learned that it doesn't have to be this way.

You don't have to be "a card-carrying member of the C++ Lawyer Bar Association", you just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.

Qt does not submit to STL and boost for a variety of reasons. You did not name any of them.

I did name the few that I feel are important.

What you feel is irrelevant. You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.

Yes, there are also historical reasons: Qt was developed at a time when the compiler support for the more advanced C++ features was far from solid.

This is correct. The other reason being that many Trolltech customers still use outdated compilers.

It tells you something when workable implementations lag years behind the approved standard.

This happens to any language. For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.

On a sidenote, C++ code that looks like Java is something I personally abhor. Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this. And I cannot understand why anybody would prefer writing C++ in the old, Java-like style. The only objective reason is a restriction to an old compiler.

Re:The first things to do

[Carewolf]

No, I usually use Qt containers, or whatever containers is used in the library I currently work with. I know very very few C++ libraries that uses STL containers. Most uses their own containers or those of a related frameworks like Qt.

Writing you own containers is only for special cases, or when developing new frameworks for other developers to use.

Re:The first things to do

[21mhz]

Which is why you should have a system that automatically designates the changed binaries. This is what I did. The build system is able to package changed files. The package is the update. Transmit, unpack, done.

So, you have never offered your libraries to an unknown number of third-party users in, say, a Linux distribution. When a problem is discovered in a library, the header-heavy "modern C++" approach would suggest telling the world to recompile. With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged. Also good for memory footprint, instruction cache pressure, startup time, and file sizes. Throw hardware at it as you wish, but your competitor may once outperform you on something that costs half as much.

You just have to understand exceptions correctly. I have yet to see what is so extraordinarily difficult about them.

I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".

You stated that "these are the reasons why Qt does not use Boost/STL". You were obviously wrong.

Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.

For example, SCons has to restrict itself to a subset of current Python versions to be able to run on ancient setups with Python 1.5.x.

And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..

Once one starts using function objects and generic programming, this "old style" C++ looks and feels dated, inefficient, bloated, primitive. The vast increase in productivity confirms this.

Tell that to Erlang fans :) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.

Re:The first things to do

[oever]

That's easy enough to make:

template
class Z : public QThread {
private:
const T t;
public:
Z(const T& t_) :t(t_) { start(); }
void run() { t(); }
};

Re:The first things to do

[ardor]

With a better isolated ABI such as the one found in Qt, you just update the shared library package, and all applications may continue on unchanged.

Unless something changed in the API (not the ABI - the API) that, say, changes the stack frame in classes. Then you must recompile, or your shiny new shared libraries will cause the application to crash. Do you really think this is better? I went this route once. I do not look back. Even with versioning things can get complicated, and ugly.

And the reasons for C++ compiler vendors to restrict themselves from implementing the ANSI/ISO C++ standard fully were?..

This is about why Qt still restricts itself to a subset, not about compiler vendors. The historical reasons are well-known. Today's reason no.1 is support for old compilers.

Nobody denies that C++ parsers are exceedingly hard to write. But lets stick to the subject, shall we?

I understand exceptions that have a full-fledged execution environment to support them. With C++, you have to care exceedingly about throwing an exception in certain methods, such as a constructor (and goodness forbid admitting an exception in a destructor). Also, if your software has some non-C++ parts and those call back to the C++ code, be sure to catch all exceptions your callbacks might throw and rely on good old ways of error reporting, or you'll have leaks and "undefined behavior".

True, however look at these cases carefully. Exceptions in destructors are known to cause problems. Exceptions from/to non-C++ parts (for example, Spidermonkey) is also a delicate issue. This is well-known, too etc. in all summary, exception issues are the cause for perhaps 5% of all errors I encounter.

Please go back in the thread and reread my comments carefully before misquoting and misinterpreting them.

Okay, so you referenced Boost/STL indirectly. My point still stands. Qt did not reject templates because of your perceived bloat and "emitting mountains of non-shared, hard to update code". Qt rejected templates because the compilers back then just didn't support them, and because Moc gives them thread safety and introspection abilities, which is useful for the Designer and for IPC/RPC.

Tell that to Erlang fans :) That's why really convenient and productivity-friendly languages like Python and Scala are getting ever more popular, and even Java gains in this respect, without turning into the disaster that C++ ended up to be.

At last, we are reaching an agreement. I fully agree that C++ is a mess. However, there is nothing out there that can fully replace it. There are languages that:
- a bad joke, but have powerful toolchains (Java)
- have interesting features, but have issues with patents, and still lack the ability for fully generic programming (C#)
- are dynamic, which allows for anything imaginable, but are far too slow (Python, Ruby)
- contain functionality for functional and generic programming far beyond C++, but are way too obscure (Haskell, Lisp, OCaml, Scala, Clean)
- are still a bit of an underdog, and aspire to supersede C++, but have a real focus problem, because "being better than C++" is not really a goal (D)

Note that for your typical business application, any of these will do, however languages with almost no features like Java will force you to write a lot of extra code, because essential stuff like lambda is not present.

However, C++ is extensively used in high-performance areas like scientific computing, and is one of the few languages able to beat Fortran in this domain. But without template meta-programming and generic programming, it is not possible to use both high-level and low-level featuresets in the same project; this very contrast is one of the most important features of modern C++. I can write my code to, say, solve Navier Stokes equations, and the code looks in fact like said equat

Re:The first things to do

[Brandybuck]

1) functors and lambdas simplify code greatly.

While they may result in some extreme terseness, they do not simplify. If you are doing an operation that is best represented by lambda functions, then use lambda functions. Otherwise keep them in the bottom of your tool chest.

Re:Should be a followup, actually

[rackserverdeals]

You have to understand the "ABC is dying/dead" mentality.

It doesn't matter how much market share you have, only that your market share is decreasing and some smaller technology which they favor has an increasing market share.

IE is dying because Firefox use is increasing in the market and IE is declining.

Unix is dying because Linux is growing and Unix is not.

It doesn't matter that at the rate of decline it would take 20 or more years for whatever it is to die. Or that the decline may be arrested. Saying something is dying is usually misinformed or more likely spreading FUD to hasten the decline.

Old technology with 80% market share drops down to 79% marketshare and new cool technology jumps up from 2% to 3% market share and old technology is declared dying. Here's a perfect example.

MATLAB on OS X won't suck now?

[myNameIsNotImportant]

Maybe now that QT is LGPL, Mathworks will finally transition MATLAB on OS X out of X11 and make it behave like a proper OS X app. ...One can dream....

Re:MATLAB on OS X won't suck now?

[guruevi]

MATLAB won't transition to anything. It's the only player in the market and is about as bad as Microsoft as far as licensing goes. Since they switched to activation for their licensing I have been looking for competitors. I've even had to crack some of their systems in order for it to keep working (some with an official crack, others with a not-so-legal crack). The Mathworks knows they have all educational institutions and a lot of engineering labs by the balls and can twist them however they want.

Octave is good but is not a real competitor because it isn't fully compatible (which would mean they would need to break stuff in order to emulate the backwards-compatibility of MATLAB) and it doesn't have all the necessary toolboxes scientists like to use.

Re:MATLAB on OS X won't suck now?

[chthonicdaemon]

I reckon most of the Matlab frontend is Java. As near as I can tell, only the plotting part uses X at all on OS X. That said, the insane license manager they use for Unix-like platforms (as opposed to a very simple activation code in Windows) has led me to scipy. I have not looked back much, except for the interactive graphs they added to the newer releases.

Re:MATLAB on OS X won't suck now?

[sys.stdout.write]

As somebody who has just spent the morning trying to work out inconsistencies in wxWidgets between Windows and Linux, let me just say: shush. It's not that wxWidgets is bad, but Qt's we-are-going-to-implement-everything-ourselves-so-it-acts-the-same-on-all-platforms approach has merit.

Re:MATLAB on OS X won't suck now?

[JimProuty]

Perhaps use the lower-cost, well-supported Igor Pro, instead? http://www.wavemetrics.com/ Disclaimer: I work there :-)

Re:MATLAB on OS X won't suck now?

[mzs]

Somebody mod this insightful.

There are also incompatibilities with MacOS X. It really is a lot in regards to feel to how Java was circa '98 where you have different versions of wxWidgets and on different platforms really affecting how you have to write the code so that it works right on everything. Also long ago, when they were still wxWindows, they dropped the support of wxX11 and had you use wxGTK on unix-alikes. The wxX11 code stayed so close to working, only little tweaks are needed every now and then, it is a shame that that branch went dead around 2 years ago. The reason is that you need a version of GTK+ on any box running a wxWidgets program now. I have never in recent years been able to compile a static library of what I needed of GTK+ so I could simply link it to the app. You get into real problems where wxWidgets does not work right due to the way that GTK+ was compiled or the version it is on a particular system and I have no good way around that except for gross LD_* overrides in shell scripts. Those libraries are HUGE too.

Re:MATLAB on OS X won't suck now?

[synthespian]

Scilab is developed by a top French academic institution and has behind it an industry consortium support.

http://www.scilab.org/

Re:MATLAB on OS X won't suck now?

[myNameIsNotImportant]

I'm afraid you're right. Had it not been for MATLAB's tremendous mindshare (existing code) in academia/engineering co.'s, I doubt they would sit as pretty right now.

Next time I have to rearchitecture code/start anew, I'm sticking with scipy. Octave is great, but... yeah, as you say, not a real option (it's not drop in replacement, and if I have to rewrite code, I might as well pick a proper language).

Re:MATLAB on OS X won't suck now?

[Hognoxious]

Scilab is developed by a top French academic institution

My gut feeling is there's a contradiction in there. Either I haven't spotted it yet or the choice is confusing me.

Re:Should be a followup, actually

[daem0n1x]

My company develops cross-platform applications for Windows, MAC and LInux in C++. Qt is one hell of a cross-platform UI toolkit.

Re:Should be a followup, actually

[AnyoneEB]

Cool. How do I get Amarok and k3b to use GTK widgets on my computer?

Parent is Troll, mod down

[mangu]

Google is providing a standardized UI on top of Linux

Then let the better UI win. Will it be one that's Java-only, or one that can be used in its native C++ environment or with Python, Ruby, or even Java?

Symbian is dead.

Even if it were true, and with about half of the smartphones in the world running Symbian I don't think it is, what has that to do with Qt?

there is very little need for a specialized UI toolkit like Qt now that there are both fewer platforms for it to run

Huh? There are more platforms than ever for Qt to run. Do you mean Microsoft isn't delivering operating systems anymore?

Re:Should be a followup, actually

[Tdawgless]

Android.

Re:Should be a followup, actually

[NoStarchPlox]

Since when was GTK+ a native graphics api? Oh wait, it's not. Qt uses Xlib on an X Windows System which is the native graphics API.

Re:Should be a followup, actually

[Fujisawa Sensei]

Unix is dying because Linux is growing and Unix is not.

Perhaps you should let Steve Jobs and Apple know about this.

Re:Should be a followup, actually

[Fujisawa Sensei]

Google is providing a standardized UI on top of Linux.

Remember how CDE was supposed to be the standardized UI on top of X?

Remember how successful it was?

Re:Die to unify

[Saffaya]

Just to clarify :

Nokia acquired TrollTech.

Nokia then decided to license QT under the LGPL, it wasn't a decision made by TrollTech while they were still independent

Re:Should be a followup, actually

[Jurily]

Qt offers quite a bit more than just an abstracted UI model. Being able to have a totally common codebase across a number of platforms for a given application (including lower-level network code, threading, non-UI graphics manipulation, file I/O, printing, etc.) is a great help.

Not to mention an XML parser, localisation and Unicode support by default, a great scripting engine, MD5 and SHA1, and awesome documentation, while the whole API is built to encourage best practices.

About the only thing I'm missing is archive handling with QDir. Including bzip for a fully functional NMDC client is so last year :)

Re:Die to unify

[pjt33]

GP is talking about GPL. You're talking about LGPL. I'm not sure whether you think you're correcting GP or expanding on it. Could someone clarify in a way which leaves the situation clear?

Re:Should be a followup, actually

[garvon]

qt 4.5 does have a gtk theme that uses gtk to draw the widgets. It allows me to continue using qt applications and have them match my desktop now that i no longer find kde usable as a desktop. The applications are still 1st rate.

Re:Die to unify

[ultrabot]

Qt vs GTK: Who is going to capitulate to let the other win?

One thing is certain - it sure as hell won't be Qt.

It survived under QPL and GPL - it's basically unstoppable under LGPL (and relavite "financial independence" under the Nokia umbrella).

Re:Should be a followup, actually

[elashish14]

Excuse me? I can run programs on my desk? This qt things sounds amazing!

Re:Should be a followup, actually

[robmv]

QT emulates the platform widgets, but uses the platform API (if it exists) to draw them, all event processing and widget behavior is done by QT, much like Java Swing do. previous QT version emulated the widget look too, but that was before even Windows APIs provided themes APIs (Windows XP)

TGI Git

[iluvcapra]

I have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable. With the way Git works, and particularly with the implementations the hosting companies provide, it's very easy to fork a project, make the changes you want, and always have the power to commit to a remote repository that not only keeps track of all your commits but ALSO how all your commits relate back to the original forked project...

Instead of downloading someone's tarball and (maybe) emailing them a diff (or just posting your own duplicate of their source with your little changes), it's like you're making a shadow copy of a projects source, where you have all the control but no information is duplicated or lost.

Re:TGI Git

[ultrabot]

have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.

However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.

It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.

Re:TGI Git

[iluvcapra]

Where does Hg succeed over Git? My understanding is that a lot of people really don't like the way git merges..

Re:TGI Git

[ultrabot]

Where does Hg succeed over Git? My understanding is that a lot of people really don't like the way git merges..

- It gets by with far smaller amount of commands, that are generally understandable and do "what you would expect" (whereas with git, to get "what you would expect" you need to do some serious study).

- It reports failures in a terminology that a normal person can be expected to understand.

- It's implemented in Python and little C for speed, not a hodgepodge of every language known to man.

- Probably deriving from previous point, it has a first-class windows implementation

- It gives revisions in local repo a running index number. It's transient, but often handier than using hashes all the time.

That being said, ease is the single most important benefit. This is important if the repo is being used by people from different backgrounds. Weigh the amount of hand holding you'll need to do for people new to the tool, and it becomes surprisingly important.

Re:TGI Git

[reemax]

Linus, is it you?

Re:TGI Git

[drinkypoo]

Just speaking as someone who occasionally downloads some source code snapshot or other and builds it, git is crap and svn is the only SCM worth using. If git craps in the middle of initially fetching a repo it can corrupt itself. svn is the only SCM that seems to have ANY ability to recover from a fault. A non-fault-tolerant code repository is worse than useless.

Re:TGI Git

[ewanm89]

Git was always known for its performance at the start. I admit haven't used mercurial more recently but it use to seem to be a bit slower than git.

Git is a bit of a pain on windows but I always preferred git out of the two. At least we have a choice.

Re:TGI Git

[fbriere]

If git craps in the middle of initially fetching a repo it can corrupt itself.

I'm curious, could you provide some details on this? The way that git operates, fetching objects individually, I find it dubious that it would fail like that.

svn is the only SCM that seems to have ANY ability to recover from a fault.

You're kidding, right?

I remember when I switched from CVS to SVN[*]. On more than one occasion, while importing my old work, svn would just choke and die, claiming there was something wrong within my .svn directory. At that point, I had to nuke the working directory and checkout a fresh copy.

Obviously, no data was ever lost (since it was only the working copy that was hosed), but it made me seriously doubt Subversion's ability not to screw up its black box database.

[*] Not too many years ago -- this must've been around SVN 1.3.

Re:TGI Git

[drinkypoo]

I'm curious, could you provide some details on this?

Nope. I only use it to download repositories because I'm not really much of a programmer. I (thankfully) encounter git pretty rarely, although it is unfortunately gaining in popularity. Suffice to say that it has happened to me personally on at least two occasions, back when I was a modem user and had lots of communications problems.

svn is the only SCM that seems to have ANY ability to recover from a fault.

You're kidding, right?

Nope. I've had git shit itself on me a couple times, so obviously they don't have it right. And I've only ONCE had svn get into a wacky state when I was doing a get, and all I had to do was nuke the .svn directory that it was working on at that time. The only other problem I've had was once having to make tmp dirs inside the .svn dirs because of a kind of lame version migration, but that was so easily fixed it almost doesn't bear mentioning.

Re:TGI Git

[fbriere]

I only use it to download repositories because I'm not really much of a programmer.

I assume you do a simple "git clone <url>", then? Did you use --depth or any other option?

Suffice to say that it has happened to me personally on at least two occasions, back when I was a modem user and had lots of communications problems.

Was this a long time ago? Git has matured a lot since its infant years (2005-2006).

I've had git shit itself on me a couple times, so obviously they don't have it right.

From what I've seen of the Git development team, I'm sure they would be eager to correct such a flaw.

If I understand you correctly, you would run git-clone, and lose the connection in the process? This would leave you with an incomplete directory, and running git-fetch in it would fail?

Re:TGI Git

[drinkypoo]

I assume you do a simple "git clone ", then? Did you use --depth or any other option?

Yes and no, IIRC.

Was this a long time ago? Git has matured a lot since its infant years (2005-2006).

Nope, just a few months ago. I haven't had a problem since I upgraded to broadband which I finally managed to locate in my area (a local WiFi ISP.) But handling bad connections gracefully is a must.

If I understand you correctly, you would run git-clone, and lose the connection in the process? This would leave you with an incomplete directory, and running git-fetch in it would fail?

You have put it succinctly.

Re:Should be a followup, actually

[Hognoxious]

It's dead as in the "doesn't originate in the USA" sense.

Re:Should be a followup, actually

[Jurily]

GTK is a toolkit on the same semantic level Qt is. It's not a platform.

Re:QT Looks Like Shit

[Frnknstn]

I wasn't aware that software could smell at all. Unless...

>>> import odour

Oh Python, I love you...

Re:Should be a followup, actually

[Hognoxious]

Android is an operating system, not a GUI.

Re:Should be a followup, actually

[Tetsujin]

Yeah sure...

>> Sales of Linux netbooks collapsed.

Proof? Sure lots of netbooks are Windows, but that doesn't mean sales of Linux models aren't increasing with the market segment.

Can't offer proof or even statistics - but I think the Linux netbook thing is basically over. For a while, going with Linux instead of Windows made a significant difference in the price of the machine - and Linux could do the "netbook" job (i.e. run a web browser, etc.) just fine.

But since people wanted Windows on these machines (particularly as their storage specs improved), Microsoft made licensing Windows for these low-end machines more reasonable... With some conditions, I think. (Among other things, everyone's wording of "____ recommends Microsoft Windows for everyday computing" seems rather consistent) It's more or less killed the incentive to make Linux netbooks, as the majority of users (whether or not you or I would feel the same) would rather have Windows on the machine.

Personally, I have Debian on my 901 and it's bliss. Not so much as a Windows logo on the keyboard, and the software works the way I expect.

Re:QT Looks Like Shit

[CarpetShark]

It does have a certain shitness to the look, for some reason, at least in KDE. I noticed a while back that a bug was fixed in KDE 4 that rendered stuff with too many borders -- so when a widget was inside another widget, or adjoining another widget, they would both render a border. Kind of hoped that would solve the vague cluttered/weird/awkward feel, but it's hard to tell, since KDE 4 went with the horrible Oxygen theme which could make any widget library look like crap. I suspect Qt itself can still look very nice though. I don't mind the look of Google Earth, for instance, and QtDesigner is quite nice in places at least, though simplistic, even WITH it's horrible KDE4-like colors etc.

That said, Qt is way more than than a widget look/theme. It's a very nice OO library for cross-platform GUI (and non-GUI) applications, with modern threading and event-driven programming support, etc. It's one of the few libraries that make me even consider using C++ these days, as opposed to nicer, more rapid languages like python++. I also think that, if GNOME had used a library of similar quality** and similar OO features, then the GNOME desktop, and Free Software in general, would probably be a lot more advanced at this stage.

++ Yes, I know PyQt is available
** Yes, I know that GNOME was a reponse to Qt's early licenses, and that Harmony didn't pan out

Re:Die to unify

[mzs]

GTK+ is not horrible. The reasons people most often cite for it being horrible are in two categories:

The code is so convoluted.
That is because it is C and not C++ so it cannot take advantage of features of the language. There are times C (say you want to use it in a C program and do not want to do a bunch of glue code with C linkage) is nice and also it depends on less with a smaller overhead.

It does not do all the fancy stuff like SQL that Qt does:
Check again, things have changed, people have written code to do more now that may not be a part of GTK+ itself though but freely available. Also again Qt is a huge thing that then defines how the rest of your program has to be written to interface with it (containers, pointers, signals, and slots for example). Also it is resource intensive because it does so much.

Re:Die to unify

[CarpetShark]

Agreed. GNOME is great and all, but I feel it could have gone (and could go) a lot further with a better underlying (and fully OO from the start) library. All the stats I've seen suggest that Qt is much faster than GTK+ (and Cairo) too. The only thing is... I'd hate to lose the GNOME look/feel (especially not in favor of the god-awful KDE4 look and feel), and more importantly, I'd hate to lose Pango. Pango is probably the best thing that ever happened in GNOME.

Re:QT Looks Like Shit

[salimma]

Qt 4.5 has an excellent GTK style that makes Qt and KDE applications look just like GTK/GNOME applications, down to button ordering.

Also, Qt Creator, their new C++ IDE, is a good illustration of what a Qt application can look like. Delicious.

Doesn't work

[CarpetShark]

we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals.

This doesn't work. They tried it with Vista.

Re:QT Looks Like Shit

[CarpetShark]

I didn't know the GNOME-compatible look/feel had improved much with Qt4.5, thanks.

On QtCreator... yeah, that's what I meant when I said QtDesigner. Just tried it last night, and it was quite... interesting. I really can't say nice, because it showed more potential than actual beauty, but it did make me stop and think a little :)

Re:Die to unify

[salimma]

Ideally, GTK+ will be rewritten in Vala. That way, we get C compatibility together with being able to write code in a modern, high-level, C#-like language (with type inference, memory management and anonymous functions, to name a few features).

Re:pointer

[zander]

the shared_ptr equivalent in Qt is QSharedPointer (surprise!) not QPointer which is something quite different. I do suggest not using shared_ptr as the Qt version has better cross-platform support and is easier to use and like most Qt things has better readability.

Re:Should be a followup, actually

[zander]

by using native GTK theming that Qt supplies :) http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-part-of-qt/

Re:Should be a followup, actually

[Anonymous Coward]

The only thing holding me back from totally adopting Qt was the outrageous licensing cost, not anything lacking in the toolkit itself. With it having gone to LGPL now, that is no longer an issue.

Same here. Only problem is that one of the major libraries "QtUiTools" is still only available as a static library which means if you use it then your app becomes GPL infected. It's hard not to use it if you use anything that creates GUI resources (eg. Qt Creator).

I would have preferred cheaper licensing rather than going LGPL. Something reasonable like the other major developer toolkits. $300 or so for all platforms. Their current pricing is just obnoxious. Especially for freelance developers like myself, paying nearly $3700 plus, what, $2000 or so per year for a single developer on a single platform is absolutely absurd. At that price I could buy a developer subscription with multiple licenses to practically every single product Microsoft and Apple make combined (including operating systems, databases, developer tools, the whole works). Who do they think they are? I mean shit, they're just providing a GUI API and some cross-platform helper API's.

Re:Die to unify

[MemoryDragon]

Actually Qt was relicensed into GPL because of KDE, not because of Gnome. KDE used Qt and came under heavy fire due to using Qt, TrollTech relicensed then Qt due to this criticis, and later on hired some of the KDE developers!

The relicensing to LGPL now happened after the Nokia buyout, and was also preplanned because Trolltech always said, if it was bought or went bankrupt it would relicense it into LGPL!

not a troll

[CarpetShark]

What reactionaries are modding this "troll"? It's a perfectly valid comment, for anyone who has actually sat down and compared the libraries. Also, it's a perfectly reasonable issue to consider, now that both desktops' core libraries share common licenses and have essentially become interchangeable. Yes, that interchange would involve hard work, which may lead reactionaries to reject it, but what progress doesn't involve hard work? It would at least be nice to see a study of some GNOME app re-implemented in Qt, and what the pros/cons are. I know for a fact that at least a few apps have have been ported from GNOME to Qt (Qt3, though, I think), and probably some have been ported the other way too. Even just those historical cases with Qt3, the case study would be interesting.

Re:not a troll

[vurian]

Rosegarden is quite a famous example, especially since one of the rosegarden authors used to be a gtkmm maintainer. His articles on the subject can still be found and are still well worth reading.

Re:not a troll

[Draek]

People who have actually sat down and compared both libraries, and went with GTK.

Seriously, comments along the lines of that AC get posted in *every* single story concerning GNOME, GTK, KDE or QT, and while that may have been a reasonable question when QT changed its license to GPL, and later to LGPL anyone who actually believes GNOME would change toolkits merely because QT opened up their repositories is a bloody moron. Therefore, the only reason such a comment could get posted is if it was a poor troll, trying to incite the GTK fans to a flamefest and deserves to be modded as such.

Re:not a troll

[egr]

You mean this one one?

Re:not a troll

[a09bdb811a]

People who have actually sat down and compared both libraries, and went with GTK.

I'd love to hear the reasons.

You'd be nuts to use GTK for any new project. I fear it'll be propped up for quite a while to come, though, mainly by Redhat.

Re:not a troll

[Draek]

Better support for languages which are not C++. Much, much, *much* better. Last time I tried it, PyQT felt like a whitespace-aware version of C++ rather than the Python I know and love, and is there even a QT#?

And frankly, I believe you'd be nuts to use C++ for any new project and that makes QT kinda sorta useless ;) you may disagree with me, hell you probably do and like that poor SOB of a language, but those are my reasons and are as valid as anyone's.

Re:Should be a followup, actually

[Dan Ost]

How did you get used to the tiny keyboard?

Re:Die to unify

[jabjoe]

Exactly!

Free software's diversity is it's strength. Each part can be replaced with a competing component. It's all glued together with open standards. This makes things more modular and enforces the Unix philosophy "Write programs that do one thing and do it well." It's an ecosystem, competition fueling evolution. Forking into more competing versions when people disagree.

Some crazy people even replace the Linux kernel with a BSD/Solaris even Hurd!

Anyone one thinks there should only be one Linux distro doesn't get it at all.

Re:Die to unify

[Brandybuck]

Interested rewrite of history. But it's not true. GNOME didn't drive Trolltech to open source Qt, KDE did. GNOME wasn't (and still is not) using Qt, so why should have Trolltech cared about their whines? It was KDE developers advocating for real open source that did it.

Re:Should be a followup, actually

[Tetsujin]

How did you get used to the tiny keyboard?

The size of the keyboard is fine for me (I have long, spindly fingers) - the only problem I have currently is some minor issues with keystroke reliability - occasionally keystrokes don't register and occasionally I get some kind of multiple input from switch bounce or something...

Still, got no regrets about buying this particular netbook.

Re:QT Looks Like Shit

[poetmatt]

I swear, I've never heard of kubuntu before.

Re:Die to unify

[Hurricane78]

resulting in unification of open-source GUI

Yeah, right. Take away choice! We hate choice! Right? ^^

Only when the last fork is unified, will you notice, that the main trunk it crap. ^^
(True for states, companies, rule sets, etc. too)

LGPL for windows too?

[poached]

Last I checked QT 4.5 Visual Studio compiler still required a license and lots of money. Only the MinGW + QT was free. I guess it's ok if you use sharedevelop and tell it to use the MinGW compiler toolchain, but for someone wanting the VS integration it is not too good. Has this changed?

Re:LGPL for windows too?

[ultrabot]

Last I checked QT 4.5 Visual Studio compiler still required a license and lots of money. Only the MinGW + QT was free. I guess it's ok if you use sharedevelop and tell it to use the MinGW compiler toolchain, but for someone wanting the VS integration it is not too good. Has this changed?

http://www.qtsoftware.com/downloads/visual-studio-add-in

Re:LGPL for windows too?

[ardor]

There are unofficial qmakespecs for visual studio. The missing official VS support has got something to do with licensing incompatibilities between LGPL/GPL IIRC (but I'm unsure).

Re:LGPL for windows too?

[poached]

that's the add-in. I didn't know that existed before. Anyway, the commercial version says it has full visual studio integration. What does that mean? What is the difference. If there is no difference then why would anyone pay the a commercial license?

Re:LGPL for windows too?

[ultrabot]

that's the add-in. I didn't know that existed before. Anyway, the commercial version says it has full visual studio integration. What does that mean? What is the difference. If there is no difference then why would anyone pay the a commercial license?

I don't know what's the status with visual studio toolchain proper at the moment (I don't do windows development); but I think the important thing is the VS compiler + debugger support in qt creator. Full Visual Studio integration (VS IDE) was important before qt creator, since all we had on windows side was the buggy eclipse plugin.

Just try Qt Creator.

Re:LGPL for windows too?

[poached]

I guess I'll have to try it to see what you mean. I would prefer to use full VS integration so I can use the debugger and compiler that I am familiar with, along with all the add-ins that I have. I would not want to switch to another tool and lose all of the add-ins. I guess I'll have to play around with the add-in vs using qt creator tonight.

Re:LGPL for windows too?

[vurian]

You can compile the free version of Qt with Visual Studio (express or standard) without any problems. I do it regularly. You might be thinking of the IDE integration, which is a problem, but one for which Microsoft, not Nokia, is responsible.

Re:LGPL for windows too?

[poached]

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.

Re:Should be a followup, actually

[DuckDodgers]

The problem with fat client software is not that it's equal or inferior to a well-built website. It's definitely superior.

The problem is deployment and support. As much as Javascript is a pain, non-standard HTML support in IE is a pain, and a million other headaches come with a website, in many ways it's far less headache than supporting a .msi/tar.gz/.deb/.rpm installer and getting tech support calls that have nothing to do with your application.

There's certainly a wide range of applications that will always remain fat client only. But the terminal-server model makes a lot of sense from the support perspective for many applications.

Re:Die to unify

[Hurricane78]

"is"! I meant "is".
Damn! Ruined my *one* chance to be quoted. Ever. ;)

Re:Should be a followup, actually

[Cyberax]

Remember Palm.

Re:Die to unify

[w000t]

I'd say correcting GGP. Qt didn't go LGPL because of GTK, Trolltech was doing fine with their dual license model. It was Nokia who decided to make Qt LGPL as, being a much larger company, they are not dependant on that (relatively) low income and thought this would boost adoption of Qt (which they seem to be pushing hard now).

Re:QT Looks Like Shit

[FictionPimp]

Kubuntu is not a decent version of KDE. Or KDE really sucks.

If they put half the time into kubuntu that they put into ubuntu it could become a great operating system.

Re:Should be a followup, actually

[NoStarchPlox]

No it was just a poorly worded version of saying that Qt uses the native graphics API to render it's widgets so it matches the look-and-feel of the platform.

Re:Should be a followup, actually

[NoStarchPlox]

See this post.

Re:Die to unify

[speedtux]

That horrible GNOME/GTK of yours drove Trolltech into relicensing Qt to GPL

No, what drove Trolltech into relicensing Qt under the GPL was that KDE had built on Qt assuming that it was open source and then discovered that the Qt license was incompatible with KDE. If Trolltech hadn't relicensed Qt, KDE would have been dead, and that would have been very, very bad for Qt.

Both projects thrive from eachother and the constant "battles" drive devs to find out new creative ways

Qt and KDE were a major incentive for Gnome to get its act together. I think Qt/KDE are now collapsing under their own weight and under the enormous numbers of features being added to them. The fact that they are C++ based is also a significant issue.

I think the Linux desktop race is effectively over. And I also don't see Qt having a lot of impact on mobile devices anymore either.

Re:Should be a followup, actually

[vrai]

The problem with fat client software is not that it's equal or inferior to a well-built website. It's definitely superior.
...
There's certainly a wide range of applications that will always remain fat client only

Websites cannot be definitely superior and unusable in certain situations. As it is they are not definitely superior as anything that can be done on a website can be done using a local client. However not everything that a local client can do is possible on a website (unless you start using embedded applications and turning the web page in to a local client within a web browser frame).

I also take issue with the implication that all local clients are fat clients. It's perfectly possible to have a system with a thin, locally hosted GUI and a much larger server backend. You can even use HTTP to communicate between the two. The use of a local GUI in such situations gives you (the software designer/programmer) much more control over the user experience. Your well-crafted UI isn't going to fall apart because a user has decided to use Chrome or the latest version of Safari has introduced a rendering bug.

To repeat my original post: web interfaces have their place but they are not a replacement for properly implemented local GUIs. For something that is relatively simple and for which the zero installation benefit of the web outweighs the downsides, an HTML/Flash/Javascript interface is the way to go. That not withstanding, the functionality available to the local GUI designer is a superset of that available to the web designer. The local GUI isn't limited to HTTP as a transport mechanism. The local GUI isn't subject to vagaries of browser "standards" compliance and to crash briefly back on topic; there is no web UI toolkit that approaches Qt for ease of use, cleanness of interface or cross platform functionality.

Re:Qt GTK

[speedtux]

It's not going to happen. Qt makes sense if you develop in C++. Gnome is going to move gradually to Python and C# development; C++ is just not on its roadmap.

Mercurial hosting?

[speedtux]

Is there any kind of Mercurial hosting for open source projects you can recommend?

Re:Mercurial hosting?

[ultrabot]

Is there any kind of Mercurial hosting for open source projects you can recommend?

http://bitbucket.org/

And soon, google code

Re:I'm at a loss for words.

[GreatBunzinni]

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.

Re:pointer

[mzs]

To be fair QSharedPointer showed-up in 4.5, hence the reason I had never heard of it until now. OPointer was forced upon me due to everything being a QObject, but then there was the other non-Qt half of the code that used boost, it was not pretty.

Re:Should be a followup, actually

[Man On Pink Corner]

Same here. Only problem is that one of the major libraries "QtUiTools" is still only available as a static library which means if you use it then your app becomes GPL infected. It's hard not to use it if you use anything that creates GUI resources (eg. Qt Creator).

Is QtUiTools part of the Qt source distribution? If so, can you recompile it as a .DLL and get around the GPL encumbrance?

Re:Die to unify

[steelfood]

Probably because QT was Trolltech's bread and butter, and thus wanted commercial apps to pay for a license, while QT is just a means to an end for Nokia, its end being to increase its smartphone market share and to dominate the portable device space.

Re:Should be a followup, actually

[pherthyl]

None of those run on as many platforms as Qt does. And all of them look out of place on all the platforms they run on (except for SWT, which looks ok on Windows and Gnome, but runs badly on Linux).

Re:Should be a followup, actually

[pherthyl]

I've never used QtUiTools and I use Designer all the time.
I don't see any reason to create the UI at runtime. I just do the single inheritance model and everything gets converted to C++ at compile time.

Re:QT Looks Like Shit

[Anonymous Coward]

Sory we can't make every one happy, we worked very hard in Oxygen to make it pretty and usable, many people find it so, and it was the qt software that made it possible.
The fact that you find it ugly, it is compensated by the fact that many, many, others dont.
Its not a finished joob I think it will never be but we do our best, and I think its a fantastic start.
Yours Nuno Pinheiro Oxygen coordinator

Re:Die to unify

[ultrabot]

Ideally, GTK+ will be rewritten in Vala. That way, we get C compatibility together with being able to write code in a modern, high-level, C#-like language (with type inference, memory management and anonymous functions, to name a few features).

Yeah, then we'd have a desktop based entirely on language/precompiler that exists solely for the developers of that desktop.

Why not start shipping Gnome as a Smalltalk system image while we are at it?

Re:Qt GTK

[Toonol]

Gnome is going to move gradually to Python and C# development

Seriously? C# in mono and all that?

Sometimes the decisions development teams make absolutely mystify me.

Re:Should be a followup, actually

[TummyX]

Actually you're misinformed. QT uses the native API (uxtheme.dll on windows etc) to do drawing of widgets so that they are drawn like native apps. That is pretty much the same thing Swing does but QT is much faster! There's no way QT could move to native widgets for real without break backwards compatibility (the features related to drawing would have to change quite dramatically for example).

Use Spy++ on a QT app like Skype if you don't believe me.

Re:Should be a followup, actually

[mattack2]

Instead we can have a global installation of five (for example) really big computers and we can access them using dumb internet terminals.

So Thomas J. Watson was (apocryphally) right?

Re:Die to unify

[ultrabot]

GTK+ is not horrible. The reasons people most often cite for it being horrible are in two categories:

The code is so convoluted.
That is because it is C and not C++ so it cannot take advantage of features of the language. There are times C (say you want to use it in a C program and do not want to do a bunch of glue code with C linkage) is nice and also it depends on less with a smaller overhead.

Is there a research somewhere that measures overhead / binary size / performance of Gtk+ and Qt programs against each other? I have anecdotal evidence that at least when you are comparing KDE and Gnome programs, the Gnome programs are always the slower ones. Take kate, gedit and 20 meg file, for example.

Gtk+ does OO explicitly with GObject. It sucks to develop for, but I'd wager to guess that it's slower than well-compiled C++ as well (because of frequent type checking).

C is still a good language for, say, making fast modules for scripting languages (integrating C to them is always easier because it has no name mangling), but writing desktop applications is not really where it should be used in the future.

Microsoft probably had a few good laughs looking at the open source community doing their little things with their ancient tools, but that time is over now.

Re:Die to unify

[silent_artichoke]

Ruined my *one* chance to be quoted. Ever. ;)

Happy?

Re:Should be a followup, actually

[synthespian]

Saying something is dying is usually misinformed or more likely spreading FUD to hasten the decline.

I agree, and support

1) Cobol job openings still exist
2) VAX support is still available
3) Mainframes are still around ...
n) Lisp ain't dead
n+1) Smalltalk ain't dead
n+2) BSD ain't dead
n+3) Assembly experts still exist
n+4) Eiffel is still used
n+5) Ada is still deployed in industries
n+6) Forth is still deployed in electronics
n+7) Somebody buys support for Rebol, believe it or not ...
What FUDders may consider a dying market might well be called "a niche market" (or "opportunity") for others, providing them with a comfortable life. And I only mentioned "big markets". There's stuff out there we haven't even heard of, and someone is developing for it and making money.

Re:Die to unify

[Thalaric]

No, what drove Trolltech into relicensing Qt under the GPL was that KDE had built on Qt assuming that it was open source and then discovered that the Qt license was incompatible with KDE. If Trolltech hadn't relicensed Qt, KDE would have been dead, and that would have been very, very bad for Qt.

This is such historical revisionism. QT had repeatedly rejected KDE's request to change their license. Gnome was started because of this fact. It wasn't until gnome matured and GTK threatened to make QT irrelevant that they finally capitulated.

Qt and KDE were a major incentive for Gnome to get its act together.

True, but it was the other way around first.

Re:Die to unify

[Thalaric]

Interesting ignorance of history...

Qt had repeatedly refused to change it's license before gnome was started. Qt found itself benefiting from a major open source movement, which would not have continued while an open alternative was available and maturing.

Qt: a dream platform!

[Kensai7]

What can I say... Qt is becoming a dream platform thanks to Nokia's insight!

- a powerful language/library (C++)
- real cross-platform
- support for embedded and mobile applications (a great alternative for the difficult Symbian C++ language)
- open source and nice licence (LGPL)
- exemplar own IDE but also Eclipse/VS integration
- additional languages supported

What else could one ask?!

Re:Qt: a dream platform!

[EvilIdler]

The only thing I could ask would be for the libraries to be smaller. The way you build a program for a platform where Qt isn't guaranteed to be installed inflates the distribution by a lot. On Mac, you use macdeployqt to include frameworks with the app, and they take at least 40MB extra. Compared to wxWidget's modest requirements, that's enormous.

Re:Qt: a dream platform!

[Kensai7]

Indeed, that could be fixed with a nice switch system. Nevertheless, wxWidget has modest requirements because it's "modest" overall... ;-)

Re:Qt GTK

[Draek]

Why? it's a wonderful platform, and an excellent language. Yes, it has some potential problems with patents, but so does half of Linux' multimedia apps and nobody cares much.

If your country has backwards patent laws it's your problem after all, not ours.

Re:Should be a followup, actually

[drinkypoo]

Actually, there's no reason you couldn't deliver a Qt application's interface via the web, and do it efficiently if you had some sort of fairly complex browser plugin, and you could ship data to the client and filter it there or just send them GUI updates as appropriate. You could implement more of the toolkit's complexity on the browser end than just sending a bunch of CSS-styled HTML elements... Of course, this is just reinventing X11 in a lot of ways. Perhaps you would be better off using X+FreeNX+ssh, since it already works.

Re:Should be a followup, actually

[moon3]

If only they can get rid off that nasty MOC compiler and adopt Boost.org signals/slots or figure themselves something better.

Re:Die to unify

[pizzach]

Maybe. I'm sure that Gnome gave those KDE developers some good leverage on Trolltech, though. ...I should go look at a timeline.

Re:Should be a followup, actually

[Jeremi]

You must be a bit behind the times as Qt no longer emulates a native look-and-feel but uses the native widgets of the platform

The above is incorrect. Qt still does all of its own drawing, pixel by pixel. It doesn't use any native widgets (except for things like file dialogs, and even those have non-native counterparts available)

What's new is that in Qt 4.5, Qt doesn't even create a native canvas widget for each Qt widget anymore. As far as the host OS is concerned, every Qt window is just one big flat canvas, with the Qt libraries managing everything that goes on within.

Re:Should be a followup, actually

[HiThere]

What I really don't like is the C++ interface. That doesn't play nicely with most other languages. (C is much better in that regard.)

Perhaps, though, I just haven't looked recently. Does Qt now have a C interface library?

I don't really like C, as it's too pointer happy. But it does have the advantage for an interface language that more languages can easily interface with C than any other particular language. (I count each separate assembler as a separate language.) OTOH, I think that many gtk widgets are horribly ugly. Especially the file directory widget. It's far superior to allow a file name to be typed as a single string than to require each directory in the path to be a separate button. (Granted, I've not used this widget. I don't know how it looks to program for. But speaking as a user, "UGH!".)

Re:Should be a followup, actually

[AnyoneEB]

Thanks. I enabled that. Unfortunately, it is only for Qt4 and the few Qt apps I use are still on Qt3, but that is not really Qt's fault. I can't comment on how well it handles emulating the GTK feel because the only Qt4 app I have appears to be qtconfig and it does not have that wide a variety of widgets.

Re:QT Looks Like Shit

[PiSkyHi]

or depending on the code... Python, you stink!

Re:Die to unify

[franki.macha]

I couldn't agree more, I just wish that

It's all glued together with open standards

applied to package management, I think that would be a huge step towards 'modularity' between distros, and create a healthier Linux ecosystem.

(.deb ftw ;))

Re:QT Looks Like Shit

[ailnlv]

>>> import odour
Traceback (most recent call last):
    File "", line 1, in
ImportError: No module named odour

:(

Re:Should be a followup, actually

[dudpixel]

This entire discussion is about Qt4. Qt3 was under a different license (GPL) and is not in the aforementioned repositories.

Re:Should be a followup, actually

[Fujisawa Sensei]

If you're posting on slashdot, it should be obvious he was talking about the Unix/Risc server market versus Lintel.

In other words, one-buttoners GTFO.

UNIX servers need a mouse, that's X.

Re:Should be a followup, actually

[Kensai7]

You have to understand the "ABC is dying/dead" mentality.

It doesn't matter how much market share you have, only that your market share is decreasing and some smaller technology which they favor has an increasing market share.

It doesn't matter that at the rate of decline it would take 20 or more years for whatever it is to die. Or that the decline may be arrested. Saying something is dying is usually misinformed or more likely spreading FUD to hasten the decline.

Quickly! Say Windows is dying so we may see it before Singularity kicks in!!

Re:Die to unify

[noundi]

I'm talking about GPL, not LGPL. If you had followed the Qt development over the years you would know what I'm talking about. Luckally we have wikipedia.

The first two versions of Qt had only two flavours: Qt/X11 for Unix and Qt/Windows for the Windows platform. The Windows platform was only available under the proprietary license which meant free/open source applications written in Qt for X11 could not be ported to Windows without purchasing the QPL edition. In the end of 2001, Trolltech released Qt 3.0 which added support for the Mac OS X platform. The Mac OS X support was available only in the proprietary license, until June 2003, where Trolltech released Qt 3.2 with Mac OS X support available under the GPL.

In 2002 members of the KDE on Cygwin project began porting the GPL licensed Qt/X11 code base to Windows.[18] This was in response to Trolltech's refusal to license Qt/Windows under the GPL on the grounds that Windows was not a free software/open source platform.[19][20] The project achieved reasonable success although it never reached production quality.

This was resolved when Trolltech released Qt/Windows 4 under the GPL in June 2005. Qt 4 now supports the same set of platforms in the free software/open source editions as in the proprietary edition, so it is now possible to create GPL-licensed free/open source applications using Qt on all supported platforms.

Re:Die to unify

[noundi]

Please read the history. It was made GPL due to the pressure partly caused by the GPL licensed GNOME/GTK. This was long before Nokia was even in the picture. Read this so you know what I'm talking about.

Re:Die to unify

[noundi]

So the fact that more and more devs went to GNOME was a nonissue? Not quite. The pressure from KDE came for a reason, and when GNOME was actually becoming equal to KDE it became clear. GNOME was following a winning strategy, and of course it was the GPL license that was responsible for a lot of the success GNOME had. Don't ignore the importance of competition. If Trolltech didn't feel threatened they would have never changed license.

Re:Die to unify

[noundi]

Exactly, I can't believe that so many people don't know their history! GNOME was created because of the GPL strife between KDE and Qt. Thus it became a catalyst for KDE to talk Trolltech into GPL licensing Qt.

Re:Die to unify

[noundi]

The whole reason Gnome exists is because KDE was attached to a non-free toolkit. Gnome was the heavy fire you speak of. It wasn't until Gnome caught up to KDE that QT finally decided to become GPL (or risk irrelevance as GTK fully matured).

It's strange how people seem to ignore this. Where do they think GNOME came from?

Re:Die to unify

[jabjoe]

No! We want competing package management systems too! They should never be any "one to rule them all".

QtUiTools

[zander]

The QtUiTools is not meant to be linked against, its a library that is shipped with designer (an development-application) so its kind of odd to judge all of Qt on a bundled application. Perhaps you should try to move the classes you require from this library into QtGui. You may want to file a feature request or even do the work yourself (this post is about the repos being open!!). The tools-library you seem to want to use is not for major consumption, doesn't have binary compatibility and all that. So its great that you *can* use it, but maybe you are expecting a bit too much to get it without any investment at all ;)

Try to design in Qt

[zander]

As posted elsewhere in this story the Qt APIs promote a certain design that make your application and your code easier to maintain and read.

So to answer your point 1;

• || parent-child relationships are not enough in many cases where objects are shared across multiple domains.

The parent-child relationship is there for memory management purposes. Which directly links to having an owner of an object. If your object is owned by someone else, that someone is responsible for deleting it. This is free in Qt when you use QObject. If your object is not owned by one thing but shared between many you use a QSharedData based concept which immediately makes you stop using pointers too.

This makes it absolutely clear what is what in common usage of the code and you'll notice that memory leaks or crashes due to dangling pointers become very easy to avoid.

So, you may be right Qt is not as flexible as STL. But I don't mind a bit of structure. Less rope to hang myself.

Another point that probably needs clarification;

• || Introspection has nothing to do with signals and slots

I think it does, you can't have powerful signals/slots without introspection. The huge advantage of using introspection to do connections is that you don't need a pre-compiled interface to code to. Which then avoids a lot of nastyness in C++ with library loading and linking etc.

Which makes it possible to have a GUI designer as powerful as QtDesigner, among others.

Re:Qt Looks Like Shit

[zander]

Its not so much that many must find Oxygen pretty, its much more that people that don't are not whining about it like the original poster did. They just use another style that looks better to them. Frankly; saying that a theming toolkit looks ugly is kind of silly. Especially since there is a native Windows look&feel as well as a native MacOSX l&f which, well, look native.

Re:Qt GTK

[EvilIdler]

Gtk+ is a mess, but it's really an apples and oranges comparison. Gtk+ is purely a GUI library, with Glib below it performing some utility functions, and Gnome above it for more convenience functionality.

Qt is a full application framework, with all levels of networking and graphical sub-libraries/plugins.

If Gnome switched to Qt, development would be set back by years. It's no small task to convert all those programs. Some are C-based (pure Gnome libraries and Gtk+), others C++ (Gnomemm and Gtkmm). Gnomemm and Gtkmm is more pleasant to code with, in my opinion, but they still doesn't abstract many tasks beyond a GUI.

Re:QT Looks Like Shit

[FictionPimp]

I like how this is flamebait, but my comment below saying kubuntu sucks is insightful.

Re:Should be a followup, actually

[HiThere]

Thanks. Still a bad design, but I'm glad to hear there's a way around it. Actually, though, I've been generally avoiding it by avoiding gtk based applications. (A real pain, since that's the library I'd rather use...due to the C linkage.)

Re:Should be a followup, actually

[Hank Scorpio]

For instantiating a UI at runtime, take a look at QFormBuilder. It is in the QtDesigner library, which does compile as a shared library, and therefore is LGPL friendly. I'm not exactly sure why they have both QFormBuilder and QUiLoader, since they both do the same thing but provide differing interfaces.

Re:Qt Looks Like Shit

[CarpetShark]

No, it's only silly to selfish people like you who only care about making themselves happy. Personally, I'm concerned about all unix users (and all computer users in fact), so yes, having a default choice of theme that's not pretty is a problem.

Re:LGPL PyQT ?

[Toy G]

Don't hold your breath. The guy behind PyQt is still a very small independent vendor with a big financial incentive in keeping the license arrangement what it is. Unless Nokia buys him out, I don't expect any license change any time soon.

Re:Die to unify

[Brandybuck]

GNOME was an unfinished project when Qt announced its first license change. It was the KDE developers who lobbied for the license, not GNOME. Commercial companies, such as trolltech, pay a lot more attention to their own customers (KDE developers) than they do to knee-jerk detractors who have no interest in using the code for any reason.

Re:Should be a followup, actually

[DuckDodgers]

It's perfectly possible to have a system with a thin, locally hosted GUI and a much larger server backend.

But your thin, locally hosted GUI must be installed, and therein lies the headache. And that's what I meant by fat client - some portion of the software must be installed outside of a web browser.

Again, I'm not arguing that websites are mostly better than installed local applications. I'm just arguing that there's a broad class of applications where the advantages of websites outweigh the weaknesses.