----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3312/#review4534 -----------------------------------------------------------
Instead of change the ScrollWidget code you should have a look in plasma/private/kineticscroll.* because there is the old kinetic scroll implementation and it is used by others classes(like plasma/webview) and would be difficult maintain two different kinetic scrolling implementations. - igorto On 2010-03-17 04:59:11, Zack Rusin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviewboard.kde.org/r/3312/ > ----------------------------------------------------------- > > (Updated 2010-03-17 04:59:11) > > > Review request for Plasma. > > > Summary > ------- > > As previously discussed with this approach we can actually properly intercept > events from child items. Furthermore now we properly "steal" events which > cause a flick (it's important for child items to properly act on > mouseReleaseEvents and not on mousePressEvents as some like to do, since it's > the release events that cause a flick) so items don't get clicks when > flicked. The physics and especially the overshoot behavior is a lot better in > this code as well. > I tried to preserve the old behavior and emit the scrollStateChanged when > needed, but I'm not quite sure what that signal was meant to be good for. > > > Diffs > ----- > > trunk/KDE/kdelibs/plasma/widgets/scrollwidget.h 1102878 > trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1102878 > > Diff: http://reviewboard.kde.org/r/3312/diff > > > Testing > ------- > > Done in a custom app. Would be nice if someone double checked it with other > things that use ScrollWidget though (e.g. the notebook shell :) ). > > > Thanks, > > Zack > > _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
