Linked by Thom Holwerda on Wed 14th Jan 2009 09:54 UTC, submitted by Almar
Qt After Nokia purchsed Trolltech last year, doubts arose about how Nokia would handle the dual licensing model of Qt, the advanced cross-platform toolkit which lies at the base of the KDE Free software desktop. As it turns out, these doubts were unfounded, as Nokia today announced it's going to add the LGPL to Qt's licensing model, starting with Qt 4.5.
Thread beginning with comment 343749
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Death Knell of Gtk+
by mallard on Thu 15th Jan 2009 20:40 UTC in reply to "RE[2]: Death Knell of Gtk+"
mallard
Member since:
2006-01-06

As to you other points... Anyone who thinks it's a good thing not to have a complete framework hasn't done real work in the real world.


Except that it becomes a pain if you want to use a _different_ framework. I don't think the GUI library should dictate what Database API you use for instance.

As for bindings, GTK+ has a C API. It is *far* easier to wrap C to other languages than C++ (and when you wrap C++, you usually have to wrap it in C first). This means less developer time/effort is spent on the "plumbing" of bindings with GTK+, leaving more time for the useful stuff.

Edited 2009-01-15 20:46 UTC

Reply Parent Score: 1

RE[4]: Death Knell of Gtk+
by boudewijn on Thu 15th Jan 2009 20:44 in reply to "RE[3]: Death Knell of Gtk+"
boudewijn Member since:
2006-03-05

Like which? Borland VCL? That's incompatible with Qt for sure... But I've used OSX frameworks, Windows stuff, boost, stl, tbb, that weird thing adobe makes available I've forgotten the name of, other linux libraries with Qt without any problems. And what's the advantage of not having a good, extensive, well-documented, consistent framework but patching your own together from a myriad inconsistent libraries?

Reply Parent Score: 3

RE[4]: Death Knell of Gtk+
by Bille on Fri 16th Jan 2009 07:08 in reply to "RE[3]: Death Knell of Gtk+"
Bille Member since:
2007-05-31

Except that it becomes a pain if you want to use a _different_ framework. I don't think the GUI library should dictate what Database API you use for instance.


Why is it a pain to do -lmysqlclient instead of -lQtSql if that's what you want to use?

Qt provides a database API as a separate module, it doesn't dictate anything.

For example, using qmake, the only Qt modules used by default are QtCore (same level as glib) and QtGui (as gtk). The other modules have to be explicitly added to your configuration with eg "QT += sql"..

Reply Parent Score: 3

RE[4]: Death Knell of Gtk+
by Richard Dale on Fri 16th Jan 2009 11:48 in reply to "RE[3]: Death Knell of Gtk+"
Richard Dale Member since:
2005-07-22

As for bindings, GTK+ has a C API. It is *far* easier to wrap C to other languages than C++ (and when you wrap C++, you usually have to wrap it in C first). This means less developer time/effort is spent on the "plumbing" of bindings with GTK+, leaving more time for the useful stuff.


Producing language bindings isn't 'easy' for either the Gnome or Qt/KDE apis. They are both very large and complex, and only someone who has never actually produced a decent quality language bindings for those apis would use the term 'far easier'.

If you look at how much actual man effort goes into producing Gnome or KDE language bindings, it appears to me to be about the same. I not talking about simple prototypes which may well be easier to produce by hand for an underlying C api. I am talking about doing the complete thing, which ends up being a different level of hardness.

None of the current Qt/KDE bindings projects wrap the api in C first, and so your point about that is demonstrably wrong.

Reply Parent Score: 5