Basic Live Connect support for java

Koos Vriezen koos.vriezen at xs4all.nl
Fri Apr 26 18:22:44 BST 2002



On Fri, 26 Apr 2002, David Faure wrote:

> On Friday 26 April 2002 15:53, Koos Vriezen wrote:
> > On Fri, 26 Apr 2002, Koos Vriezen wrote:
> > > I still think setting up a khtml_plugin interface should be done first.
> > > So maybe
> > >
> > > Create a khtml/plugin dir which contains contains a khtml_plugin.so that
> > > is loaded by khtml when needed. It also declares a DCOP interface in
> > > the html widget (konqueror-xxx html-widgetx pluginx), that can do JS
> > > calls (evalJS will do). A khtml_plugin has also a QWidget derive.
> > > A libkhtmlplugin.so that contains a DCOP interface for
> > > put/get/call/init/start/getWinId calls. These are called from
> > > khtml_plugin.so.
> >
> > Thinking of this a bit further, can DCOP be used for dynamic object
> > traversal? E.g.
> >    dcop konqueror-xxx html-widgetx pluginx
> > shows all members of this plugin (applet).
> >    dcop konqueror-xxx html-widgetx pluginx myobject
> > shows all members of this applet's member object.
>
> Not just that way AFAIK. It's always "dcop app object function [args]"
> so you have to call a function on html-widgetx to get hold of a DCOPRef
> to pluginx, then call "dcop app pluginx myobject"
> to get hold of the DCOPref to the object etc.

Well, that function could be the trigger for registering a new DCOP sub
object from the plugin interface. In java you never know how deep you must
go. So 'dcop app pluginx regobject', triggers a registering of this applet
properties/functions.

Koos





More information about the kfm-devel mailing list