Would it be possible to add support for borderless window mode? Thanks! 馃憤
This can be done by adding an Option that overrides a default in Application config. By default we should enable borders. They may be disabled in GLFW using the decorated attribute: https://www.glfw.org/docs/latest/window_guide.html#GLFW_DECORATED_attrib
This can be done in core go-flutter. Not sure if it should be a plugin.
I'll open a PR on go-gl/glfw to support glfwSetWindowAttrib.
Such features can be done in core go-flutter, but I'll like to keep the numbers of Option small. And IMO encouraging people to understand and tweak around the package is better than solving local demands.
That being said, I think there is room in plug-ins for a specific go-flutter plug-in that will take care of setting an multiple WindowAttrib
I think go-flutter must be in charge of the window and application lifecycle. Plugins are meant to support platform specific features that are not in scope for go-flutter. E.g. webcam, audio, webview, etc.
Imo the PluginGLFW interface already exposes too much. I want to write an abstraction layer that is implemented by GLFW (and in the future possibly others). All window settings should be configurable in Application config via Options, so that the user doesnt have to worry about the GL and window managing back-end. Until then the Options can stil be created but applied using the internal plugins workarround, that way they are future compatible, even when PluginGLFW goes away. The option will still be there but work through the correct abstraction layer.
Most helpful comment
I think go-flutter must be in charge of the window and application lifecycle. Plugins are meant to support platform specific features that are not in scope for go-flutter. E.g. webcam, audio, webview, etc.
Imo the PluginGLFW interface already exposes too much. I want to write an abstraction layer that is implemented by GLFW (and in the future possibly others). All window settings should be configurable in Application config via Options, so that the user doesnt have to worry about the GL and window managing back-end. Until then the Options can stil be created but applied using the internal plugins workarround, that way they are future compatible, even when PluginGLFW goes away. The option will still be there but work through the correct abstraction layer.