If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Implement Left/Right gestures in the system application to switch between apps

RESOLVED FIXED

Status

Firefox OS
Gaia::System
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: vingtetun, Assigned: etienne)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

1.26 MB, application/pdf
Details
46 bytes, text/x-github-pull-request
alive
: review+
Details | Review | Splinter Review
Basic left/right gesture support to swipe from app to app. In order to implement this it would be good to wait for the new window manager to not do this work twice.
(Assignee)

Updated

4 years ago
Assignee: nobody → etienne
(Assignee)

Comment 1

4 years ago
Created attachment 815276 [details]
UX Spec
(Assignee)

Comment 2

4 years ago
Created attachment 826984 [details]
WIP
(Assignee)

Comment 3

4 years ago
Created attachment 827734 [details] [review]
Pointer to gaia PR

Let the fun begin :)
Attachment #826984 - Attachment is obsolete: true
Attachment #827734 - Flags: review?(alive)
Comment on attachment 827734 [details] [review]
Pointer to gaia PR

Almost is good as an initial draft of swipe gesture implementation but forgive my picky. I'd like (App)StackManager to have it's own list of appWindow instances to avoid coupling with (App)WindowManager too deeply.
Attachment #827734 - Flags: review?(alive)
Also I prefer to move SheetTransition into AppWindow,
that means we could just call App.moveTo(x)/App.FinishTransition()/..... in EdgeGestureDetector or AppStackManager/AppSheetManager ...whatever.

But it's fine that we do this later after bug 907013 is landed.
One more thing about screenElement overloading:
Currently it's overloading by lots of classes and some of them may be not necessary.
For example if I move the modal dialog into the appWindow we don't need screen.modal-dialog anymore.
The dom element structure is what I want to speak here: Just let parent(the one control it) or itself do the style controlling.

For example,

A > B > C > D > E {
}

If we want to control E's style, do it in D or E itself by appending classes in D instead of going through up to A.

With this we don't need to write dirty rules like A.aaaa.bbbbb:not(.ccccc):not(.ddddddd).eeee.ffff.gggg { .... }

In your use case I think we could just control the style of edge line directly but in the case about transitioning it's O.K. to do that after bug 907013. So this comment is just added to track this issue addressed in github comment already.
(Assignee)

Comment 7

4 years ago
Comment on attachment 827734 [details] [review]
Pointer to gaia PR

Updated!
All the comments should be addressed :)

I'm still listening to launchapp/launchwrapper because |appopen| also gets triggered when you swipe from one app to the other.

But we're now storing app objects in the StackManager which is indeed way cleaner!
Attachment #827734 - Flags: review?(alive)
Comment on attachment 827734 [details] [review]
Pointer to gaia PR

r+ except for the stayBackground.
BTW travis is unhappy https://travis-ci.org/mozilla-b2g/gaia/jobs/13605336
Attachment #827734 - Flags: review?(alive) → review+
(Assignee)

Comment 9

4 years ago
https://github.com/mozilla-b2g/gaia/commit/55cf586b78f1f2d88f376260b3e2a167b3da920b

Thank you *so* much Alive and Vivien, this was a wild ride!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
I could figure out lots of followup now :)

Updated

4 years ago
Blocks: 923441

Updated

4 years ago
Flags: in-moztrap?(jhammink)

Updated

4 years ago
No longer blocks: 923441

Updated

4 years ago
Flags: in-moztrap?(jhammink)
You need to log in before you can comment on or make changes to this bug.