Ein Problem, das ich mit dem Schreiben von KDE Bibliotheken derzeit habe, ist das ich nicht weiss, wie zukunftssicher diese sind. Die Chancen stehen recht gut, dass ich meine Software in 5 Jahren bedenkenlos in C# (mittels DotGnu und Mono) oder Python schreiben kann. Nur brauche ich auch dafür einen Desktop und diverse andere Bibliotheken. Es kann weder erstrebenswert sein, bis zum Ende der Zeit auf C++ festgelegt zu sein, noch für jede Programmiersprache einen neuen Desktop zu schreiben. Das halb-manuelle Schreiben von Wrappern ist viel Arbeit und schon allein deswegen sind die Wrapper praktisch nie komplett. Was benötigt wird, und das möglichst schon für KDE 4, ist die Möglichkeit mit anderen Sprachen ohne manuelle Arbeit auf C++ Bibliotheken zuzugreifen. Es gibt verschiedene bestehende Ansätze, beispielsweise XPCOM und die Benutzung von QObject Slots, wie QSA es macht. Alle bestehenden Möglichkeiten haben aber genug Nachteile, um sich in der KDE Welt nicht für alle APIs durchzusetzen. Meine derzeitige Hoffnung liegt auf TrollTech, denen es wohl kaum entgehen kann, dass der C++ Markt schrumpfen wird (wenn er es nicht bereits tut) und hoffentlich so etwas dagegen tun.

Mit der Sprachenunabhängigkeit kommt auch die Notwendigkeit, die kdelibs und Qt besser zu unterteilen und strukturieren. Klassen wie KSharedPtr, QRegExp und QValueList werden von anderen Sprachen nicht gebraucht, mal davon abgesehen, dass man Templates nicht in sprachenunabhängigen APIs benutzen kann. Viele Dinge wie Netzwerkzugriffe erledigt man besser mit der Standardbibliothek der jeweiligen Sprache. Andere könnte man zwar mittels einer gemeinsamen API benutzen, sind aber besser nativ zu implementieren, zB kann DCOP in die Remoting-Architektur der C# CLR eingebaut werden.

Dazu kommt bereits jetzt, dass es für Qt-basierte Server wie Knot mehr als nützlich wäre, wenn die GUI vom Rest getrennt wäre. Bevorzugen würde ich eine Lösung, wie ich sie jetzt für die GStreamer-Bindings und Knot benutze, mit C++ Namespaces unterhalb von KDE (zB KDE::UI, KDE::Core etc). Das würde hoffentlich die Navigation durch die APIs vereinfachen und Konflikte vermeiden, wenn man die nativen Bibliotheken der jeweiligen Sprachen mit KDE APis zusammen benutzt.