Support for single/multi-Screen folds, off-center folds, and multiple folds in a single Screen.

[michaelwasserman]

Support for single/multi-Screen folds, off-center folds, and multiple folds in a single Screen.
These questions arise from discussion on w3c/window-management#35 and relate to #37

The proposed shape of exposing a single Fold (angle, orientation, and change events) within a Screen seems to indicate that a foldable screen is exposed as a single Screen interface object. However, the proposal notes relevance of "devices with a single flexible screen (seamless), and devices with two screens (with seam)".

I'd like to better understand how this API might handle:

1. Folds positioned on a seam between two Screens
2. Folds positioned off-center within a single Screen, or folds between asymmetric Screens (related to Supporting asymmetric shaped displays #37)
3. Multiple folds in a single Screen (e.g. 3+ columns, or even orthogonal/overlapping folds within a Screen?)

Please also note the relevance of the proposed Window Segment Enumeration API
Let's seek compatibility between proposals and support forthcoming screen paradigms! I hope we can discuss plans/compatibility in advance of TPAC 2020 or as a Second Screen CG topic; thanks!

[kenchris]

@darktears and I have already been asked to find out how this will scale to screens with at least two folds, and we are definitely interested in collaboration.

[kenchris]

The proposed shape of exposing a single Fold (angle, orientation, and change events) within a Screen seems to indicate that a foldable screen is exposed as a single Screen interface object. However, the proposal notes relevance of "devices with a single flexible screen (seamless), and devices with two screens (with seam)".

So far we (Microsoft and Intel) have considered hinged dual-screens, which are made up of two physical screens, as one virtual screen (with segments) and thus one viewport. The window manager is able to maximize a window to one side (one physical screen - or in a segment if you would like) but a window manager might do the same on an actual single-screen as well.

The Microsoft PowerToys (FancyZones) allows you to create such segments, and we could potentially expose those via the Window Segments API.

We could probably make that clearer in the introduction.

[kenchris]

The question is a bit how generic we want to make this. Too generic and it will be impossible to develop for, so we really need to look at that OEMs and our design teams are coming up with, but at least so far we know there will be devices with

• folds in the middle - two equally sizes screens
• hinge in the middle with two equally sizes screens
• devices with multiple folds but in the same direction (vertically or horizontally)
• separate mini screens (like in touch pad), front of phone

[kenchris]

Issues that I have heard so far

• Window Segments API doesn't expose fold area (so for a foldable phone/tablet, the area around the fold is not good for touch events and given fold, might be hard to interact with) so developers would like that exposed as a segment as well

If we have segments, we could expose the fold angle etc between them in the case that it is foldable. It will be a bit of a nice challenge coming up with an API that is flexible and still simple to use and reason about.

If we can simplify and say that segments are only in one direction things become a lot simpler.

Other question I have for @zouhir etc is do segments change size when keyboard is visible? I assume not if the overlay keyboard feature is used.

[darktears]

Window Segments API allows you to compute the fold area (segment 1 - segment 2) basically. The API supports also more than 2 segments paving the way for devices with 3 screens or more, or 2 hinges or more.