Benjamin Fritzsche posted <[EMAIL PROTECTED]>, excerpted below, on Thu, 22 Dec 2005 22:51:39 +0100:
> Can anyone here shed some light on the connection between these three > apps? > > I'm working on getting my iPAQ (3970) to sync with KDE. And it is working > now with syncekonnector which is now in portage. > > It just suddenly worked after I played around a bit with these things. I > Just don't understand how they work together and documentation seems to be > very limited. > As I understand it till now mulltisynk (with k in the end) seems to be a > frontend to Ksync which seems to be an application for syncing PDAs. But > the syncekonnector only seems to work if I set it up in Kitchensync?!? Is > kitchensync meant to be a replacement for Ksync in the long term? on the > other hand syncekonnector won't compile if ksync isn't installed?! Perhaps someone else can get you something more accurate, as I don't have a handheld to worry about, but I'm a KDE user and (I think) understand a bit about how KDE works and the KDE devs think. Note that nearly all of the family of libraries and apps designed to work with handhelds are part of kdepim, and come packaged together in the tarball supplied by KDE. KDE tends to be very modular but very interconnected, such that many modules depend on others, particularly within the same tarball and against kdelibs and the base apps and libs in kdebase. This is by design, easing code reuse and preventing the same thing from having to be rewritten five different ways for different apps. Now, each of the big tarballs as shipped is designed to be able to be split apart, as Gentoo and most other distributions now do, so one doesn't have to install everything. However, the interconnectedness often means more has to be installed than one might intuitively consider required. To answer your question, yes, long term (with KDE 4, due out late next year altho full schedule hasn't been nailed down), kitchensync will be replacing a number of other modules, however, to throw another kink into things, it's a /different/ and /new/ kitchensync that has just been rewritten at one of the recent KDE gatherings, not the existing kitchensync, which is just one of several modules. (The name kitchensync, of course, is a joke. It was formerly said, generally as a criticism, that KDE included everything but the kitchen sink. Well, the KDE devs addressed that gripe head-on, and now, KDE even includes the kitchensync! =8^) Back to the present, as I understand things, there's one or two different front-ends, but they depend on a number of different backends and libraries, depending on exactly what hardware you have. So, yes, you'll have several different components merged, but that's just how KDE works, and if you check the ebuild to see where the sources are from, you'll see that most if not all of them are actually part of the same kdepim tarball, and would be merged as a single giant package (along with a bunch of other stuff, kmail, kroupware, etc) if you had chosen the monolithic kdepim package instead of all the little components. Choosing the little components, however, is often better, because you may not need /all/ of them (I don't use the handheld stuff but use kmail, which depends on kroupware, for instance), and even if you /do/ merge everything, if a security or other update is required, it's far easier to merge just the -rX versions of the one or two components that are updated, than it is to update the entire monolithic kdepim package. Make sense? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- [email protected] mailing list
