On Wed, 20 Jan 1999, David Faure wrote:
>The discussion is interesting, but about your last statement :
>I don't think Torben subscribed himself to this list...
Don't know. But he already posted to this list..

Torben, are you listening???

Cheers,
Lars
>
>On Wed, Jan 20, 1999 at 08:41:04PM +0200, Lars Knoll wrote:
[...]
>> >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