Continued Gesture Widget (reveal use case)

For things like the phone's lockscreen we want a continous gesture widget that when swiping reveals the content under neath it (and snaps back when not swiped wide enough). So like a GtkStack that switches by swiping maybe.

@tobias.bernard could you link to some mockups for that?

changed title from Continues Gesture Widget to Continued Gesture Widget

changed the description

assigned to @guido.gunther

Assigning this to myself since it's needed for the shell at some point. I won't start working on it immediately so if anybody wants to pick it up ping me so we don't duplicate work.

In its most simple form, what we need is a kind of "slideshow" widget with separate screens that are all arrayed in a row/column. If you swipe along the direction of the row, the entire row moves with the gesture. Depending on the position when the gesture ends, the row will snap to the closest screen.

Here's an example of what this would look like in the app drawer:

app-drawer

However, the "slideshow" use case isn't the only one. We'll also need something similar but where the individual screens overlap, like for the in-app back gesture:

video_2018-07-25_14-36-16

In addition to that, there will be cases when we want to map a swipe to other movements. For example, the swipe up gesture to go to multitasking will require scaling the app thumbnails with the gesture.

Do you think it would make sense to have something abstract enough to cover multiple of these cases, or separate widgets for all of them?

Your second use case matches my initial bug description. Let's use this bug report for that one (since these will likely be two totally separate widgets) and lets open a separate one for the slideshow use case.

Let's open a different one for the "Slideshow" usecase - gitlab has no "clone issue" though. sigh.

changed title from Continued Gesture Widget to Continued Gesture Widget (reveal use case)

mentioned in issue #25

The app drawer is so specific you probably want a custom widget just for that, a sort of automatically paginated flow box.

We would need a continuous gesture widget in Calls too to hide the DTMF tone pad. We probably could implement it as a fork of GtkRevealer which enables some gestures (maybe depending on the selected animation?) and bind them to its animation.

Then again we would need something for HdyLeaflet to allow moving back in a continuous way.

When the gesture is done (understand the screen is released) it seems to be common on Android for these animations to fully reveal the widget if more than half of it is visible, or to hide it less than half of it is visible.

mentioned in issue #27

@adrien.plazas Note that this is not about the slideshow use case (see the actual issue description above).

To avoid mixing everything in a single issue, I opened a few more specific issues:

• continuous-gesture revealer #27
• continuous-gesture stack #28 (closed)
• continuous-gesture leaflet #29 (closed)

Only the app-drawer/carousel is remaining, it could be implemented with the continous gesture stack but I have the feeling it may be complicated to do so cleanly that way because it may be hard to determin the right number of rows and columns to use for each page, so we may need a more complex/dedicated widget which would be a sort of continous-gesture-aware paginated flow box.

mentioned in issue phosh#205 (closed)