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

List:       kde-devel
Subject:    Re: DCOP right for that task?
From:       Ravi <ravi () kde ! org>
Date:       2003-11-17 19:04:40
[Download RAW message or body]

On Monday 17 November 2003 12:23 pm, you wrote:

> > The "done right" problem is
> > that of exposing the right interfaces. (I am probably going to get flamed
> > for this, but I think KDevelop 3, aka Gideon, is a good example of a
> > mildly overengineered application that exposes the right interfaces.)
>
> To get this right you mean by Interfaces (as C++ don't have them like Java)
> pure virtual abstract classes - so just decalring the methods.

Yes. Of course you can have default implementations of the virtual functions 
there as well. However, that can let you instantiate the class when you don't 
want to. Typically, you never want to instantiate the base class by itself.

>
> > You can and
> > should use KTrader for figuring out the functionality exposed by each
> > plugin. In particular, no plugin should depend on the existence of
> > another specific plugin, but only on the existence of some plugin that
> > provides the desired interface (or "service"). However, in order to get
> > the desired interface, it should include a header file that describes it,
> > usually in the form of a base class.
>
> Ok thats new to me - never did anything with plugins so i didn't knew that
> there is a way to search for a plugin providing the "service" i need. That
> makes a lot of things much clearer for me.
>
> > Let's look at the example you provide:
>
> [snip]
>
> > When a document has been created, the editor part should query KTrader
> > for a plugin that handles processing of the document. Let's call this a
> > controller:
> >
> > class ControllerBase : public SomePluginType
> > {
> > [...]
> > virtual handleFirewallDoc(FirewallDoc *) = 0;
> > }
>
> so my Interface classes will be inherited from KParts::Plugin - and the
> plugins itself will be inherited just from my Interface and not from the
> KPars::Plugin stuff

Yes, since you are specializing the class to different OS combinations. For 
more information on using KTrader and plugins in general, please see the 
tutorials page on http://developer.kde.org. Hmm, for some reason, I can't get 
to David Faure's tutorial, but the other two should be sufficient.

>
> > Now the document class asks KTrader for a service that handles
> > "FirewallDocs" and has property "OsType=NetBSD". The object that you get
> > is derived from ControllerBase, but the app does not need to know
> > anything more. The plugin, which by now, has been specialized for NetBSD,
> > is the only one that knows about further plugins - the app does not know
> > about the other plugins, and does not need to include the header files of
> > the other plugins.
> >
> > Now, the NetBSD controller knows that no iptables compiler is needed. So
> > it asks KTrader for an service that handles "FireWallDocInstallation" and
> > has property "OsType=NetBSD" which provides an object of type
> > InstallerBase:
> >
> > class InstallerBase : public SomePluginType
> > {
> > [...]
> > virtual installFirewallDoc(CompiledFirewallDoc *) = 0;
> > }
> >
> > This process can be repeated ad infinitum, as you might imagine. Note
> > that we always include only the base class interfaces (exposed API),
> > never anything about the actual implementation of the derived class. When
> > you install you plugins, make sure that each of them has a proper
> > .desktop file; for each each base class (as a general rule of thumb)
> > which exposes a particular interface, you will need a servicetype
> > .desktop file as well. Remember the rule that the only headers you ever
> > include in your code that calls the plugin is that of the base class of
> > the plugin.
> >
> > Now, for most of these cases, you do not require KPart::Plugin since the
> > KGenericFactory interface will suffice for plugins that do not have a
> > GUI. Of course, you can KPart-ify them if you wish. Based on the method
> > described above, you can call functions of other plugins without knowing
> > their exact implementation.
>
> well it needs to add actions so i think KParts::Plugin is requred - but i
> think i understand now how that should work.
>
> > For a DCOP call to work, you must have a running application that exposes
> > that particular DCOP function. If the functions are in plugins, unless
> > your plugin knows that another plugin is already loaded (how?), the call
> > will not be guaranteed to succeed.
>
> Yes that sounds logical to me -> so no DCOP for that.
>
> > Hence, the right way to do it is to load the
> > plugin yourself as mentioned above and call the required function from
> > the base class interface.
> >
> > Hope this helps.
>
> Well that helpes a lot. So thank you very much for your help and i'll try
> get that approach work.
>
> thanks,
> chris

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]