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

List:       kfm-devel
Subject:    Re: Fwd: Re: Crashing frames
From:       David Faure <David.Faure () insa-lyon ! fr>
Date:       1999-01-21 16:15:27
[Download RAW message or body]

On Thu, Jan 21, 1999 at 08:59:35PM +0200, Lars Knoll wrote:
> 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..
I asked him to, because I was getting all the bug reports that people sent
him, and there were some I couldn't do anything except forward them to you
or Waldo... so I asked him to forward bug reports to kfm-devel@kde.org


> 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

-- 
 ____________________________________________________________________
|                                                                    |
|  David FAURE                                                       |
|  E-mail : David.Faure@insa-lyon.fr, faure@kde.org                  |
|  http://www.insa-lyon.fr/People/AEDI/dfaure/index.html             |
|____________________________________________________________________|

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