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

List:       kfm-devel
Subject:    Re: khtmlw-0.7: Resize & Scrollbars
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-06-01 1:21:35
[Download RAW message or body]

Hi,

On Sat, 31 May 1997, Sven Radej wrote:

> Hi,
> 
> I belive that this problem is still actual.
> 
> The problem is this. khtmlview class has an interesting way to hide/unhide
> scrollbars. If khtmlwidget (subclass of khtmlview) is smaller then whole
> document, scrollbars are painted ontop of khtmlwidget and khtmlwidget is forced
> to resize to smaller size (by ->setGeometry) the problem is that khtmlwidget
> parses again and sends documentChange signal which causes khtmlview to
> recalculate if scrolbars are needed (becouse documentChange may occure without
> resizeing) which sets/removes scrollbars on top khtmlwidget and resizes it ...
> it doesnt go ad infinitum, but takes a while, and scrollbars are usualy badly
> written or is khtmlwidget wrongly resized.
> 
> The above problem is only for horizontal scrollbar, since vertical is
> implemented so that khtmlwidget has right border of 20 pixels and ver.
> scrollbar is placed so it never hides text (or whatever) under it.

The code is indeed very tricky. I had major problems with it. ... and 
still have :-(

> What I think:
> 
> Let's make rightborder 10 pixels as it was before. 
> Khtmlwidget (further html) has geometry (0, 0, w, h)
> We set ClipppingRegion to (0, 0, w, h) (in screen coordinates)
> 
> 1)  html->parse() => signal documentChanged
> a) If DocumentSize > ClippingRegion we make clipping region smaller for the
> width/height of needed scrollbars and paste them on top of html. Scrollbars
> hide somee text, but it doesn't matter since we can see it if we move
> scrollbars. No need for repaint/parse.
> If scrollbars allready exist we just adjust their range.
> 
> b) If DocumentSize < Clipping region we enlarge clipping region for
> width/height of no longer needed scrollbars. Here we must reparse if we want
> areas where scrollbars were to be used.
> If we allready don't have scrollbars we do nothing
> 
> 2) resizeEvent
> ClippingRegion = html->geometry()
> We remove scrollbars if we have them
> 
> a) If DocumentSize > ClippingRegion we make clipping region smaller for the
> sizes of needed scrollbars, and paste them on top of html. We reparse. Reparsing
> causes 1a) but we allready have scrollbars so we just adjust their range there.
> 
> b) If DocumentSize < ClippingRegion we remove scrollbars if we had them, and
> reparse. This causes 1b) where we do nothing.
> 
> Paint event in html should paint only inside Clipping region... if event is
> resizeEvent. I'm not sure about this. 
> 
> I'll try to make it so tonight. Am I totaly wrong? Comments? Pros? Cons? 
> 
>                         Bye
> --                               
>                              Sven <sven.radej@iname.com>
> 
> 
The problem I see is this one: We have progressive parsing. So once
we already parsed some text we encounter that we need scrollbars.
Starting the parser again now could cuase a flickering on the
screen. But that is not really worse. 

But without reparsing you get this problem:
You suddebnly have to display a vertical scrollbar
that makes the width of the KHTMLWidget smaller. This causes
some text to disappear. The user  has to scroll
left/right all the time to read the document. But a additional
parsing could break the text in a more intelligent way.

To solve both problems I set RIGHT_BORDER to 20.
This leaves always space for for the vertical scrollbar without
the need of resizing.

I dont like my approach. So if anyone can do it better then
dont wait!

Whild doing this please consider an option to suppress
displaying scrollbars. This is needed due to the
<frame scrolling=no> tag. And we must be able to display
scrollbars all the time because of <frame scrolling=yes>.
The default is of course <frame scroling=auto>.

Good night :-)

Bye
Torben

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