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

List:       kfm-devel
Subject:    Re: .kde.html, khtml's embed tag and frames in konqueror
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-08-20 13:05:00
[Download RAW message or body]

On Fri, 20 Aug 1999, Lars Knoll wrote:

> On Thu, 19 Aug 1999, Simon Hausmann wrote:
> 
> > On Thu, 19 Aug 1999, Lars Knoll wrote:
> > 
> > > Hi,
> > > 
> > > Since I'm currently rewriting khtml's internals, I'm also thinking about
> > > that stuff. We will need to be able to embed widgets in khtml, not only
> > > for the .kde.html feature, but also for Java, the IFRAME element and
> > > perhaps some other things (haven't thought too much about these things
> > > neither up to now...)
> > > 
> > > Because I want to have an implementation in khtml, which ich compatible to
> > > DOM Level1, I'm not so sure, if the implementation of frames in khtml will
> > > stay as it is at the moment. 
> > > 
> > > On the other hand, I would like to have some general solution to embed
> > > widgets (of any kind) in khtml. For this HTML-4 defines the object
> > > element. We could extend it a little bit, to serve also our own needs. One
> > > idea I had, goes as follows:
> > > 
> > > in the html code, you have something like:
> > > <object height=yyy width=xxx codetype="KDEWidget:some_id">
> > > 
> > > This causes khtml to create an object for this element, and request the
> > > widget from the application (can be done with signals/slots). The app
> > > returns the widget to khtml, and khtml embeds it.
> > > 
> > > With some support from konqueror, this could be used for implementing the
> > > .kde.html feature, or to embed any other thing you want int khtml.
> > > 
> > > I don't know, if this is as flexible as the solution you thought of, but
> > > it might be less bloat, and I don't think it's very difficult to
> > > implement.
> > 
> > I think your solution is part of my proposal :-)
> > 
> > Everything is configured through KBrowser, which provides the virtual
> > createFrame() method. Originally this used to be overloaded by KfmBrowser,
> > allocating a new KfmBrowser instance.
> > 
> > I thought of changing this in KonqHTMLView, again, and allocating a new
> > KonqHTMLView, with the addition that the view gets embedded from
> > OpenParts's focus-handling point of view (and from the part hierarchy in
> > general) . In addition we have to tell the MainView about this, so that it
> > can connect to the openurl/progress signals and such.
> 
> I'm not sure if this is really needed for html. HTML frames should only
> contain html pages, and because of that should do very well with a new
> KBrowser instance, using KonqHTMLView adds quite some bloat IMO. 
> 
> > I think if we solve the communcation issue between the MainView and the
> > frame view we're nearly done and can therefore embed the iconview and
> > others aswell.
> > 
> > But of course I might be wrong. And I probably misunderstood how the frame
> > handling changes with your DOM port.
> > 
> > How will/does dom-khtml handle html frames? How will/does it handle
> > <object>'s ?
> > 
> I thought a bit more about it, and got to the conclusion now, that it'll
> probably be best to stick with createFrame() in kbrowser. I want to change
> the internal handling, but that doesn't need to affect you too much. 
> 
> For objects, we could perhaps add a virtual createObject() function. 
> The implementation in kbrowser will then take care only of a few object
> types, others (like an embedded KIconView) can then be defined by
> overloading the function.
> 
> IMO we should use the object element for embedding other things than
> HTML frames. It's added to HTML-4 for this purpose, and is now mainly used
> for Java. But we can easily extend this one to embed whatever we want.
> Here it could be nice to use OpenParts. Hmmm... but then on the other hand
> all frames need to be KonqHTMLViews, or we need to pass the createObject 
> call through to the main HTMLView (which is a KonqHTMLView).

I can only agree with what you said :-)

...and I vote against passing createObject calls through.

The rest is quite clear I think. (I also had another thought about the
embedding from the OpenParts's point of view, and I see it's even easier
than I thought)

Greetings,
 Simon

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