From kde-core-devel  Mon Apr 25 22:17:00 2011
From: =?UTF-8?B?QXVyw6lsaWVuIEfDonRlYXU=?= <agateau () kde ! org>
Date: Mon, 25 Apr 2011 22:17:00 +0000
To: kde-core-devel
Subject: Re: Deploying new kdelibs classes
Message-Id: <4DB5F2DC.7050500 () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=130376986803124

On 23/04/2011 23:22, Jaroslaw Staniek wrote:
> Aurélien, I am writing regarding
> http://agateau.wordpress.com/2011/04/21/kde-ux-2011/
> One thing, about deploying the kmessagewidget (and similar things) in
> kdelibs. If it's part of kdelibs 4.7 or something, apps that support
> kdelibs < 4.7 would have to fork it (unless distro backports given
> classes to previous kdelibs but this it very bad idea and technically
> and coordination-wise).

I agree it is a problem. I used to copy relevant classes into Gwenview
code when it was a "3rd-party" application.

> How to solve that? I am thinking about releasing additions to kdelibs
> as separate libraries like kdelibs47.so etc. and then merging only in
> 5.0.

That would mean no new classes in what I would call kdelibs46 (ie,
current libkdecore, libkdeui...), all new classes go to kdelibs47, then
when we start KDE 4.8, kdelibs47 is frozen for new classes, which go
into kdelibs48, is this correct?

It certainly looks clever. I am just worried about the cost for loading
these additional libraries? Would loading more libraries impact
application or desktop startup time?

Aurélien