why kdelibs?

[John Layt]

On Friday 29 October 2010 06:08:35 Stephen Kelly 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,
> 
> Steve.

Some excellent points, and it makes clear the sort of areas we need to be 
working on.  Currently choosing to use kdelibs or any other KDE library just 
as an extra Qt module usually means more pain, not less, which really should 
be our selling point.

Do we have a wiki page were 'what can be fixed now' and 'what needs fixing in 
KDE5' has been/can be written down?  Perhaps a version of 
http://techbase.kde.org/Projects/Mobile/PlatformModifications but with a 
little more detail?

While a lot of the dependency fixing would break BC and so can't be done in 
the KDE4 SC, I suspect a lot of 3rd parties would actually ship their own copy 
of of what they use anyway, rather than using shared libraries?  In which case 
we can do compile time switches for them to just get what they need without 
all the other stuff?  Of course there would be a lot of work providing the 
alternative paths, but it would be in preparation for KDE5 and thus less work 
to do then?

For example, KLocale needs KConfig on KDE platform to load the format 
settings, but a Qt program would not want those settings so a QLocale backend 
could be used instead and thus remove the need for KConfig.  In fact, KLocale 
is a problem as if you don't have kdebase/runtime/l10n installed you get the C 
locale, and even if you do have the files there's no guarantee they will be 
the same as what QLocale will return for the rest of your app, or what your 
Win/Mac/MeeGo/Gnome system settings are. I'm working on that.

For those libraries like KIMAP and the itemview stuff that don't really need 
kdecore/kdelibs stuff at all perhaps kdesupport is the right place for them?  
Perhaps the 'K' name is also an issue, if they don't need K stuff, then just 
call them QSomething or a funky non-K name?  From a promo point of view, we 
could then advertise libraries as being 'By KDE', 'Using the KDE Platform', 
and 'For the KDE Desktop'.

The other issue is platform portability, stick with Qt and you know it works 
on every platform with no extra effort, even if the tools fall short in some 
areas.  Use kdelibs and you will have problems on Win and Mac trying to decide 
how to package and distribute.  Work is ongoing on Win to make it happen, but 
Mac appears to have stalled somewhat?

Of course, once the splitting work is done, and it's easily portable, then 
eternal vigilance is needed to make sure it stays that way, which probably 
means more stringent rules around kdelibs.

John.