On Sunday 04 October 2009, Kenneth Christiansen wrote: > > this whas added to achieve scrolling by flicking (even in an animate way, > > by dragging fastly the webview and "launching" it) > > right now is done by a private class (right now with timers, will be > > ported to kinetic) that sets the scrollvalue properties to achieve that. > > seems a sane approach? > > So you need separate methods for each orientation? That might not be > very efficient as it will result in two different scrolls. I'm also > asking because I believe we have a scroll(int dx, int dy) method > somewhere (probably QWebFrame) > > > also this behaiur would make sense at lower levels in qt or perhaps is > > better that gets implemented by users of qgraphicswebwiew? > > It is a graphicsitem after all, so it will actually have a scroll > method already that takes a dx, dy and an area (defaults to the > boundingRect). Could you use this instead?
yeah, indeed, luckily the api can still be changed since it's been added in the 4.4 cycle. we are trying to share the logic of the animated scrolling between that and ScrollWidget, that is just a widget inside a clipped parent (and behaves like qscrollwidget) so we are still in a trial and error phase :) it has been done this way to be able to do it by settings qproperties, perhaps could be done with a global scrollposition property, like QWebFrame::scrollPosition > > as for make plasma::webview use qgraphicswebwiew: > > -keep both, separate implementations (uugly :) > > -webview subclassesqgraphicswebwiew (aaah, bic) > > -webview is an empty qgraphicswidget that contains nothing but a > > > > qgraphicswebwiew: i think despite ugly it's the only feasible option? > > I guess so, unfortunately. -- Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel