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

List:       kfm-devel
Subject:    Fwd: Re: Crashing frames
From:       Lars Knoll <knoll () mpi-hd ! mpg ! de>
Date:       1999-01-20 18:41:04
[Download RAW message or body]

Hi everybody,

Waldo just asked me if I could forward this to the list.

Cheers,
Lars

----------  Forwarded Message  ----------
Subject: Re: Crashing frames
Date: Wed, 20 Jan 1999 16:37:56 +0200
From: Lars Knoll <knoll@mpi-hd.mpg.de>


On Tue, 19 Jan 1999, you wrote:
>> >I update KFM regurarly... does your KFM connects the documentRequest signal
>> >somewhere?
>
>> No. There's no need for it. KfmView overloads the function openURL().

>Ah.. I guess it wasn't a very good idea to add an extra argument to
>KHTMLView::openURL() then. 
Perhaps not ;-]

>
>Hm. This htmlview stuff is a mess.
I now. I already thought about what one can do to make it better. There also
was somebody sometime ago, who wanted to show framed pages with khtmlview, and
was wondering it didn't work. One problem is, that khtmlview doesn't offer
(except for the scrollbars) much more functionality, than khtmlwidget does.
What I was thinking about is moving all HTML viewing related stuff from kfm into
khtml. I'm thinking about a class, which can do almost all HTML related stuff
by itself. It should just have some slots for actions like back/forward,
openURL, reload; signals for things like urlSelected, scrolledTo,
URLRequested and some query methods. This would of course mean moving a
bigger part of kfm into the lib, but it will also alow every application, to
use a widget, which understands all of HTML4 with a few lines of code. So kfm
(or every other application) would just need to do something like:

	w = new KHTML();
	connect to some signals/slots (should be less than 10)
	w->openURL( url );
>
>What I want to do is save the contents of the forms in savedPage.
>
>What shouldn't happen is that when KFM calls htmlview::restore() control
>is bounced back and forth between khtml/kfm like it is now.
>
>I think it should become something like:
>
>KFM:
>====
>call htmlview->restore()
>
>HhtmlView::restore:
>===================
>look at savedPage, rebuild framestructure and call
>for the child-views restore(), extract usefull info like scrollposition and
>set scrollToX/Y, emit newURL to update the location bar.
>
>call KHTMLWidget->restore to apply the form-contents saved in savedPage to
>the next page loaded.
>
>emit 'requestDocument' to get the actual HTML from KFM.

Sounds much better than the present approach, but would mean moving lots of
stuff from kfmview to khtmlview. I would perhaps prefer my solution above: Make
a new KHTML widget, which can do all of this (you can inherit from KHTMLView)
and has just a few (as few as possible) signals and slots to connect to. We
would then have three classes for displaying HTML, and each application
programmer could choose the one which fits him best (which does all he want's
without adding too much overhead). At the same time, we could also clean up
the API for HTMLWidget and HTMLView (making them completely source incompatible,
but I don't think thats a big problem, since we still have khtmlw for old apps
and khtml is source incompatible to khtmlw already)

We could ask Torben if his new html viewing widget for kfmIII does perhaps meet
these requirements. If yes, we could easily move it into the libs.

Cheers,
Lars

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