[contrib.glfw3] New version 3.4.0.20240817

[ypujante]

Release notes:

• Major clipboard changes: the clipboard now uses the browser events to handle cut, copy and paste
• Added a way to tweak the timeouts for the Super + Key workaround (Super is also known as Meta or Cmd)
• Added a way to set which keys are allowed to be handled by the browser
• Added a convenient API to open a URL (emscripten::glfw3::OpenURL)
• Added a convenient API to detect if the runtime platform is Apple (emscripten::glfw3::IsRuntimePlatformApple),
  mostly used for keyboard shortcuts (Ctrl vs. Cmd).
• Added GLFW/emscripten_glfw3_version.h with EMSCRIPTEN_GLFW_VERSION define for compilation time version detection
• EMSCRIPTEN_USE_PORT_CONTRIB_GLFW3 port define now also contains the version

Warning

Breaking changes!
The clipboard async API has been removed.
Check the Clipboard support section for details on how to deal with the clipboard in your application.

[sbc100]

Does it really make sense to add misc new function such as OpenURL and IsRuntimePlatformApple to the glfw library?

Why not stick to the GLFW API and put those APIs in another library?

[ypujante]

@sbc100 thank you for providing feedback.

glfw already has the concept of platform but it is a compile time concept because it is meant to be compiled and run on a given platform. I absolutely need the concept of runtime platform for the internals of the library so I just expose it because it is being needed by other libraries (ex: ImGui which now supports emscripten-glfw).

For openurl it uses a deferred click approach which is also already implemented in the libraries. So it is trivial to add as well.

These functions are in their own headers and you don't have to use if you don't want to. It is not changing the glfw API in any shape or form.

Am I supposed to create a brand new library for 2 completely unrelated functions and add a new contrib port for them? I don't think that would even be accepted and even if it was, honestly I don't want to go down this route given the amount of work/maintenance...

[sbc100]

i just don't see how those function are related to GLFW itself. They just seem like misc unrelated functions. I can't stop you from developing your library however you want, but its seems like its evolving from a port of glfw to something more than that.

[sbc100]

Perhaps those two new function could live in emscripten itself?

[ypujante]

i just don't see how those function are related to GLFW itself. They just seem like misc unrelated functions. I can't stop you from developing your library however you want, but its seems like its evolving from a port of glfw to something more than that.

Like I said I do appreciate your feedback and input. At this time I would like to proceed with these changes. I am waiting for these to submit a PR on ImGui to add full support for clipboard using my library (library_glfw.js has no support whatsoever for clipboard and SDL has only library support for clipboard, meaning you cannot copy/paste with another application... which makes my library the only emscripten library with full clipboard support... and this change requires to know the runtime platform).

ImGui::GetIO().ConfigMacOSXBehaviors = emscripten::glfw3::IsRuntimePlatformApple();

FWIW, SDL offers an SDL_OpenURL api and I believe I would not be surprised if GLFW 3.5 adds it as well.

Thanks

[sbc100]

Well I guess the point of the contrib ports is so that you can forge your own way.

I would like you to consider those functions for inclusion upstream somehow though so others (who don't use glfw) could also benefit (assuming they are useful APIs to have).

[ypujante]

@sbc100

Well I guess the point of the contrib ports is so that you can forge your own way.

This is true, but I do genuinely appreciate your feedback and point of view. Having somebody external offer their perspective is always valuable. I am definitely not planning to turn emscripten-glfw into a bag of random unrelated functions.

I would like you to consider those functions for inclusion upstream somehow though so others (who don't use glfw) could also benefit (assuming they are useful APIs to have).

That is a fair point. I can take a look at providing similar APIs with library_html5.js if you think that would be the right place for them.