On Wednesday 24 March 2010, you wrote:
> On Tuesday 23 March 2010 13:53:24 Marco Martin wrote:
> > in that way the whole webview would flick instead of the webview
> > contents?
> > 
> >  (webview could also be resized to the whole contents but this would be
> >  terribly inefficient right?)
> 
> Ah, I see, that's the core of the issue. Yea, the scrolling of contents
> behavior should probably be configurable with properties just for cases
> like this. I don't quite have the time right now to do it in full but the
> attached should be 90% there. Maybe you'll like it better than the other
> approaches. It basically checks whether the widget which the ScrollWidget
> is supposed to scroll has defined the following properties:
> - contentsSize
> - scrollPosition
> - scrollPositionX
> - scrollPositionY
> and if it does it uses those, instead of statically calling widget->size(),
> widget->pos(), widget->x and widget->y.

i like this approach :D

> It should compile/work, but iirc the position to scrollPosition function
> needs to be negated somewhere (especially visible since the webview
> scrolling will now be inverted and it will probably try to overshoot all
> the time =) ), I don't quite have the time right now to start compiling
> and testing to see where that position needs to be negated but I think
> this approach would be more convenient and cleaner. Especially since it
> means that the ScrollWidget would be able to just handle really anything
> anyone could possibly throw at it and it would just work (tm) in all
> cases.

well, that is an huge help already, i can try to finish it up and then i'll 
put it on reviewboard when done

> (also possibly viewportGeometry will have to be overwritable for
> completness as well).

yeah, could come handy


Cheers,
Marco Martin
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel