I originally created an issue on Github, before I discovered in the
CONTRIBUTIONS.md file that this was highly discouraged for my type of issue. So I’ll paste the original text into here. Contributing to GLFW, where to find things, and where to write and discuss things, is very confusing.
Is there some kind of a roadmap or structured overview of which platform specific APIs that are planned, on hold, or declined, to be part of GLFW?
The milestones do not specifically list exactly which APIs we/you want to expose/wrap or not.
For those of us working with GLFW through a wrapper, in a non-native language (such as Java + LWJGL), interacting with these native APIs is not a happy experience. So for that purpose, the more that gets put into GLFW, the better. This comes with a great risk of bloating GLFW, as well as piping platform specific APIs through GLFW in a way that later hampers or prevents platform-agnostic APIs from being added. There’s also a risk of introducing APIs that provide subpar and severely limited functionality of the native API, and interfere with client code’s attempts at working with the native API for platform-specific features. There’s a lot of open issues, much more than @elmindreda and other important developers can work on alone. For example, I have tried looking into helping with MacOS code, but the more I look at it, the more Cocoa functionality I discover, that would be a great addition to GLFW seen from the perspective of MacOS, but not necessarily from other perspectives.
This might not be an issue to those of you that know all the different platforms very well (MacOS, Windows, X11, Wayland), but I believe it can be a valuable resource to those of us that don’t. I know the capabilities and limitations of Cocoa, but not the other platforms, and even if multiple platforms support similar functionality, I don’t know how to best bridge them. If similar functionality exists across platforms, and it’s been decided that wrapping this in GLFW is a good addition to GLFW itself, such efforts are best discussed in dedicated issues or PRs.
GLFW wraps/exposes certain platform-gnostic APIs, not only for compatibility reasons, but also simplifying common tasks. It would be nice to know which ones should not be exposed, which ones should be exposed in a platform-gnostic way, and which ones in a platform-agnostic way.
I also wonder what the overall plans for GLFW 4.0 are, and which parts of the library are supposed to be redesigned, and the reasons behind it. Many of the issues and PRs for GLFW were created many years ago, and the discussions in them span several years. I believe the lack of a greater overview raises the bar for participation, raises the risk of incompatibly adding functionality, greatly increases development time, and puts more strain on everyone that maintains, develops and contributes to GLFW.
There is also a chance that I myself have come to request this, because I failed at navigating the issues, and building myself a mental overview. Discussions in issues and PRs are scattered, and it’s not necessarily easy to search for discussions revolving a particular platform’s API. I may also be somewhat impatient. My apologies if I made a mistake here. Perhaps it is best if each of these native APIs are discussed in dedicated issues, from start to end?