[PATCH] When is KHTMLView done with rendering?
David Faure
faure at kde.org
Thu Jun 17 14:18:02 BST 2004
On Thursday 17 June 2004 15:08, Jeroen Wijnhout wrote:
> Hi,
>
> Hereby I send you a patch for (no. 11 of most hated bugs, but it's my most
> hated bug)
> Bug 57360: URLs with anchor - sometimes the position is not moved to the
> anchor
>
> Description:
> In KHTMLPart::checkCompleted a call to gotoAnchor is performed, however AFAIK
> this is useless since at the moment of this call there is no guarantee that
> the layouting is done. Result: KHTML jumps to an arbitrary position since
> HTMLElementImpl::getUpperLeftCorner(x, y) returns random data (usually it
> results in jumping to (0,0) though).
>
> Solution: Create a new (private) slot in KHTMLPart, gotoAnchor. This slots
> jumps to the anchor if a HTML reference is present in the current URL. This
> slot is connected to the KHTMLView signal finishedLayout(), which is emitted
> at the very end of KHTMLView::layout(). When the slot gotoAnchor is invoked,
> all HTML elements have well defined positions.
>
> About the "whether or not to jump to the anchor after user interaction"
> discussion: KHTML will jump to the anchor even after user interaction. In the
> end this is the best behavior, since this is what the user might expect
> (after all the HTML reference is clearly visible in the location bar). Also,
> unsuspecting users will probably be confused when KHTML does not jump to the
> anchor when they scroll the view a bit.
>
> Ok to commit? Constructive criticism is welcomed :-)
Small nitpick: why not do the test if ( !m_url.encodedHtmlRef().isEmpty() )
before actually connecting to the signal?
Then gotoAnchor() will only be called when we actually need to go to an anchor,
as one might expect.
Even more nitpicking: emit finishedLayout() is more common than emit(finishedLayout()),
since emit isn't a function (merely a noop keyword).
Patch looks great otherwise.
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kfm-devel
mailing list