[gentoo-desktop] Re: Kitchensync, Ksync, Multisynk

[Duncan]

Benjamin Fritzsche posted <200512222251.39189.BFritzsche@×××.de>,
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


-- 
gentoo-desktop@g.o mailing list