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

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       David Faure <faure () kde ! org>
Date:       1999-12-07 18:10:20
[Download RAW message or body]

I think that when one applications wants to use another one,
it should use KParts (the next one) and load the other app's shared lib,
instead of using DCOP - for the same reasons that we dropped CORBA.
And KParts provides open, close, save, ...

Of course if you are talking about scripting, then this doesn't apply :-)
You don't really say what those DCOP interfaces would be used for.

On Tue, Dec 07, 1999 at 01:29:52PM +0100, Antonio Larrosa wrote:
> Hi,
> 
> I've been thinking about how fast and easy it is to write a DCOP interface
> for any application and all that. But before everyone starts doing so, I think
> we should write a standard.
> 
> For example, each application should have an "Open(QString)" method that opens
> the given file (just as they are 'forced' to have an "Open ..." item in the
> "File"
> menu). And a "Save(QString)" which saves the current file in that url (although
> that would be trickier as sometimes 'current file' is not well defined, but I
> suppose you get my line of thinking).
> 
> I've come to this because I thought of adding a DCOP interface to KMid, and
> Greg Lee, has already added one to KMidi which is different to the one I thought
> to implement. With an standard we could be sure that any application will be
> able to use any of them independently and people will write scripts much more
> easily.
> 
> Another problem is the name of the DCOPObject that receives the DCOP calls, I
> suppose there should be also an standard on this.
> 
> Also, is there any _simple_ way to know which apps are installed on the system
> that implement a given interface or a superset of it ? ( "superset" = "which
> includes the given one as a subset" :) ) 
> I suppose KTrader in kio has something to do with it, but it doesn't have any
> docs, so it seems it's just for specific uses.
> 
> Anyone is doing something like that ? I have very little time and already
> promised to do other things which aren't so urgent, but I think I should do
> before this.
> 
> The basic idea would be to have something like a MidiPlayerIFace definition
> distributed with KDE (along with a GraphicViewerIFace definition, a
> GraphicEditorIFace definition, a TextEditorIFace definition, etc.)
> with "Load(QString)", "Play(void)", "Stop(void)", "Pause(void)", and that
> any application can use this interface to play midi files, be it with KMidi
> or KMid.
> 
> It's somehow similar to mimetypes (the user should also have a preference list),
> but not exactly the same.
> 
> Opinions ? Is this too crazy ?
> 
> Greetings,
> 
> PS: I know I haven't defined well how it should work, but that's why I post it
> here, to let the collective mind think about it :-)
> --
> Antonio Larrosa Jimenez
> Student of Mathematics
> antlarr@arrakis.es        larrosa@kde.org
> http://www.arrakis.es/~rlarrosa
> Klein bottles for rent -- inquire within.
> 
> 

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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