[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-20 18:12:13
[Download RAW message or body]

The discussion is interesting, but about your last statement :
I don't think Torben subscribed himself to this list...

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

-- 
 ____________________________________________________________________
|                                                                    |
|  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]