Re: Deploying new kdelibs classes
On Sat, April 23, 2011 10:22 pm, 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). 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. Perhaps there's already solution I am not aware of. I'm not aware of any policy in the past to prevent new classes being added to kdelibs. It's something that third party apps have always had to cope with. Are you perhaps thinking of the rule in kdepim which says that it must build against the previous version of kdepimlibs? -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Deploying new kdelibs classes
A Dissabte, 23 d'abril de 2011, Jaroslaw Staniek va escriure: 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). Well, that makes sense, if you want to use a new feature, you have to depend on a new version, why you do not think that's acceptable? Albert
Re: Deploying new kdelibs classes
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
Deploying new kdelibs classes
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). 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. Perhaps there's already solution I am not aware of. -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org)
