KHTML Plugins

Mon Jul 4 21:23:30 BST 2005

Am Montag 04 Juli 2005 21:15 schrieb Koos Vriezen:
> On Mon, Jul 04, 2005 at 05:36:54PM +0200, Florian Roth wrote:
> > 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.
>
> setData only does a setAttribute in khtml and the object element
> implementation marks needWidgetUpdate. I think it would be possible to
> call closeURL/openURL on an embedded part if we really want that.
> Any idea what ns/ie do in this case?
> Also, like said, other changed attributes or child PARAM, only propagate
> on a newly created part. This is how it works in khtml, would be
> interesting to see how ns/ie handles this. (with the hopefully upcoming
> framework to embed kparts in ns, I could see it myself of course).
> Btw, reloading a part is hardly any faster than only calling openURL on
> an existing one. So why do you want it at the first place?

It's nothing that I absolutly want or something like that. It's just a thing a 
found out and thought the behavior could be changed. If only openURL() would 
be called and you could keep track of the opened files within the plugin 
itself what could be usefull in some cases. OK, I have no idea what cases 
this might be, but it's an idea :)
On the other side this probably might cause security problems if it the plugin 
is not reloaded. One could force a mimetype to keep the plugin loaded and 
store data within the plugin which could be used at another place.

Florian