[PATCH] When is KHTMLView done with rendering?

[David Faure]

On Thursday 17 June 2004 16:37, Jeroen Wijnhout wrote:
> It was there in checkCompleted originally, just copied it. Suppose we have an 
> URL:
> http://url.com/index.html#
> Does url.hasRef() return true? 
Yes. (that's the main reason for hasRef() to exist)

> If it does, the url.htmlRef().isEmpty() is sensible, otherwise not I guess.
You're right.

> > Another issue: is finishedLayout() called if aborting the loading of the
> > page? If it is, then ok (although the jumping might be strange when
> > aborting). If it's not, then we might keep a connect() to the view's
> 
> If KHTMLView::layout() is called then finishedLayout is emitted. There is one 
> exception, the case in which there is no khtml::RenderCanvas. In that case 
> it's ok not to emit the signal.

This doesn't really answer the question, since I don't know when KHTMLView::layout().
But never mind, you handled it anyway :)

> > finishedLayout() signal, and end up being connected more than once. In this
> > case it won't do much harm I suppose (just going to the same anchor
> > multiple times in a row), but generally I find that dynamic
> > connects/disconnects are a bit dangerous for this reason. One approach
> > would be to disconnect before connecting, to ensure we're only connected
> 
> I've added a disconnect() in KHTMLPart::openURL, just before the connect. 
> Better safe than sorry.
OK.

> > once. Another approach would be to always connect (in the constructor), and
> > put back the check for whether there's a ref in the current url :/
> 
> This would also be a good solution, however in this case I would propose to 
> rename gotoAnchor to something like: afterLayouting(). Since the slot really 
> provides a point where one can do stuff that really needs to be delayed until 
> layouting is done. 
Yep. Can still be done later.

> I've implemented the first option, because that took only five keystrokes :-)
OK.

> Btw, is it good coding practice to make this slot (gotoAnchor) private? 
Yes

> Since another class (KHTMLView) connects to it, shouldn't it be public?
No. It's not KHTMLView which connects to it, it's KHTMLPart which connects to
a signal from KHTMLView. KHTMLView doesn't have to know who listens
to its signals.

> I made the slot private because I didn't want to change the API.
Yes, that's good.

IMHO you can commit.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).