hi
love the launcher, by far the best one I’ve ever had in terms of customisability and functionality.
how does nested scrolling work in lightning?
I thought the most intuitive approach would be to treat overscroll as scroll on a parent, if the parent can be scrolled.
for example, let’s say I have 2 pages vertically, and on the page that’s on the bottom I have a panel filling the whole page, that freely scrolls vertically, for example containing an app list. when I scroll to the top of the panel and then try to scroll up further, I’d expect to scroll back to page 1, but that does not happen, instead it just overscrolls the panel. swipe up/down events also don’t trigger on overscroll as I’d expect them to.
is that intended behaviour? is there an option that I missed to turn it on/off?
sorry if this is the most asked question ever
]]>
D5 Creation
< ![CDATA[
De Ja Vu. I think i saw this question asked like last week or something. And…. I think it was you who posted it.
]]>
< ![CDATA[
Curtis Sylvester Jr. I posted something similar in the other community, because I wasn’t approved into this one. figured that maybe I’ll get some more information on this here.
]]>
< ![CDATA[
Tored I knew i remembered this “post” from somewhere. I’ve been staying on top of this wondering what i can “gain” from the solutions. Sadly i didn’t see any comments on it.
]]>
< ![CDATA[
This has been a longstanding request. Indeed, a nested panel which is being scrolled will not allow its container to react to scroll events anymore.
Technically, once an object catches the user input, it will not relinquish it until the finger is up. Event handling is terribly complex in Lightning, because of transformations, stop points, snapping and custom features like that. I never really wanted to change this behavior because there is probably no good solutions considering the way I implemented events handling.
Today however I tried a hack to make this work (more or less). I’m not sure it is fully satisfying though. Specifically, if you start to scroll the nested panel and reach a limit, the parent container will start to scroll, but scrolling back (without finger up) will not scroll back the nested panel, only the parent will scroll (back and forth). I don’t know whether this is bad or not so maybe the best is to try in real situation. If you’re willing to test it I can setup a beta, but there’s no guarantee that I will ever be able to implement a perfect overscroll behavior.
]]>
< ![CDATA[
Pierre Hébert I want to say that I appreciate the effort a lot! I’m down to testing, if you’re willing to set up a beta branch for just one guy.
I have an idea I’d like to propose that might be easier to implement – make the scrolling work like this (using the same example as before): scrolling the nested panel always scrolls it’s contents, like it is now, with one exception: make the parent get the scroll only when the panel is at the edge of it’s scroll, either vertically or horizontally, and the user wants to scroll further in that direction.
this solution might not work with the scroll option to not limit each scroll to one axis, but I think it would be the most intuitive one in every other case. it wouldn’t require transferring the scroll event from the panel to the parent, since which one handles the scroll would be determined at scroll start:
by default the panel gets the event, except when the panel starts scrolled to the end and user wants to continue further in that direction. in that instance, the event is handled by the parent container.
I admit I’m biased, this is inspired by the way the app drawer worked in my previous launcher, lawnchair. the drawer opened after what would be the equivalent of a vertical scroll down, and had a vertically scrolling list inside it. the drawer could then only be closed by scrolling up when the list was already scrolled to the top before the scroll started. if the user started scrolling the list up and continued the gesture after the list was at the top, an overscroll effect happened on the list.
of course I don’t know how lightning works, and if what I’m proposing is even possible – especially with how complex it is and how many elements are at play, but figured I’d throw the idea out there just in case it may be useful.
]]>
< ![CDATA[
This is a bit like this that the modification is implemented. But the difficult part is not to make it work, it is to make it work nicely without breaking other features. I’m quite good at implementing regressions…
I’ll put a beta on the play store tomorrow.
]]>