[Kde-pim] Intra-module dependencies in kdepim

[Volker Krause]

On Monday 05 October 2009 16:51:57 Volker Krause wrote:
> 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?

As Allen pointed out correctly, I forgot KAlarm: AFAIU currently it uses some 
parts of kdepim/akonadi/resources/shared and ical, ie. code from the runtime 
part, which breaks the apps/runtime separation. Besides copying that code I 
don't see any other short term solution. Long-term we probably want a kalarm 
library in kdepimlibs, otherwise putting stuff into Akonadi is of limited use 
as noone else can access it.

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/20091006/82c7c6f3/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/