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

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       Simon Hausmann <shaus () helios ! med ! Uni-Magdeburg ! DE>
Date:       1999-12-08 10:23:36
[Download RAW message or body]



On Wed, 8 Dec 1999, Waldo Bastian wrote:

> On Tue, 07 Dec 1999, 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.
> 
> Yes.
>  
> > 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).
> 
> Yes.
>  
> > 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.
> 
> Yes.
>  
> > Another problem is the name of the DCOPObject that receives the DCOP calls, I
> > suppose there should be also an standard on this.
> 
> Yes. We need the service/servicetype/trader stuff for this. So that you
> can say something like: Give me an application who can play midi's and
> supports interface "XYZ".

I'm neither Torben nor Mr. Trader ;-) but I can try to answer :-)

I like the idea of creating/defining some generic DCOP interfaces, and
IMHO we already have a place for that: kdelibs/interfaces .

Just create your FooInterface (as .h file ) and put it in there, together
with a servicetype .desktop file.

Example:
[Desktop Entry]
Type=ServiceType
X-KDE-ServiceType=FooService
Name=Antonio's Service for Foo Interface

Install this .desktop file in $kde_servictypesdir .
(this will make ksycoca recognize it as service and make it available
through KServiceType/KTrader)


If an application implements your FooInterface, then it can add a line
like
ServiceTypes=FooService
to its (application) .desktop file.

This will make it possible to let

KTrader::OfferList offers = KTrader::self()->query( "audio/midi", "`FooService` in ServiceTypes" );

return you a list of services being able to play midi and supporting your
given interface :-)

(what's left is starting and contacting your service/server/application :)

(note that the ServiceTypes field is a list -> you can let a service/app
implement mulitple servicetypes (which can be indirectly bound to an
interfaces) .

Is that what you are looking for, Antonio? :)

Ciao,
 Simon

> > 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.
> 
> See above. Torben is Mr. Trader. I am sure he has a good solution for
> this.
>   
> > 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 ?
> 
> No. This is what we need. 
> 
> A good start would be to write IFace files for a broad range of
> applications. E.g. MidiPlayerIFace, GraphicViewerIFace,
> GrpahicEditorIFace, TextEditorIFace. With perhaps two superclasses like
> "MimetypeViewerIFace" and "MimetypeEditorIFace". All the viewers and
> players would inherit from MimetypeViewerIFace and all the editors
> would inherit from MimetypeEditorIFace.
> 
> That allows you to start a program for a certain mimetype even if you
> have no clue what the mimetype is about or without knowing whether
> there is a special IFace for that mimetype.
> 
> Cheers,
> Waldo
> 
> 
> 
> 

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