[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]