> 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
