search

webscreens / screen-enumeration

Screen enumeration API explainer
Apache License 2.0
23 stars 4 forks source link

Dynamic properties #11

Closed mrunalk closed 4 years ago

mrunalk commented 4 years ago

I looked at the api and one thing which I found missing is the display in focus or active where user might be typing or has it's mouse pointer in focus. The detail this api provides seems fairly static. Do you plan to add any dynamic properties or that's not the goal of this api?

Garbee commented 4 years ago

What are use-cases for including any given dynamic property?

Use-cases drive the requirements of the APIs. If there aren't any presented then it's hard to justify building them out, speccing them, and then pushing for them in the standards organizations.

michaelwasserman commented 4 years ago

There's no current goal to expose an "active" screen with window focus or pointer presence. Please do share use cases, but I suspect that would be complex (eg. active window spans screens) and have privacy and abuse concerns (eg. pointer tracking).

Please also see Issue #12 regarding the general approach for static or live objects.

mrunalk commented 4 years ago

For example, Microsoft's new Surface Neo, https://www.microsoft.com/en-us/surface/devices/surface-neo has two separate screens which fold. If it is folded in other direction only one screen might be visible making that the "active" and other one inactive. Similar state changes could be thought of for other multi-screen or foldable screen devices where 2nd display might turn-off or primary or secondary display readjusts it's resolution. Example for this could be adjustable keyboard on the 2nd screen of Surface Neo. I know it's still too early to talk about such devices but considering this api tries to address new and upcoming use cases I wanted to throw this based on potential use-cases.

Malvoz commented 4 years ago

Microsoft has a proposal for the Window Segments Enumeration API targeting foldable devices.

plinss commented 4 years ago

One can also envision upcoming screen technology like roll-up screens that can change dimensions over time. I accept that we don't want to throw every theoretical property into the API until there's a need, but some forward thinking and future-proofing the API can be worthwhile. Existing technology already supports dynamic screen changes, e.g. screens changing availability, orientation, and relationship to each other, it makes sense to extend this to allow dynamic updates of more properties.

(I got here from https://github.com/w3ctag/design-reviews/issues/413)

michaelwasserman commented 4 years ago

Thanks for the discussion here; the current proposal suggests exposing static snapshots and firing events on changes.

That seems to align with Web Platform Design Principles advice and should handle scenarios described in this issue (screen dimension changes, future "active" screen property and changes). Additional exploration materials also discuss this topic with related info in a couple subsequent topics. Issues #12 and #8 discuss similar considerations.

The additional explorations doc also considers ways to check the "current" screen, and it might be useful to add separate tracking of an "active" screen; I filed webscreens/window-placement/issues/17 to track that enhancement.

I'm going to close this issue, but welcome new feedback on these topic in the updated Window Placement repo; thanks!