search

fyne-io / fyne

Cross platform GUI toolkit in Go inspired by Material Design
https://fyne.io/
Other
24.56k stars 1.37k forks source link

Device Orientation Hints / Lock #1845

Open AlbinoGeek opened 3 years ago

AlbinoGeek commented 3 years ago

Is your feature request related to a problem? Please describe:

I cannot lock the orientation of my Landscape-only Android game.

Is it possible to construct a solution with the existing API?

No. (Although, adding a method to App would be non-breaking, because afaik, users are not supposed to extend App.)

Describe the solution you'd like to see:

I would like at least 4 of the 9 Android modes to be implemented:

Mode Android iOS
Default screenOrientation.DEFAULT TScreenOrientation.Auto
Landscape screenOrientation.LANDSCAPE TScreenOrientation.Landscape\|TScreenOrientation.UpsideDown
Natural screenOrientation.NATURAL
Portrait screenOrientation.PORTRAIT TScreenOrientation.Portrait\|TScreenOrientation.PortraitReversed

https://developer.android.com/reference/androidx/browser/trusted/ScreenOrientation

AlbinoGeek commented 3 years ago

This can also be done at runtime on iOS, on a per-view basis: https://nunoalexandre.com/2018/08/24/forcing-an-orientation-in-ios

I would prefer for runtime orientation support, v.s. compile-in hints.

andydotxyz commented 3 years ago

We have support for portrait and landscape orientations. It would be possible to add a "supported orientations" configuration somehow, but I don't understand the need to add new types of orientation to do this.

AlbinoGeek commented 3 years ago

Sorry, the table will make a lot more sense now. I was trying to show the Android and IOS equiv. for each setting.

I would not call these "new orientations" unless fyne does not currently understand the difference between "Portrait" and "UpsideDown" for example (which is a complete 180 degree difference), or Landscape and its inverted counterpart.

As well, the intention with this ask is that you would be able to change orientations at runtime, not just compile-in hints.

Both mobile platforms (and Desktop) support compile-in hints and run-time (view-based) orientation hints.

Example include: Crunchyroll App which displays only in Portrait until you start playing an episode, then the App changes its supported orientations to only Landscape and InvertedLandscape so that you can watch the video at its' normal aspect ratio, returning to only Portrait when you close a video. It explicitly uses every orientation except "UpsideDown".

andydotxyz commented 3 years ago

As well, the intention with this ask is that you would be able to change orientations at runtime, not just compile-in hints.

This is not something I am keen to add. A window should respond to user events, not force changes that the user did not request (this is the mobile equivalent of the desktop discussions about moving/maximising windows using an API IMHO).

If an application wishes to support landscape it should not only do so when certain screens are visible. Right now all apps are expected to support all orientations, changing this would be exposed as an orientation lock as far as I can see.

AlbinoGeek commented 3 years ago

If an application wishes to support landscape it should not only do so when certain screens are visible.

Sure, but then fyne would have to support my requested orientation locking at a window level, still requires this implemented; just changes where/how it gets implemented (e.g: not app-wide, but view-wide, which is currently abstracted to windows I think?)

andydotxyz commented 3 years ago

We appear to not be on the same page. I am trying to say that windows should not force users to rotate their device to accomodate a change in what is shown.

AlbinoGeek commented 3 years ago

I haven't used an iPhone for quite some time, but that doesn't match Android.

A number of rotation changes are outside of the developer's control entirely:

Many video applications (most notably, as I use it often, Crunchyroll); are forced Portrait for the entire application, until you go to watch a video, which you would expect to be able to fullscreen, and therefore force the device to rotate to any landscape orientation.

It makes close to zero sense to be forced to watch wide content in portrait mode, where it only takes 1/6th of your screen height...

All of these situations could be handled by your quote, if it meant what I thought it did:

If an application wishes to support landscape it should not only do so when certain screens are visible.

Current confusion seems to be down to me not understanding what you meant by that, if not giving the developer the ability to decide that the device's orientation was locked "when certain screens are visible", then I really can't figure out what you meant by that.

(and again, since fyne's only concept of screen is currently a Window... where did we end up with different ideas of this?)

andydotxyz commented 3 years ago

I agree that I am contradicting what Android (and iOS) allow you to do. I am not keen to replicate features that we can be a bad user experience. What I am trying to explain is that forcing a user to rotate their device is in the same area as allowing desktop apps to move windows or control how the app is positioned on the screen - sorts of things that should be controlled by the user or the OS, not the developer.

So, if you want a video to play in landscape then that's great, allow the user to hold the app in landscape. But if they are in portrait mode, you should render it that way (see YouTube app etc).

As for locking the orientation for an app - if it can truly only support landscape or portrait we could add, at an app level, the ability to block other orientations - but it feels dangerously close to my objections above. We should be working for the user, not making them adapt to how an app is written.