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

List:       kfm-devel
Subject:    Re: khtmlw-0.7: Resize & Scrollbars
From:       Martin Jones <mjones () powerup ! com ! au>
Date:       1997-06-04 8:40:52
[Download RAW message or body]

weis@stud.uni-frankfurt.de wrote:
> 
> 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

I have given some thought to this problem.  My solution was
to separate the size calculation from the parsing so that
the objects size/placement can be recalculated any time
separately from parsing, i.e. call parse() once and let the
widget handle resize events so that in the top level calcSize
you do

  if width != prevWidth
     start calculating from the start
  else
     continue calculating from last pos

This should make size recalculation quite fast and would
minimise the visual effects of adding a scroll bar and resizing
the view.  It would also not delete the htmltokeniser and object
hierarchy, so the widget will not generate loadImage requests
when resized.

I've started doing this already - should know by the weekend
whether it will work Ok.

-- 
bye,
Martin Jones
mjones@kde.org

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