From kde-pim Thu Nov 28 14:45:59 2002 From: Cornelius Schumacher Date: Thu, 28 Nov 2002 14:45:59 +0000 To: kde-pim Subject: [Kde-pim] Re: [Kroupware] Re: [PATCH] Fixes Bug 49802: vcard does not get displayed, kmail shows err X-MARC-Message: https://marc.info/?l=kde-pim&m=103849488927311 On Thursday 28 November 2002 14:08, Don Sanders wrote: > On Thursday 28 November 2002 18:22, Cornelius Schumacher wrote: > > On Thursday 28 November 2002 07:47, Don Sanders wrote: > > > KMail and its dependent kdenetwork libraries need to be moved > > > into kdepim. Those dependent libraries are mimelib and > > > libkdenetwork (the later could do with a renaming). Other > > > kdenetwork apps that also rely on these libraries should be moved > > > into kdepim also. > > > > In how much code would this result? What would be the size of > > kdepim after moving KMail, its dependencies and the apps that > > depend on that? How would this compare to other KDE CVS modules? > > So kdepim would become 37056 K, swapping places with kdenetwork to be > the 3rd largest KDE source package I have. I think that's ok. Agreed. It's not that bad as I thought it would be. > > > This is because kdepim should be able to make independent > > > releases, like KOffice, and the users should be able to get all > > > there pim apps from one package. > > > > Distributions tend to split up the CVS modules for making packages. > > So what the user gets isn't necessarily defined by the structure of > > the CVS. > > Sure, but I don't see that as being significant. I mean this doesn't > alter my thinking that kmail belongs in kdepim. I'm concerned about > what KDE does, not what other distributors do. You were talking about users and users get their packages from distributors. For users it simply doesn't matter where the source code is in CVS. > The reason why kdepim > was created was so that certain apps, like addressbooks, mail clients > and organizers could all be put in the same package. Now that KMail > has been made into a part and unified with its siblings it's just > common sense to put it in the same package. The whole point of KPart technology is to reduce dependencies between components so that it isn't neccesary to put all the code in one place. But I agree that KMail would fit into kdepim at least as well as in kdenetwork and that we might get dependencies in the future which make this move necessary anyway. > > As a developer you can update parts of kdelibs and you will have to > > anyway because libkabc is in kdelibs. Making a separate release of > > parts of kdelibs is certainly also possible, although it will > > require some additional effort. > > These kind of dependencies are a hassle for users and they really > should be minimized. I don't find the idea of a separate release of > certain parts of kdelibs enticing. Yes, but at least for libkabc this will be necessary, if you want to release something based on Kaplan before 3.2. We are planning some bigger changes to unify the Resource framework for addressbook and calendar data. -- Cornelius Schumacher _______________________________________________ kde-pim mailing list kde-pim@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-pim kde-pim home page at http://pim.kde.org/