Dear friends
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)
*WebView class*
- 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)
*AbstractItemView class*
- object: m_scrollBar = new Plasma::ScrollBar(this);
- moving:
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)
*AppletsListWidget class*
- m_appletsListWidget = new QGraphicsWidget();
- moving: m_appletsListWidget->setPos(newPos);
4) News reader (kdeplasma-addons/applets/news)
*News class*
- object: m_news = new Plasma::WebView(this);
- moving: not explicit, check '1)'
5) rssnow (kdeplasma-addons/applets/rssnow)
*Scroller class*
- 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
ATM.
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.
Best regards
Adenilson Cavalcanti
a.k.a. Savago
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
