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

Open
jhsx opened this Issue Sep 27, 2015 · 9 comments

Comments

Projects
None yet
6 participants
@jhsx

jhsx commented Sep 27, 2015

If it is okay to add this to the app package, i can send a CL implementing this to Android and IOS.

@jhsx jhsx changed the title from Fullscreen mode, app.SetFullscreen(fullscreen bool) ? to gomobile: Fullscreen mode, app.SetFullscreen(fullscreen bool) ? Sep 27, 2015

@rakyll rakyll added this to the Unreleased milestone Sep 27, 2015

@rakyll

This comment has been minimized.

Member

rakyll commented Sep 27, 2015

We still haven't got to a conclusion about how the APIs must look like. See the previous discussion at #9508.

/cc @crawshaw

@adg adg changed the title from gomobile: Fullscreen mode, app.SetFullscreen(fullscreen bool) ? to x/mobile: Fullscreen mode, app.SetFullscreen(fullscreen bool) ? Sep 28, 2015

@crawshaw

This comment has been minimized.

Contributor

crawshaw commented Sep 28, 2015

@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:

type AppOptions struct {
    HideTitleBar bool // set to true is traditional android fullscreen
    Fullscreen bool // android immersive mode, implies HideTitleBar?
}

and then:

type App interface {
    ...
    SetOptions(o Options)
}

This could also hold EGL options, if we can find any suitable portable subset of those (I suspect we cannot).

@jhsx

This comment has been minimized.

jhsx commented Sep 28, 2015

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)
    })

}
@rakyll

This comment has been minimized.

Member

rakyll commented Sep 28, 2015

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.

@jhsx

This comment has been minimized.

jhsx commented Sep 28, 2015

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) ?
For games, i think yes, i don't know about the other use cases.

@rakyll

This comment has been minimized.

Member

rakyll commented Sep 29, 2015

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.

@jhsx

This comment has been minimized.

jhsx commented Sep 30, 2015

Ok.

Sure, as @crawshaw said for propose an api, i am proposing.
BTW, thanks you all for bring Go for android can't wait for start use.

@diegomontoya

This comment has been minimized.

diegomontoya commented Oct 23, 2015

@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.

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

@gopherbot gopherbot added the mobile label Jul 20, 2017

@udhos

This comment has been minimized.

udhos commented Aug 16, 2017

Sorry this issue has stalled. Native apps need a way to set fullscreen mode for games.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment