Source Compatability and DCOP
sanders at kde.org
Fri Aug 9 08:19:15 BST 2002
For KAddressBook DCOP was used as a temporary solution until a more
permanent solution was implemented. In this case the DCOP interface
was not public.
In the future I think it may make sense to use DCOP for private
communication between a family of tightly coupled applications like
kde-pim. In which case these DCOP interfaces will not be public.
I would like a standard way of marking such interfaces as being non
I won't limit my use of DCOP to only creating public APIs, that makes
no more sense than forcing all C++ member variables and methods to be
public. Please think about that and then it should be obvious it's
useful to have non public DCOP methods.
For the record I haven't promised to kept compatibility with any
existing DCOP apis. I don't regard them as a subset of the frozen KDE
On the other hand I have no intention of breaking compatibility, I
would only endorse it if there was a good reason.
On Friday 09 August 2002 03:47, Waldo Bastian wrote:
> On Wednesday 07 August 2002 09:36 pm, Don Sanders wrote:
> > IIRC the KAddressBook DCOP interface was commented as being for
> > the use of KPilot.
> If you type "dcop kaddressbook" it doesn't say "don't use these
> funcions" in large red bold blinking letters.
More information about the kde-core-devel