[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:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       1999-08-19 12:39:34
[Download RAW message or body]

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.

Cheers,
Lars

On Thu, 19 Aug 1999, Simon Hausmann wrote:
> I had look at the old kfm sources, khtml's <embed>-stuff and "old" kfmIII
> code (especially kfmbrowser).
> 
> In fact Torben's code was able to embed an iconview in any html frameset,
> as frame, which is more or less the basic .kde.html feature.
> 
> Unfortunately we *currently* can't do this anymore.
> 
> I might be wrong, but AFAIK in the old kfmIII code frames were normally
> KfmBrowser's, and in case of the <embed>-tag KfmIconView's.
> 
> In Konqueror frames are KBrowser's.
> 
> I'm a little bit puzzled at the moment, but I have a wild guess /
> "experimental proposal" (meaning I didn't think *that* carefully about it,
> yet ;)
> 
> (please note that this requires adaptions in the OpenParts Part-Child
> handling, but it should be possible :-)
> 
> (I'm now leaving out the .kde.html feature, but if we manage to get the
> stuff below working, then embedding a KonqIconView should be more than
> trivial I think)
> 
> In case of a frameset, we, the KonqHTMLView, handle frames in two ways:
> 
> - from the OpenParts's point of view we embed them as child-parts
>   in the KonqHTMLView.
> 
> - from the Qt/QWidget/khtml point of view, we have/create KonqHTMLViews as
>   children.
> 
> So every KonqHTMLView becomes the hosting parent part and child part at
> the same time. 
> 
> It is either a child part of Konqueror::MainView *or* it is a child part
> of another Konqueror::HTMLView.
> 
> It is a parent part of frames.
> 
> This looks like a *possible* and *very* flexible approach to me, but it
> has two disadvantages:
> 
> - it creates big overhead, because we deal a lot with CORBA Objects, which
>   leads to bloat in somehow. And KonqHTMLView will get pretty large, too.
> 
> - it requires tweaky handling in OpenParts, regarding activation of parts.
> 
> Advantage:
> 
> - we can have every kind of frame, not only htmlviews and iconviews.
> 
> So what do you think?
> 
> Greetings,
>  Simon

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