Remove GLFW from the API surface #254
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rather than exposing the GLFWwindow that is used, treat it as an implementation detail and use an opaque pointer specific to this library as the context object instead. In practice the use of GLFW can't be entirely internal since the use of GLFW in the library prevents its use by the embedder, but the details of how it is used should not be exposed. This also gives greater control over the API surface, as part of working toward a stable ABI (google#230). This does mean that the embedder cannot manipulate the GLFW window directly, but rather than trust that doing so would be safe across DLL boundaries, any functionality need by the simple embedder use cases this library enables should be exposed via wrappers.
franciscojma86
approved these changes
Jan 29, 2019
RobertZenz
reviewed
Jan 29, 2019
| const std::string &assets_path, | ||
| const std::string &icu_data_path, | ||
| const std::vector<std::string> &arguments) { | ||
| FlutterWindowRef CreateFlutterWindow( |
There was a problem hiding this comment.
Was that whitespace change deliberately?
There was a problem hiding this comment.
I'm not sure what whitespace change you mean, but since we use clang-format the answer is almost certainly yes.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rather than exposing the GLFWwindow that is used, treat it as an
implementation detail and use an opaque pointer specific to this library
as the context object instead.
In practice the use of GLFW can't be entirely internal since the use of
GLFW in the library prevents its use by the embedder, but the details of
how it is used should not be exposed. This also gives greater control
over the API surface, as part of working toward a stable ABI (#230).
This does mean that the embedder cannot manipulate the GLFW window
directly, but rather than trust that doing so would be safe across DLL
boundaries, any functionality need by the simple embedder
use cases this library enables should be exposed via wrappers.