A home for KIMProxy

Olivier Goffart ogoffart at tiscalinet.be
Sun May 30 22:27:57 BST 2004


Le Dimanche 30 Mai 2004 18:54, Will Stephenson a écrit :
> On Friday 28 May 2004 19:45, Jason Keirstead wrote:
> > [...] there is a funamental misunderstanding of
> > what kdelibs/interfaces is. kdelibs/interfaces are *not* interfaces to
> > other apps. They are *interface classes* to be implemented, like
> > KTextEditor, KScriptInterface, etc. The .cpp files hardly even have any
> > code in them.

KIMIface is presisely an interface classe to be implemented. and there are 
even no .cpp

Unlike others, KIMIFace can be implemented by all applications. But i don't 
see the problem to have it in interfaces.
Since KTrader or KPartd can't handle the fact that it can be used by several 
applications in the same time, KIMIProxy is required.

And, several others interfazces have .cpp there.
I realy don't see the problem.

> > libkimproxy defintly does not belong in here. The DCOP IDL spec for it
> > could go in here, because that describes a generic interface. But a
> > library that contains implementation code like libkimproxy would be way
> > out of place.

Where ?
interfaces is the place IMO ?

>
> How about the following proposal:
>
> interface and service definition in interfaces/kimproxy

Yes

> library in kio/kimproxy

Why KIO ?
Unlike you have another better solution, I think interfaces is the good 
choice.

Maybe you just do not need to split kimiproxy and kimiface in two different 
paths.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040530/51f456d6/attachment.sig>


More information about the kde-core-devel mailing list