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

List:       kde-pim
Subject:    Re: [Kde-pim] Addressbook - link to advance contacts ?
From:       Adriaan de Groot <adridg () sci ! kun ! nl>
Date:       2002-06-12 9:14:03
[Download RAW message or body]

On Tue, 11 Jun 2002, Bryan Brunton wrote:
> No, you miss the point.  Who said KDE was only about supporting KDE
> applications?  This is almost like a conversation with Microsoft:

Yup. We have our own agenda and are in fact beholden to noone but
ourselves. But we have this extra mantra, see, that says "patches are
always(*) welcome". The small print by the (*) says "unless it breaks
something or is unportable." Nowhere does it say "Yea, and the KDE team
shall quiver when third-party applications developers speak, and shall
scramble to provide them with Interfaces and Gadgets so that they may be
satisfied." So write a patch and be done with it!

Enough of this quasi-sarcastic crap, technical arguments below.

> Q: "How do I invoke an addressbook that isn't KAddressBook from a KDE application?"
> A: "Sorry that isn't technically possible.  If you want to do that, you will need to write a few
> thousands lines of code and use our libkabc library.  We could provide a simple invokeAddressBook
> method, but we choose not to do that because we can."

Actually, we could invoke just about any application and KMail could
be extended just like that to launch whatever you like when you click on
the addressbook icon. Gosh, it's no more than a KRun call. So it's
technically possible.

As for providing a single simple way to lanch it with
kapp->lanchAddressBook(), that's a BIC to the libraries and is out of the
question until KDE4. But just doing the

	KConfig c;c.setGroup("General");
	KRun::launch(c.readEntry("PreferredAddressBook"));

thing isn't that hard either.

The whole point is that launching all these apps _doesn't_ maintain a
single programmer's interface and duplicates data all over the place.
That's what Don has already pointed out. We had three applications with
three different interfaces (both UI and API, but we're concerned with the
PIA now). That's why, for example, KPilot could _only_ sync with
Abbrowser. It had the DCOP API that KPilot could use to do a sync with. If
we _had_ a single DCOP interface it might be done. But we have _chosen_ to
not use a DCOP interface for address data in KDE3. It was too slow.
Instead, there's a library. A single reasonably documented interface that
both UIs and applications can use to get at the addressbook data.

This is the API we use. Live with it. Living with it means that you get
seamless integration all through KDE for free. Ignoring it means that,
gosh, even if KMail can just start your address book with a KRun call,
there's no way to get a selected address back to KMail short of
drag-n-drop, because there's no interface for it.

> Of course KAddressBook doesn't suit my needs.  I don't think its a very
> good application: it doesn't scale and it isn't multi-user.  That's why
> I wrote Advance.

A noble goal.

Interoperability has to come from two sides, you know. Both sides have
their requirements and wishes. And both sides are fundamentally lazy.

-- 
+------------------------------+--------------------------------------------+
+ Adriaan de Groot             + Project: FRESCoS                           +
+ adridg@cs.kun.nl             + Private: adridg@sci.kun.nl                 +
+ Kamer A6020 tel. 024 3652272 + http://www.cs.kun.nl/~adridg/frescos/      +

_______________________________________________
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/
[prev in list] [next in list] [prev in thread] [next in thread]