[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Deploying new kdelibs classes
From:       Aurélien Gâteau <agateau () kde ! org>
Date:       2011-04-25 22:17:00
Message-ID: 4DB5F2DC.7050500 () kde ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]