From kde-pim Thu Nov 28 06:47:47 2002 From: Don Sanders Date: Thu, 28 Nov 2002 06:47:47 +0000 To: kde-pim Subject: [Kde-pim] Re: [PATCH] Fixes Bug 49802: vcard does not get displayed, kmail shows error instead X-MARC-Message: https://marc.info/?l=kde-pim&m=103846551402070 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. 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. Moving the KMail Part interface into kdelibs isn't a good solution, as it means pim users will end up having to update kdelibs to update kdepim, and that means they will end up having to update all of KDE. Don Sanders / sanders@kde.org KMail Adopter / kmail.kde.org KDE PIM Co-founder / kdepim.org KAddressbook Founder / kaddressbook.org KDE Contributor / kde.org On Thursday 28 November 2002 08:49, Marc Mutz wrote: > On Wednesday 27 November 2002 22:33, Ingo Klöcker wrote: > > On Wednesday 27 November 2002 08:11, Bo Thorsen wrote: > > > > > > I definately think kmail should be moved to kdepim. Stuff like > > > this shows that kmail has compile time relations to pim while > > > it has none to the other network apps (knode might be the > > > exception). I understand that this has previously been decided > > > against :-( > > > > In the past there were probably some arguments against moving > > KMail to kdepim (like what?). But in the meantime the arguments > > for a move, especially with respect to Kroupware and Kaplan, > > clearly overweigh (IMO). > > > > Kaplan is designed to host several independent apps. Kroupware will > be ported to this framework before merging. Thus, this argument > doesn't count. > > OTOH, if you move KMail, you need to move libkdenetwork and > mimelib, too. > > If you move libkdenetwork and mimelib, you need to move at least > KNode and Korn. So you end up with a bloated kdepim and a bony > kdenetwork. Not what I call a solution. > > Starting from bare C++ (abstract classes/interfaces) over Qt > (QMetaObject) to KParts, we have a framework that encourages loose > coupling between components. We should prove it's worth instead of > going back to procedural "I want that code, so I need it at compile > time" thinking. Wrong thinking. What you need is the interface (or > not even that) and that can go into a common place such as kdelibs. > > Marc _______________________________________________ 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/