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

List:       kde-core-devel
Subject:    Re: changes to khtml before krash (?)
From:       Reginald Stadlbauer <reggie () troll ! no>
Date:       1999-11-17 21:24:59
[Download RAW message or body]

On Wed, 17 Nov 1999, Lars Knoll wrote:
>Hi,
>
>Simon and I had a longer discussion about frames in khtml today. There are
>mainly two problems we have with the current implementation, and whcih
>would need a (small) change in the API of KHTMLWidget, and moving the
>konq_htmlview from konqueror over to khtml to solve them.
>
>There are mainly two problems. The first one is conceptual, and unsolvable
>with the current implementation.
>
>Suppose we have an htmlwidget with frames. Up to now, we use a method
>createFrame() in KHTMLWidget, to create a new KHTMLWidget as a child
>frame. But this limits us to displaying html in the frames. If one frame
>for example specifies an image to display inside, we will create an
>HTMLWidget, and this widget, will try to load the image data and display
>it as html. You can see this effect, if you go (for example) to mosfet's
>site, and try to look at one of the screenshots.
>
>To change that, we need to have a frame widget, which inherits
>from BrowserView, so konqueror can check the url of the frame to be
>loaded, and (if needed) change the viewmode to display the image. In case
>of HTML, we need a widget, which can display html and inherits from
>BrowserView. This is why we should move konq_htmlview to khtml. Then we
>can solve the whole problem, and wouldn't even loose the ability to
>display frames even if people are just using KHTMLWidget. The following
>API changes have to be done in khtmlwidget: the method createFrame() has
>to be replaced by a signal()/slot() mechanism, to create the frames
>asynchrounously. I think, we can provide a mechanism, that this will work,
>even if people are just using KHTMLWidget in the way we have it now.
>
>The second reason to do this switch, is, that it'll make history handling
>for html pages (you probably noticed that it's broken in konqueror at the
>moment) a lot easier, and give a cleaner implementation. I tried to
>implement history handling for framed html in the current design, it's
>a real mess, and we would need a lot of hacks to get it working. There is
>no clean way to implement it as it is now.
>
>AFAIK, the only app using this createFrame() method (overloading it) is at
>the moment konqueror, so we wouldn't break any other app, and we'll fix
>konqueror.
>
>So what do you think?

According to what I can read here we win a lot and not much will be broken
(only konqy needs to be updated). So, IŽd say, go for it!

-- 
Reggie

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