split kdepimlibs

[laurent Montel]

Le mardi 26 août 2014 11:50:50 Kevin Ottens a écrit :
> On Tuesday 26 August 2014 11:20:25 laurent Montel wrote:
> > Hi,
> > I will split kdepimlibs as it
> > 
> > akonadi (need to find another name because it's still used)
> > akonadi-abc
> > akonadi-calendar
> > akonadi-contact
> > akonadi-mime
> > akonadi-notes
> > akonadi-socialutils
> 
> To me it sounds like some of those things could be regrouped now. What about
> also bringing the akonadi server on board? Having a bigger akonadi
> framework containing server (right now in kdesupport), some access libs and
> a few default plugins would make sense (it looks like a KIO like
> framework).

Regroup as a framework as :
akonadi-framework (better name)
 -> src
     -> akonadi-abc
     -> akonadi-calendar
     -> akonadi-contact
     -> akonadi-mime
     -> akonadi-notes
     -> akonadi-socialutils
     -> server (Dan must speak about it if he wants to move here)
     -> plugins serializer (moved from kdepim-runtime)



> > gpgme++
> > kabc
> > kalarmcal
> > kblog
> > kcalcore
> > kcalutils
> 
> This one looks like a dumping ground of random things. Maybe some of it
> should move in other frameworks?

Sergio can speak about it

> 
> > kholidays
> > kimap
> > kioslave
> 
> Definitely not a framework. Are all the ioslaves in there still used? I
> think at least some of them can be let go. The others could go in
> kio-extras I guess.

kioslave indeed not a framework. I think that just pop3 is used by kdepim

yes others can move to kio-extra

> 
> > kldap
> > kmbox
> > kmime
> > kontactinterface
> 
> Probably should go in kdepim or kontact itself. Similarly the content of the
> kdelibs/interfaces folder moved out of KF5.

We extracted it in 4.x to allow to create kontact plugins for other 
application.
If we merge in kdepim we will not able to do it.

> 
> > kpimidentities
> 
> Maybe deserves a better name? kidentitymanagement?

Ok seems better. I will work to rename it.

> > kpimtextedit
> 
> I suspect it could get a better name, but couldn't decide yet. :-)
> Also I wonder if some of it could/should go in ktexteditor? But I don't know
> the respective feature sets enough to be sure.

For me it's kdepim specific. 

> > kpimutils
> 
> Looks like another dumping ground of random classes. Each class should
> likely find a new home.

Ok I will try to move them.

> > ktnef
> > kxmlrpcclient
> > mailtransport
> > microblog
> > qgpgme
> 
> Couldn't that be merged with gpgme++? This one already builds several
> variants depending what it finds on the platform, why not treat the Qt
> integration in the same way?

Really I never study this lib, there is not unittest, I don't know how it 
works and I don't know why there is several build.
I will not work on.

> 
> > syndication
> > 
> > is it ok for you ?
> 
> I tried to point out things which would be harder to address after the
> split. So I think we should have discussions and decisions about the points
> above before being able to proceed.
> 
> Regards.



-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,  http://www.kdab.fr