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

List:       kfm-devel
Subject:    Re: Basic Live Connect support for java
From:       Koos Vriezen <koos.vriezen () xs4all ! nl>
Date:       2002-04-26 17:22:44
[Download RAW message or body]



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

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