I was looking at the 3.4 release and the concept of platform that was introduced. Having worked on the GLFW3 emscripten implementation, I am not too sure how I would implement the glfwGetPlatform() API since none of the defines make sense: the code runs in the browser so the platform is “web” or “emscripten”?
I understand that this platform is not part of the official distribution, but GLFW in the browser is a reality… Would it make sense to add a new define for this purpose?
// one of these?
#define GLFW_PLATFORM_WEB 0x00060006
#define GLFW_PLATFORM_EMSCRIPTEN 0x00060006
I think that would make sense, and personally I would choose GLFW_PLATFORM_EMSCRIPTEN.
Is the right approach to submit a pull request on GitHub?
The official GLFW repository cannot add this platform define because it doesn’t have the emscripten platform, and I don’t think we can take on an emscripten platform at the moment.
So you should just add this define to your own project: GitHub - pongasoft/emscripten-glfw: This project is an emscripten port of glfw written in C++ for the web/webassembly platform #wasm
What we can do is reserve that platform ID for Emscripten, even if it isn’t currently part of the official repository.
@dougbinks I know I can add this define to my project (and the emscripten built-in project) and I would be fine doing that, but what if in GLFW 3.5, this value is used for some other platform officially supported by GLFW?
As @elmindreda suggested, it would be great if there was a platform ID reserved for Emscripten.
I suppose an alternative would be to have an official platform ID for “other” (GLFW_PLATFORM_OTHER) which could be returned by other platforms not part of the official distribution.
A reserved platform Id for Emscripten is a good idea, though we have to be careful to ensure people don’t think this means they can use GLFW with Emscripten out of the box.
If we go that route I can see some other unofficial platforms wanting to add their defines. If we didn’t want to open up that capability then GLFW_PLATFORM_OTHER is a decent alternative. It might be best to offer a range of defines for ports which support multiple platforms (GLFW_PLATFORM_OTHER_START to GLFW_PLATFORM_OTHER_MAX or similar).
I am up for whatever solution makes the most sense for GLFW. Just let me know which way you want to go.
Our current plan is to reserve a define and add a comment in the header that this is reserved.
For example:
/*! @addtogroup init
* @{ */
/*! @brief Hint value that enables automatic platform selection.
*
* Hint value for @ref GLFW_PLATFORM that enables automatic platform selection.
*/
#define GLFW_ANY_PLATFORM 0x00060000
#define GLFW_PLATFORM_WIN32 0x00060001
#define GLFW_PLATFORM_COCOA 0x00060002
#define GLFW_PLATFORM_WAYLAND 0x00060003
#define GLFW_PLATFORM_X11 0x00060004
#define GLFW_PLATFORM_NULL 0x00060005
/*! @} */
/* Reserved platform define for external Emscripten port: 0x00060006
* See https://github.com/pongasoft/emscripten-glfw
*/
So you should be able to go ahead and use 0x00060006.
Does that work for you?
Absolutely. This is awesome and would work perfectly!
I am also planning to add support for this new (platform) API to the built-in (javascript) implementations that comes packaged with emscripten since I did some work on it recently. Although they are different implementation (one is C++, the other javascript), they represent the same platform. So maybe the comments could be:
/* Reserved platform define for external Emscripten ports: 0x00060006
* See https://github.com/pongasoft/emscripten-glfw
* See https://emscripten.org/docs/tools_reference/settings_reference.html?#use-glfw
*/
But either way, knowing that this value is reserved is enough for me to move forward with implementation! Thank you so much.
Seeing that now GLFW progress is marked as 55%, I just want to make sure that, in the next release, this blurb about the EMSCRIPTEN platforms makes it.
Is the right approach for me to submit a PR for the GitHub project?
Thanks