[Kde-pim] Intra-module dependencies in kdepim

Volker Krause vkrause at kde.org
Mon Oct 5 15:51:57 BST 2009


Hi,

as you probably know, there have been various problems with the dependencies 
inside the kdepim module since the runtime/apps split of the release 
tarballs. With moving the most used stuff out of akonadi_next into kdepimlibs 
the most pressing issues have been resolved recently, but there is still more 
to do. Since I have to introduce some more dependencies I though it might 
make sense to clean some of this up before ;-)

akonadi_next: A development playground for new components for libakonadi, some 
if which is already used by applications before it is API-stable. The number 
of actually used stuff is reduced to zero again I think, so no immediate
problem, but this will likely change again in the future.
Possible solutions: experimental library as part of kdepimlibs like it has 
been done for KNotificationItem or copies in every module that uses it. Since 
we only have four at most (apps, runtime, extragrear, playground), temporary 
copies and more aggressively pushing to kdepimlibs seem the least ugly 
solution to me.

libkdepim: A total nightmare as nearly everything uses it. Fortunately most 
classes in there are independent from each other though. I propose we try to 
eliminate that one step by step:
- move stuff that is only used in one place to that application, the KScoring* 
stuff for example is only used by KNode and there is next to no chance that 
KMail will ever use it in the future.
- do not allow to put new stuff in there
- push stuff used in multiple places into kde[pim]libs, the date/time edit 
widgets to kdelibs for example, or the uistatesaver
- let's see what still remains after that ;-)
The goal would be to have less and less components depending on libkdepim 
which gives us more freedom when moving stuff around and avoids the libkdepim 
copy in the runtime tarball.

akonadiconsole: ended up in runtime, due to the dependency mess. Should IMHO 
be moved back to apps. The only blocker currently is akoandi/kcal AFAICS. 
That seems to contain mainly obsolete models (not using ETM yet), so we could 
just move that into akonadiconsole for now, which avoids that they get used 
anywhere else.

examples: there are a bunch of examples in akonadi/clients, more are part of 
the upcoming merges from the akonadi-ports branch. They should be independent 
of internal/non-installed libs and eventually moved to the kde-wide example 
module IMHO. Even if that will not be created (I haven't seen the result of 
that discussion yet), our examples should probably not be in the runtime 
module, kdepim/examples maybe? or somewhere in playground/pim?

Now on to the new stuff: I'm about to merge the current state of 
libmessageviewer from the akonadi-ports branch. That's the Akonadi/KMime port 
of the message viewer of KMail, extracted and made a stand-alone library 
(depending, among other things, on libkdepim, libkleo and libkgpg, ie. three 
libs in kdepim/apps, not movable to kdepimlibs currently). Besides KMail (and 
hopefully KNode) this will also be used by the Nepomuk email feeder agent, to 
do message decryption. With the feeder agent currently in kdepim/runtime, you 
can see what made me think about the dependency mess in the first place ;-)

Despite obviously belonging into kdepim/runtime the only possible solution I 
can see currently is to move the feeder agent to kdepim/apps. It shares a 
small amount of code with the agents for contacts and calendar, this would 
need to be copied for now. Some of this is at least supposed to end up in 
libraries eventually.

To at some point move it back to runtime we would need to get rid of its 
libkdepim dependency, get rid of the deprecated libkpgp and make libkleo and 
libmessageviewer API-stable and move them to kdepimlibs, so this is only a 
very long term option.

What do you think?

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20091005/4f320255/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list