I was out having a pint with a fellow when he mentioned he uses (and quite likes) Evolution as his email client. He had a few gripes about it, but then don't we all when it comes to the software we use day-in and day-out? He then mentioned how he was surprised at just how huge a program it was. i asked if he knew how many lines of code went into Evolution, and he guess about right. I then asked him if he could guess how much had gone into Kontact; he though a little less than Evolution, but probably a similar amount. This is, however, far from the truth. Kontact is dramatically smaller that Evolution in terms of code count, even when taking into consideration all the various apps that are associated with it (KMail, KOrganizer, KAddressbook, libkabc, the various kioslaves). Then he asked a very interesting question: if I wanted to make a KDE mail app that was an alternative to KMail, would I be able to, would the KDE project encourage such an effort, and how much work would it be?
I smiled, sloshed back a swig of frothy brew and started to explain how KDE apps such as KMail were put together. For networking there are ioslaves, which get things such as SSL and TLS support nearly for free. These ioslaves are easily reusable via the KIO framework. His theoretical email application would only need to pass URLs and fill buffers with messages when requested to send email, and do similarly (if in the reverse direction) to receive emails. Without writing a single bit of code to specifically speak the RFC protocols, his app could send via SMTP and ASMTP with or without SSL or TLS and receive emails via POP3 and IMAP (again with similar SSL/TLS support). This means his KDE mail app would only need to provide local storage of email (assuming it wasn't pure IMAP) and a user interface that had a folder browser, reader and composer. The KDE addressbook library grants a ready-made contacts solution, and sprinkle in some configuration dialogs using the new KConfig Xt and you've got a mail app. Configuring toolbars, opening/saving files, customizing keyboard shortcuts and more are very nicely wrapped by classes that grant you that functionality in a few lines of code each.
But this doesn't just mean faster development. It also means that when a bug is fixed or an optimization committed by the KMail developers in the IMAP implementation (for example), his mail app would also receive that fix. And vice versa.
It also means that since KMail and my friend's new mail app would both rely on the same basic components, they would also stand a much better chance of interoperating properly. They could share account settings and address books, for example, and basic UI elements orthogonal to email usage (e.g. toolbars and their configuration) would be similar in each.
This solid use of components is a great boon to the developer. But it's also a boon to the user. Why? Well, by empowering the developer, KDE provides a better chance the user will get what they want. Applications with similar scopes can be developed with as little duplication in effort as possible, and custom development can harness the work of those that went before (even if they went in a slightly different direction).
Other platforms have promised or are promising highly componentized environments. KDE actually delivers that today.
Syndicate Blogs
Re-usability of code is the key
I completely agree with you about the benefits of componentised development, Aaron. It really is great to be able to rapidly build applications using KParts, KIO Slaves and all of the other useful things that KDE frameworks provide.
I also agree with Brad that the re-usability of components and code has benefits beyond ease of coding and clarity of code. The ability to distribute enhancements and patches so rapidly to applications which inherit from core components really is a boon, and one of the great strengths of using OO languages for GUI and OS work. If you look at Gnome's work on their file selector for example, it is going to take a long time to stabilise all applications and ensure that they are using the same one, where in KDE apps, it is instant, simply because everyone has always been instantiating the file selector and using it with the same couple of lines of code and left it to the KDE core libraries to do the hard work. Toolbars are another good example. While Gnome's HIG is praised for bringing visual stability to toolbars and making sure that they use a given size of icon, borders are the right width, positions are precise, etc., we don't have to care... It's all done for us. Not to mention free toolbar editing.
I would also like to point out that the network transparency of KDE applications is wonderful as an app coder and DCOP really is superb as a glue to allow us to perform complex functions with trivial amounts of code. KParts too, are completely inspired.
These systems are what makes KDE programming such a joy for me as a coder, and the types of innovation that we need to see to develop Linux applications quickly and in a stable and productive way.
more than just components
I think there is more to it than just the re-useable components issue (which is assuredly an important issue). The use of inheritance is also a huge saver of effort, and reducer of bugs - as an example, the gtk tree widget code is of the order 17K lines (from wc -l in a very unscientific way).
The use of C++ is also a useful way to avoid bugs in memory management. Glib memory management helpers can do some of it, but the C++ approach is more rigourous.
The other critical factor is the availability of clear and comprehesive developer documentation. We are getting there, but it isn't quite there yet.
Those features don't come for free though, and the skills required for Gnome (or anything else C based) are much more common than C++ and Qt skills. We need to reduce the entry steps for KDE. I'll try to blog up some ideas on this later.