Thank you, that's what I've wanted. :-) On Tue, Apr 3, 2012 at 10:30 PM, <[email protected]> wrote:
> Hi,**** > > ** ** > > That’s Flickable.AutoFlickDirection messing with you. If you don’t set > the flickableDirection explicitly, Flickable tries to work out which > directions you want to be able to flick. Generally, it’s what you’d want, > but if it’s not then set flickableDirection explicitly and it will work as > you want.**** > > ** ** > > Br,**** > > Martin.**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ext > Rafael Brandao > *Sent:* Wednesday, April 04, 2012 6:20 AM > *To:* [email protected] > *Subject:* [Development] Flickable and boundsBehavior**** > > ** ** > > Hello there,**** > > ** ** > > Recently I've came to this strange behavior when the boundsBehavior is set > to DragAndOvershootBounds: if the size of an axis of the inner content is > strictly equals to the size of the flickable area axis, then it won't drag > outside the boundary and overshoot as the behavior suggests. This is not > clear in the docs as far as I know, and it sounds odd the "strictly equal" > case. If instead it was "lower or equal", then an argument to it would be > "you should not drag the content inside if the content in that axis is > completely visible already". Right now this is not valid. Does this sounds > like a bug?**** > > ** ** > > Also, maybe it is desired that this overshoot always happens, even if the > content is equal (or lower) to the flickable area size, so adding a new > behavior enum might be an option. Do you think this is a good idea?**** > > ** ** > > Regards, > **** > > ** ** > > -- > Rafael Brandao @ INdT**** > -- Rafael Brandao @ INdT
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
