From kfm-devel Wed Jun 04 15:31:52 1997 From: weis () stud ! uni-frankfurt ! de Date: Wed, 04 Jun 1997 15:31:52 +0000 To: kfm-devel Subject: Re: Resize & Scrollbars: !?!!!? X-MARC-Message: https://marc.info/?l=kfm-devel&m=88721887600195 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 , frustrated to death > >