Chani wrote:

I didn't get a "Qt is all you need" vibe at DevDays, but the Qt developers there are completely unaware that the kde libraries are available and usable. Most still think that KDE is a monolithic desktop environment, and set of applications. Nothing independently useful or usable.

So awareness is one issue, and one which I'm trying to address. Another is interdependence in kde libraries, and what I think of as upside-down-ness in parts of the stack and modules. kdelibs is mixture of two things: a set of libraries, and a platform. KJob is in the libraries conceptually, as is KIMAP, whereas KStandardAction, which someone mentioned, KStandardDirs, KSyCoCa, KGlobal etc are platformy because 1) They provide benefit to well integrated KDE applications, and 2) They provide no benefit to Qt developers who are not creating 'KDE integrated' applications. Qt developers often have control over distribution of their own dependencies and can be more specific in code about data directories etc than KDE applications.

Because of interdependence though, a developer who wants to use KIMAP must also use KStandardDirs, KComponentData, KGlobal and everything else they come with. It should be possible to use a an IMAP library without depending on the entire 'integration platform', so I think of kdelibs as upside-down.

Even if communication about the separate KDE Development Platform had reached the Qt developers at DevDays, I don't know if they would care, because they would want libraries, not a 'platform' with all the buy-in baggage that entails.

The result for the Joe the plumbers^W^W^W Gregory Schlomoffs of this world is privately managed ifdefs and hacked target_link_libraries lines.

http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-development- platform

Thinking of the kde libraries in terms of how people like Gregory and other software vendors which create and deploy (and self-manage the deployment, paths, dependencies etc) could see and use them could be a good way to make kdelibs more modular and independently and make the 'platform integration pieces' appear much higher in the stack.

Anyway, making a list of (mostly-)independent libraries which are potentially interesting to a Qt developer is easy:

KLocale: More powerful i18n than QObject::tr and friends. Based on gettext. KConfig: More powerful settings management than QSettings. KJob:    Asynchronous APIs for executing tasks. Includes progress reporting. Kross:   Cross-language script interpretation Threadweaver: Threading APIs to suit practical needs of applications. KDEUI/ItemViews: Add-ons to the Qt itemviews API. KMime :  Qt based library for handling emails KIMAP :  Qt based library for asynchronous IMAP communication

I've only included things which I have some familiarity with. The list could be made longer of course.

All of those could be useful to 'Qt applications', and they only depend on Qt for the most part, or other libraries in the list (KIMAP depends on KMIME and KJob, but Qt has no equivalents for those). Conceptually there's no reason for them to depend on 'the platform'.

The fact that they can't be used independently out of the box makes communicating about them difficult. "If you're using Qt ItemViews for serious business, you want to use the stuff in kdeui/itemviews, but it depends on klocale, kconfig, kfile etc etc at shipping time, none of which are used." Actually kconfig is used in one place, but that's removable.

Hopefully there's some coherence in all that. I had intended this email to be much shorter.

All the best,