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

List:       kfm-devel
Subject:    Resize & Scrollbars: !?!!!?
From:       Sven Radej <a9509961 () unet ! univie ! ac ! at>
Date:       1997-06-04 12:28:33
[Download RAW message or body]


On 04-Jun-97 Martin Jones wrote:
[...]
>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
>

Dear friends,

I obviously overestimated my brainwidth when I said that it won't be too hard
to fix those scrollbars. Well I fixed it completely, but not entirely :-) 

This is what works:

- scrollbars show, hide, resize themselves ok;
- even in frames;
- nothing else;

This doesn't work or causes Sven->braindamage(Permanent) :
-When you have two scrollbars you have in lower right corner a small
 rectangle that NOONE should paint in. However someone does. This kills me.    
-paintEvent is called two-three times per resizeEvent. This is slow and blinks. 
-Scrolling is slooooooow and blink-blink-blinking if you have two scrollbars.
-after resize, the widget is sometimes so badly repainted... 

The folowing things do not work but I don't think that's my fault.
-You cannot resize frames with panner... I don't think I did this.
-Sometimes in frames selected frame gets all black. (in HTML pages) 

What I did:
Well, I introduced a "QRect visible" as a public object in "KHTMLWidget".
"KHTMLWidget::paintEvent ()" takes intersect of its "event->rectangle" with 
"visible" and paints into this intersect.

"QRect visible" is set in "KHTMLView::calcScrollBars ()". First it is set to
"view->geometry()" ("KHTMLWidget *view") an than shrinked if scrollbars are
needed. "calcScrollBars" is called from "slotDocumentChanged" and "resizeEvent"
"slot..Changed" only calls "calc...Bars"; "resizeEvent" does
"view->setGeometry(...)" and then "calc...Bars".

My idea was to restrict every painting job to paint in visible rectangle
"visible". But changing every "width()" to "visible.width()" (or same for
height) does terrible things, and wakes ghosts of bugs that were killed long
ago.
Someone with better knowledge of who exactly paints in htmlwidget, and which
width/height() should be changed to visible.width/height() should finish this.

If, of course this is a right way of doing things; I hoped to reduce repaints
that occure one after another, but without luck. 

I have no doubt that Martin Jones will make a better job then I did.

This sad patch made for khtmlw-0.7.3 is on lynch ("khtmlw-0.7.3.sr.diff")
--                               
                             Sven <sven.radej@iname.com>, frustrated to death

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