I have had great fun programming with Kde and Qt. This page is meant
as an invitation to join the developers, providing some good and objective
reasons to do it (and a few more controversial reasons). If you are thinking
about writing a Gui application or already started to do so, it is perhaps
worth reading.
In january 1999, I asked RMS at the French Linux Expo if he thought Kde,
with the new QPL, could be considered as free. His answer was Yes,
it is free !. Although I don't see why you need Kde, you have Gnome.
:-)
So this controversy should be closed.
The problem is that according to Debian, there is a copyright violation of the GPL when distributing binaries of Kde, because the license of Kde doesn't expicitely states it allows linking with Qt. The thing is that Kde is GPL but Qt is not. The GPL states that the whole executable must be GPL. If this is not the case, the author should give permission to link with non-GPL code. This freshmeat editorial discusses a few points where GPL and QPL (the Qt license) might not fit.
In this case, it is obvious that Kde people did agree to link their program with Qt, because their program won't run without Qt. RMS has agreed that in such a case (a program purposely developed to link with a given library, no replacement being available), this permission is implicitely granted. He also thinks that it is unwise to rely on implicit permission and that one should better make this explicit.
The debian folks don't want to distribute something with tiny license problem. They have in the past rejected applications for such reasons, even if it is obvious that the author intend to make its software free. Their point on the Kde matter is that if the permission is already granted, it is not really a copyright change to make it explicit (write it down).
The problem also arise stronger with application whose code is used in Kde but whose author never implicitely gave a permission to link with Qt. A typical example is kghostview which uses ghostview's code.
The Kde's point of view on this matter is that there is no need to give an explicit or implicit permission. They have asked their lawyers and they don't see any copyright violation with this. The GPL is not crystal clear on this matter and different lawyers have different point. So it could only be resolved in court.
About the fact that Kde should change its license and give explicit permission to link with Qt, the problem is different. There are thousand of people who have coded for kde. They gave their code to the project, agreeing on the license being used at this time. You can not change the license of Kde without asking all of them, because it is their code. Even if you know that they would agree to such a change, that they think linking with Qt was already permitted, changing a copyright is not allowed without the author's permission . It would be a very hard job to find all these people. Some of them are unknown (all code is not marked), some of them have disappeared from the net, uso. Kde is not willing to make such an effort, for an issue on which they don't agree.
This problem has generated a _lot_ of discussion. Kde claimed Debian and RMS were unfairly bashing Kde because they prefer Gnome. Debian claimed that Kde was in GPL violation. Kde got very bad publicity and a _lot_ of people half-knowledged about the problem have written stupidties about this.
Hopefully, there is an happy end. Qt was sick of being bashed over and over for the same problem. Because they think they can now control a free version of Qt, they have released Qt 2.2 under both GPL and QPL. This controversy is also closed, thanks again to TrollTech. Kde is now distributed by debian!
As a note, RMS has had a strange reaction to Qt being GPL. We won't know if there was really a GPL violation and it doesn't matter anymore. But, in any case, he has called to forgive kde for their actions. It sounds more like a religious call than anything. Why sould kde be forgiven ? For using code despite an unresolved issue ? For having violated the GPL ? In either case, noone have ever asked for foregiveness. Kde core developers have reacted strongly to this call.
If you want a more complete and detailed hisotry and analysis of the Kde
Licensing problems, check the
Chapter 19 of the Kde 2.0 Development Book, published under the
Open Content License.
You can achieve C++ in C with pointers and a clean API
I agree. You you can indeed replace a C++ program by a program cleanly written in C. But let's see why one wouldn't want to do that, at least for a Graphical application.
[ understand : everything should be written in good old plain C ]
First, you have to agree that a Graphical application is in essence Object Orientied. You have bunches of widgets that you manipulate, aggregate, make interact with each other : you connect a button to a dialog, to actions. The GUI itself reacts to events that have to be propagated from one widget to another. Gtk, just like Qt, achieve this with an Object Oriented API and a signal/slot mechanism.
Then, why prefer C++ over C ? Well, C++ has been designed to support Objects, it is simply more suited to the task of writing an Object Oriented application. Consider a these points :So you can still do everything in C. But it will be a lot more complicated to design and to debug. This is an hazardous choice.
- C++ provides modularity very naturally with classes. This is less natural in C.
- C++ provides a lot of very handy containers. To achieve the same effect in C, you need to use a lot of macros and void * pointers. Macros and generic pointers are not typesafe, they are always a bit hazardous.
- Namespace pollution : because you don't have complete independant modules (classes), you have to use heavy names (like gtk_menu_ensure_uline_accel_group ) and prefix all your functions and global variables to make them unique. This makes you code harder to read.
- A Gtk programmer once mentionned this problem : within all the structs used for Gtk, it is not always obvious what should be used by the programmer and what is used internally by Gtk. So you might call a function you shouldn't have access to. C++ has public, protected and private interface to solve this problem.
- The header files in C++ make it easy to understand the goal of a class in one glance. In C, people are not used to declare all their function in a separate file. So you often end looking directly at the code.
- The glib is providing in C things that you have builtins in C++: constructor and destructor, objects, inherintance, typecasting, etc. If you are using all this, why not use directly a language that supports this from the start. It will make your life easier.
- C++ has nice features : default arguments, function overloading, operator overloading, inheritance, constructor and destructors. All this make it a lot easier to read and use (and even to write). In comparison, C needs one function name for every different possible construction of a function and can't overload operators.
Example 1 :
So if you need to create a pixmap, you need to remember (or check in the doc) the exact name of the function and all his arguments. In C++, you have default arguments and the same name can be used for different constructors. This kind of thing makes programming lighter and code easier to read.static void pixmap_create_blank(GdkPixmap **pixmap, GdkBitmap **mask);
static void pixmap_create_by_name(char *name, GdkPixmap **, GdkBitmap **mask);
static void pixmap_create_by_num(int pixmap_num, GdkPixmap **, GdkBitmap **);
static void pixmap_create_by_dir(char *name, GdkPixmap **, GdkBitmap **mask);
- Perl is being rewritten in C++. You might be interested in knowing why Chip Salzenberg choosed this language
C++ is not a good language
This has been argued a thousand of times and there are some good points. Other languages such as Ada, Objective C, Eiffel, SmallTalk, Python, etc probably have better Object Oriented design, or better syntax, or better type checking, or better memory managment, less bloated feature, ... However, C++ has also some good points.
[ understand: we should really get rid of C and C++ ]
Anyway, the idea here is that C is still the standard, the default language, used in strong majority in the free software community . A lot of people know C. By writing your application in C, you are sure that 99% of the developers can understand your code and participate to your project.
Then, when you know C and want to learn about this Object Oriented stuff you have heard about, C++ comes as a reasonable choice. You already know the syntax, so you just have to figure out the Object part. Of course this is not as easy as it sounds, because if C++ has a C-like syntax, the object concept brings something completely new. But it doesn't matter. Because of this C/C++ compatibility, C++ is a widely known and learned language.
Now, if you want to take advantage of a more powerful but less mainstream language like Ada, SmallTalk or Objective C, you put at risks the greatest strength of free software : Peer review. Only the few people that can understand your programming language will be able to help you.
Choosing another language that the toolkit native one has also some serious drawbacks, as states Guillaume Laurent (maintainer of a C++ binding for Gtk) :
- You often feel the wrapper isn't complete enough and you would like to do something the original lib allows but the wrapper don't.
- It is a hard job to maintain a binding. The Free Software World does release often, so the binding has to follow all the work being done on the main toolkit and be updated at every new release. This is a heavy job, and most of the time, the binding will have a long delay before providing access to the latest feature.
- Gnome and Kde API are built upon toolkits, respectively Gtk and Qt. While there are bindings for the toolkits, there are very few bindings for the Desktop API itself (ie, gnome or kde). The problem is that these desktop are always in development, so it is a lot harder to maintain a binding. So if your application wants to take advantage of some desktop features (and it should, that's why we are building desktop and not just applications), then this is a problem.
Note that Kde has stabilized its API KDE 2.0 and ensure (just like Qt) Binary Compatibility for every Kde 2 release. This means that an application written for Kde 2.0 will run with every version of Kde 2, without the need to recompile. Can Gnome promise something like that ?
Well, I explain my point and the point of many kde developers here.
You might be surprised, but not everyone likes this guy. And this includes people using Gnome. He speaks a lot, and probably too much: Unix sucks ? ? Then why write a desktop for Unix then ? Gnome Staroffice Bonobo components ? Everyone speaks about them, but you will have to wait for a long time. Kde doen't have a clown like Miguel and KDE is not a circus. The project cleanly organised and lead by a _team_ of core-developers (not by a board of fundation members). I however admit Miguel helps a lot from a marketing point of view, while Kde lacks this kind of entertainement, that the press loves.
So you better leave Gtk, because GTK is LGPL. Despite what the FSF advises, the FSF and RMS are supporting Gtk/Gnome, which allow non-free software to be written with it. Qt is GPL, Kde is mostly LGPL, but they are ignored or unfairly bashed by RMS and the FSF. Ever wonder why Kde doesn't like RMS ?
Well, I explain also my point and the point of many kde developers here. You can also sum it up to this: Kde 2 has had two major stable releases. Qt 2 has had three major releases (all binary compatible of course). Gnome and Gtk still havn't had their 2.0 release.
I have done a little analysis on this. The conclusion is that your program will be bigger and probably harder to read, not to say (but this is personal) harder to write. I hope to extend this analysis with other material (stay tuned).
This is a very good reason :-). Note that in this case, this also a good reason no to program for Gnome :-). But, don't you want to have a try ? Programming is very fun and not that hard, especially if you try a nice language. I highly recommend Python and of course PyQt. You can achieve quickly and efficiently very good programs with it, like Klotski.
I used to say here that there are only one binding for KDE and Qt, the python binding. But this is not true anymore. Qt has bindings for Python, Ruby, Perl, Java, C, Objective C ( see developer.kde.org). The C bindings are generated from the C++ headers, so they are quite easy to maintain. And the C binding is used by the Objective C binding and by the Java binding. This binding allow almost any language to bind Qt.
On the KDE front, PyKde for KDE 2 is coming. The C, Java and Objective C binding are also available for KDE. So things are going quite well.
QtDesigner, the UI builder of Qt/KDE can generate code for C++ and for Python. It should not be hard to make it generate code for other bindings.Note that even if you choose to program in one of these language, you can still interact and integrate within the Kde desktop. As a matter of fact, DCOP, the Kde Desktop COmmunication Protocol has bindings in C, Java, Perl and Python. And it is easy to add one more if you need it, or to use XML-RPC . With XPart, the DCOP based component Kde technology, you can even embed Kde components or have your application embedded as a component into a Kde application (they have embedded Mozilla with this).
I have heard this once. I find this really stupid and I really hope this is an exception and very few people don't like TrollTech for this. TrollTech is providing the best Graphical Toolkit that has ever been available to the Free Software, under the GPL, and they shouldn't make money with it ? This would be non-sense. TrollTech uses the business model "free for free software, pay for non-free software" which I find very good.
Kde core-developers have reacted strongly during the Kde licensing issue. But, hey, consider this:So, please understand that the Kde folks have had a lot of reasons to be angry. Most of these issues have been resolved though. Anyway, if you follow the project from a developer and technical point of view, people are very friendly, just like in most of every free software project. We are not here to have flamewar, we are here to code and have fun.
- One core-developer doesn't necessary reflect the attitude of the whole project.
- Qt has been bashed over and over, not because it wasn't free software (RMS agreed it was), but only because it wasn't GPL.
- Kde has been bashed over and over, not because it wasn't free software (RMS agreed it was), but only because they were using Qt.
- A _lot_ of people have said a _lot_ of stupidities about Kde without knowing half the issues of project, nor having tried to learn anything about it.
- Gnome has used FUD against Kde. And they are still using it. Yes, we still see results today, when people understand that Kde has no components because it doesn't use Corba, or when people explain me that Kde doesn't have a beautiful architecture like Gnome (ever checked Kde architecture ?)
- Gnome has unfair support from the FSF ! The goal of the FSF is to provide a Free operating system with Free applications. Linux and Hurd are good for this purpose, just like Gnome and Kde. The FSF should give equal and fair support to every project that helps to achieve its goal. It should not bash one and encourage the other, especially when this last one is lead by a board of company members and using a LGPL toolkit against the FSF recommendation.
C++ is the language of choice of Qt and Kde. On the Gtk side, you find more than 5 toolkits, none of them being correct. And particulary, Guillaume Laurent who wanted to program in C++ absolutely has been developing Gtk-- (a C++ binding as you guessed from the name :-) ) for 3 years, then switched to Qt/Kde. Now he is a regular Qt advocate and is the first to recognise that you are more efficient with Qt than with Gtk.Why prefer C++ to C ? For a complex asynchronous program, like a Gui application, I find that C++, combined with Qt, provides cleaner code. Your code is easier to read because you know where it begins (constructor), where it ends (destructor), what is the available API (public members) and what are implementation details (private and protected members). So, by just having a look at the specification of a class, you know what its purpose is. Then the C++ provides nice features, like inheritance, operator overloading, function overloading, polymorphism, namespaces that make you coding life a lot easier than in C where you only have functions, struct and macros. My toolkit comparison highlights this.
Python has excellent bindings for Qt and Kde 1 (not for Kde 2 yet, unfortunately). Python integrates with Qt as if it was its native language and you can use all the excellent and copious documentation of Qt. The support of PyGtk and PyGnome is not that bad, but still inferior to PyQt. And with PyQt, you can release your program for Windows without any code change, because Qt and python support Windows natively.
The toolkit is very well written, full featured, with a very clean and good architecture, plus excellent documentation, tutorials and examples. Please check doc.trolltech.com to see by yourself. Read also, if you haven't done it yet my Analysis on this. Qt is simply two years ahead of Gtk, as I have previously said.
Kde uses great and fun technologies, which are very good documented and easy to use. Check deverloper.kde.org, especially the tutorials, documentation and architecture links. In Gnome, it is a pain to develop a Bonobo component or the equivalent of a kio_slave, as was explained at the OSDEM by Mathieu Lacage.