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.