Making kinetic scrolling generic
savagobr at yahoo.com
Fri Sep 25 14:30:11 CEST 2009
Last Wednesday, there was a discussion in plasma IRC channel
concerning ideas to make the Kineticscrolling class more generic to
handle scrolling in other plasma components.
Trying to understand how *actual* movement is done in some of
KDE's plasmoids, I had read the code of following plasmoids:
1) Webview (kdelibs/plasma/widgets)
- object: d->page is a QWebPage
- moving: d->page->event(&we);
Maybe void QWebPage::scrollRequested ( int dx, int dy, const QRect & rectToScroll ) [signal]
could be used or just keep with current approach of generating events.
2) Folderview (kdebase/apps/plasma/applets/folderview)
- object: m_scrollBar = new Plasma::ScrollBar(this);
m_scrollBar->setValue(qMax(m_scrollBar->minimum(), m_scrollBar->value() + step));
m_scrollBar->setValue(qMin(m_scrollBar->maximum(), m_scrollBar->value() + step));
3) Widget explorer (kdebase/workspace/libs/plasmagenericshell/widgetsExplorer)
- m_appletsListWidget = new QGraphicsWidget();
- moving: m_appletsListWidget->setPos(newPos);
4) News reader (kdeplasma-addons/applets/news)
- object: m_news = new Plasma::WebView(this);
- moving: not explicit, check '1)'
5) rssnow (kdeplasma-addons/applets/rssnow)
- object: SingleFeedItem * item = new SingleFeedItem(this);
- moving: item->setPos(0, 0);
Following the idea of Marco Martin, movement should be done by the
animated widget itself and not inside of KineticScrolling as it is
Scrolling must be possible for widgets that are *not* inside of another widget (as the current implementation assumes).
And finally, instead of using X/Y coordinates, operate over a property
of the widget in the range of 0 -- 1, where:
- zero: equals to top or left scrollable position
- one: equals to lower or right scrollable position
Trying to address this requirements the following design is proposed:
- KineticScrolling emits a signal in setKineticScrollValue
- the widget has a connected slot that will call itself the function
to change its position (i.e. setPos(), event(), setValue(), etc).
The signals will be created in current implementation by the timer
event used to handle the animation.
When KDE migrates to Qt 4.6, I guess using a default property in the
animated widget can make easier to bound it with QPropertyAnimation,
as long that "... for properties in classes you have implemented yourself--just check with QVariantAnimation that your QVariant type is supported."
Comments and suggestions are welcome.
More information about the Plasma-devel