[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: Review Request: Rewrite kinetic scrolling on ScrollWidget
From: "Marco Martin" <notmart () gmail ! com>
Date: 2010-03-18 9:33:47
Message-ID: 20100318093347.15395.11726 () localhost
[Download RAW message or body]
> On 2010-03-17 12:31:22, Marco Martin wrote:
> > just by a quick test, the physics seems to work indeed better, it just still has \
> > some quirks:
> > - scrollbars aren't syncronized when dragging (yeah i know it needs a mode \
> > without scrollbars but i would keep them on the desktop)
> > - event stealing doesn't seem to work (even with setFiltersChildEvents): if \
> > registerasdraghandle is used clicks don't pass anymore to childrens, if it's not \
> > used is the parent to not receive events)
> > - the old behaviour of scrolwidget was to center the inner widget into the parent \
> > if it's smaller, now seems to always go to 0,0
> >
> > about scrollStateChanged uhm.. permits external things to know the scrlling \
> > state, to for instance show/hide things depending if the user is dragging... not \
> > terribly useful indeed..
>
> Zack Rusin wrote:
> The scrollbars issue is fixed.
> The event stealing works for sure, since that was the first thing I got working. I \
> don't really understand what draghandle's are supposed to be doing or why there are \
> event filters for them so I'm not sure what exactly is expected to happen there. Is \
> there an example that uses that code so that I can figure out what's the expected \
> behavior for those? I don't see the centering behavior with the old code \
> (especially since the setWidget has been calling an unconditional setPos(0,0)) , is \
> there an example that shows the behavior you mention?
> Marco Martin wrote:
> in plasma some places that are using the scrollwidget and have lots of child items \
> (that are supposed to manage clicks too) is the microblog plasmoid or the netbook \
> search and launch interface (just plasmoidviewer sal) where all the icons can be \
> clicked or it should be possible to drag the view around also by draging the icons, \
> here the need of stealing events when needed. before it was working wit the \
> registerasdraghandle function: it installed an eventfilter and bounced the event \
> back and forth between the child and the scroll widget. this would hopefully become \
> deprecated, since now it's using setFiltersChildEvents. Icons in search and launch \
> had this eventfilters in place, by killing the implementation of \
> registerasdraghandle we are sure there shouldn't eventfilters around that do \
> strange things, but it's still impossible to scroll by dragging over the icons.
> about the centering thing, always with search and launch, usually when it starts \
> the contents of the scrollwidget are just some icons, so content it's smaller than \
> the scrollwidget and is centered. If the inner widget was placed centered by hand, \
> it stayed there, it simply couldn't scroll horizontally, so no problems. now as \
> soon as is touched by the mouse it animates and it goes to 0,0. I know is not a \
> prety thing to move the inner widget by code, but probably the scrollwidget will \
> need a Qt::Alignment flag in the api to decide how to align the inner widget if \
> it's smaller than the scroll widget...
> Zack Rusin wrote:
> Yes, the "lots of child items that accept clicks on top of a scrollview" is exactly \
> the case that works here. Here "sal" seems to be working ok. BTW, setting the \
> position of a widget managed by another widget from somewhere else is pretty evil \
> =) I did add setAlignment code to the ScrollWidget, i think it makes a lot more \
> sense than allowing others to position the items that it's supposed to be managing \
> :)
> With the patch underneath sal has items centered correctly and I can flick the view \
> by click&dragging items without them executing. BTW, sal could probably actually \
> use the scrollStateChanged signal to not call ensureItemVisible when another \
> animation is in progress (when that happens ScrollView has to immediately stop the \
> currently running animation and invoke another one, since otherwise we could have \
> two different animations pulling in opposite directions, which causes a small jump \
> on hover events during the flick animation)
> Index: containments/sal/itemcontainer.cpp
> ===================================================================
> --- containments/sal/itemcontainer.cpp (revision 1104506)
> +++ containments/sal/itemcontainer.cpp (working copy)
> @@ -150,7 +150,6 @@
> m_usedItems.remove(key, item);
> } else {
> item = new ResultWidget(this);
> - m_itemView->registerAsDragHandle(item);
> item->hide();
> item->setPos(boundingRect().center().x(), size().height());
> }
> Index: containments/sal/itemview.cpp
> ===================================================================
> --- containments/sal/itemview.cpp (revision 1104506)
> +++ containments/sal/itemview.cpp (working copy)
> @@ -32,6 +32,7 @@
> setFocusPolicy(Qt::StrongFocus);
> setSizePolicy(QSizePolicy::Expanding, QSizePolicy::Expanding);
> m_itemContainer = new ItemContainer(this);
> + setAlignment(Qt::AlignCenter);
> setWidget(m_itemContainer);
> m_noActivateTimer = new QTimer(this);
> m_noActivateTimer->setSingleShot(true);
yes, evil indeeed, a setalignment function is -way- better
- Marco
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3312/#review4532
-----------------------------------------------------------
On 2010-03-17 22:20:25, Zack Rusin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3312/
> -----------------------------------------------------------
>
> (Updated 2010-03-17 22:20:25)
>
>
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic