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

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-12-08 12:16:11
[Download RAW message or body]

Hi,

this is Mr. Trader speaking. Give me all your stocks and I will
run away with your money. Ooops, that was my other job :-)

Ok, servicetypes are your friend. You can put all kind of information
in a servicetype including supported interfaces.

If you have three interfaces like

Edit
MultimediaPlayer
SpreadSheet

you may want to create three servicetypes and put the required
interface names in the servicetype. See how KOffice deals with
servicetypes.

Then you can query the trader for an application that implements a
certain sevrice type.

However, I tested that the last time before KSyCoCa but it should
still work that way ...

Bye
Torben


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".
>   
> > 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]