Proposal: New module "kdepimlibs"
Cornelius Schumacher
schumacher at kde.org
Wed Apr 19 09:51:20 BST 2006
On Wednesday 19 April 2006 02:08, Matt Rogers wrote:
>
> Is the ability to deviate from kdelibs policies and release schedules
> really that important? I could see this causing all kinds of problems, but
> I am a bit paranoid nowadays. :)
It's not the primary motivation for the proposal. But as the topic of
releasing modules separately regularly comes up I mentioned it because we
would be better prepared to handle it with the better modularization. I
personally would prefer to not make use of this option.
> I'm not sure that all of this belongs outside of kdepim. Are
> libkmime,libkholidays, and libsyndication already used outside of kdepim,
> or are we just putting them some other place so that other projects can use
> them?
libsyndication is a rewrite of a library which was forked from the kdenetwork
module (where it's used by knewsticker) and duplicated in kdepim. It
certainly would clean things up to only have one shared library for this
specific functionality.
libkmime is a border case. Having decent access to email objects is something
which could well be useful for lots of applications. Search applications are
one example.
libkholidays would provide all applications handling dates with the option to
know about holidays. We are for example still missing the display of holidays
in the calendar which is part of the clock applet. That's a pity, because
it's a feature which would be easy to implement. The only reason it's not
there yet is the problem of dependencies.
> What happened to the rule that two apps had to be using a class (or
> set of classes) before a move to kdelibs could even be considered?
By having something like kdepimlibs it would be easier to follow these kind of
rules because kdelibs would not be the only way to share libraries between
modules, but there would be an intermediate step.
> I think all the functionality of libemailfunctions can and should be moved
> back into the kdelibs as well.
For the specific case of libemailfunctions I'm fine with every solution where
it can be folded back in an existing library.
--
Cornelius Schumacher <schumacher at kde.org>
More information about the kde-core-devel
mailing list