Re: Questions about Gnome project



Alberto Vecchiato wrote:
> 1) According to the KDE development group, Qt is simply the best tool,
> better than GTK. Is it true or not in you opinion? May you justify your
> answer, if it's not too long?

I've only taken cursory looks at Qt, and to be perfectly frank, it
really *does* look nice. There's a lot there, and it looks pretty easy
to use. I think that on technical grounds alone, it would be a good
toolkit to base a project on.

However, I still prefer GTK for these reasons:
1) Qt can only be used from C++ code. GTK can be used from C++, C,
python, Java, and many other languages.
2) GTK is much more aesthetically pleasing, IMHO.
3) The most important reason, of course: GTK is available under the LGPL
license. This is much more important than it would initially seem. One
aspect of this license is that the development is totally open, which
means that the toolkit is advancing much faster than Qt. So while Qt has
a lot there now, GTK is getting  a lot more every day, and IMO will soon
surpass Qt.

But there aren't *that* many differences. Many of the things which make
Qt great are employed by GTK too (signals and slots, object oriented
design).

> 
> 2) Does GTK support multithreading and themeing?

GTK proper is not thread safe, but there is a thread safe wrapper for
it. Unfortunately I can't find a reference to it on the GTK web site, so
I'm not sure what it's called or where to get it :-(

It does support themeing, though that feature is still in development.
Look at http://www.labs.redhat.com/themes.shtml for info and
screenshots.

> 
> 3) You said that KDE has some (few) basic problems that Gnome will resolve,
> contemporarily adding some new ideas/features. Could you tell us which these
> problems/new features are? (Again, if not too long)

1) The fact that Qt is not free software.
2) KDE requires that you use kwm as your window manager (at least for
full functionality). GNOME will be window manager agnostic, only
specifying *behaviors* that are required for full functionality.
3) KDE requires you to use C++, GNOME is language agnostic.

> 
> 4) Somewhere in your site we found that, according to you, it's better to
> re-write KDE instead of Qt, as both have more or less the same length (about
> 89000 lines for KDE and 91000 for Qt) and KDE has those basic problems
> mentioned above, but in the KDE site is written that KDE is a
> half-a-million-lines project. Why this difference?

The KDE site is more accurate. The page on the GNOME site you saw is out
of date.

So the codebase size argument doesn't really apply, but there are other
arguments. Some of the best were in an editorial on Slashdot which you
could look for. The basic gist of the most convincing argument IMO was
that writing an API-compatible clone of Qt is necessarily more difficult
and less productive than writing a full replacement for the system
because Qt is a moving target -- you have to follow the design changes
being made without the benefit of being a part of them, and clones are
subject to subtle bugs and behavior differences. Look at the problems
Lesstif had when it was younger. And the Lesstif project obviously can't
innovate much since they're just providing compatability for the Motif
API. And if TOG decides to make major changes or additions to Motif,
Lesstif is back playing catchup. The same is true for the Harmony
project (the GPL'ed Qt clone).

Tim



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]