KHTML Plugins

Mon Jul 4 16:36:54 BST 2005

Am Montag 04 Juli 2005 17:29 schrieb Koos Vriezen:
> On Sun, Jul 03, 2005 at 09:27:41PM +0200, Leo Savernik wrote:
> > Am Freitag, 1. Juli 2005 20:32 schrieb Florian Roth:
> > > If you now change the data attribute of the object tag using DOM
> > > (unsing JavaScript or from your app embedding a KHTMLPart) the plugin
> > > is reloaded/a new plugin is loaded depending on the new mimetype. This
> > > is absolutly OK, because the mimetype might have changed.
> >
> > This is good news that dynamically changing the source finally works.
> >
> > > But if the mimetype
> > > did not change? Or the mimetype was fixed using the type attribute?
> > > Shouldn't it be enough to notify the plugin (if it's a kpart, of
> > > course) of the change and call openURL() instead of reloading the
> > > complete plugin?
> >
> > Yes, it should. Any volunteers to find out why it's reloading?
>
> It really would help if the reporter adds a testcase, now its more
> a bit of quessing what he means :(.
> Anyhow, there is more to it than only the data/mimetype. All attributes
> and PARAM child elements should be taken into account, I think. And
> these are passed on (re)loading, not in the openURL call.

OK, here some code to see what I exactly mean:

The html code looks like this (very basic example, but should work)
<html>
<body>
	<object id="someobject" data="file1.mpg" />
</body>
</html>

The c++ code

DOM::HTMLDocument doc = html->htmlDocument(); //where html is a KHTMLPart
DOM::HTMLObjectElement element = 
static_cast<DOM::HTMLObjectElement>(doc.getElementById("someobject"));

element.setData("file2.mpg");

This causes the complete plugin to be reloaded. But I think it should be 
enough to update the data source for the plugin.

Florian