-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/mobile: Fullscreen mode, app.SetFullscreen(fullscreen bool) ? #12766
Comments
@jhsx if you'd like to propose an API for this (or use this issue to discuss it), please go ahead. You will have to work out what should be called on both Android and iOS. Android at least has more than one notion of fullscreen, so bool may not be enough. It may also be worth considering an options struct, and deciding whether or not that should be passed as a method to the App object. That is:
and then:
This could also hold EGL options, if we can find any suitable portable subset of those (I suspect we cannot). |
I prefer the android style of setting window flags, and to have different methods for window and egl management. In some cases you may want to change just one or more things related to the window and not touch the others. We can add many flags and process them according to the operation system. And sorry my english is not very good. package app
const (
FULLSCREEN windowFlag = 1 << iota
HIDE_NAVIGATION
HIDE_TITLEBAR
IMMERSIVE_MODE
IMMERSIVE_STICKY_MODE
// OR JUST
FULLSCREEN windowFlag = 1 << iota
IMMERSIVE_MODE
IMMERSIVE_STICKY_MODE
)
type windowFlag int
type App interface {
//...
SetWindowFlags(flags, changingFlags windowFlag)
}
// app code
func main() {
app.Main(func(app app.App) {
// SET FLAG
app.SetWindowFlags(
app.FULLSCREEN|app.IMMERSIVE_MODE,
app.FULLSCREEN|app.IMMERSIVE_MODE,
)
// REMOVE FLAG
app.SetWindowFlags(0, app.FULLSCREEN|app.IMMERSIVE_MODE)
})
} |
The mobile repo should avoid containing non cross-platform APIs as much as possible since the mobile packages gives a promise of API parity on multiple platforms. There must be a good middle ground that needs to be investigated that support both platforms for the most common use cases. We can tolerate platform-specific flags only for edge high-priority cases. |
I think that SetFullscreen method would be simple and easy for users, problem is on Android, should it hide the navigation (maybe enter in IMMERSIVE STICKY MODE) ? |
I don't think we are at a stage to think about the UI libraries and are still targeting native developers. Any user who has a fully featured UI library can override this behavior by providing a call from their library. Immersive sticky mode seems to be what's expected in games. FWIW, I don't know @crawshaw's long term goals for the UI libraries. I think it is his call to determine what is good enough for now and how it can be extended. |
Ok. Sure, as @crawshaw said for propose an api, i am proposing. |
@rakyll When it comes to future UI part of mobile package I hope the following is not true or set in stone yet. ios and android are so wildly different in api and philosophy. If android has an api that ios doesn't it should still be exposed, uniquely, and vice versa. If using common api approach, the code could be a huge mess with branching logic for platform and then subranching for diff platform versions with all the quirks in between. Imagine writing v4-support-libraries but now times 2 or 3 for ios/android/windows with common api calls. Looking at googles own supportlibraries code is like trying to count threads in a yarn ball as it is.
|
Sorry this issue has stalled. Native apps need a way to set fullscreen mode for games. |
If it is okay to add this to the app package, i can send a CL implementing this to Android and IOS.
The text was updated successfully, but these errors were encountered: