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

List:       kfm-devel
Subject:    Re: Resize & Scrollbars: !?!!!?
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-06-04 15:31:52
[Download RAW message or body]

Hi,

this is going to be a zombie list :-)

I am brainded, Sven is braindead ... :-)))

I am shure that Martins approach will have success.
Sven and I tried and I think that is proof which
shows that the wiget needs some rewritings.
Martins idea of sperating the parsing from the
width calculation sounds good.

On Wed, 4 Jun 1997, Sven Radej wrote:

> 
> 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 can but the panner rush back to their default width/height.
( at least on my system it wrks ).
Ooops. Belongs to the sentence below!

> -You cannot resize frames with panner... I don't think I did this.

> -Sometimes in frames selected frame gets all black. (in HTML pages) 

Seems to be my fault but I dont know where this is going to happen
exactly.

I hope that your brain will regenerate :-)

Bye
Torben

> 
> 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]