[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposal: New module "kdepimlibs"
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2006-04-19 8:51:20
Message-ID: 200604191051.20647.schumacher () kde ! org
[Download RAW message or body]

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@kde.org>
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic