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

List:       kde-core-devel
Subject:    changes to khtml before krash (?)
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       1999-11-17 21:39:39
[Download RAW message or body]

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?
	

-- 
Lars Knoll                                 knoll@mpi-hd.mpg.de
  PGP pub key [6DADF3D5]: finger knoll@pluto.mpi-hd.mpg.de 

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