Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLFW 3.4 support? #25

Open
TheOnlySilverClaw opened this issue Oct 8, 2024 · 6 comments
Open

GLFW 3.4 support? #25

TheOnlySilverClaw opened this issue Oct 8, 2024 · 6 comments

Comments

@TheOnlySilverClaw
Copy link
Contributor

I just saw you were working on GLFW bindings, but only for version 3.3

I actually made my own 3.4 bindings already:
https://github.com/TheOnlySilverClaw/glfw.c3l

Just wanted to ask whether you're also planning to support 3.4 anytime soon, since I need functions like glfwGetPlatform.

@lerno
Copy link
Contributor

lerno commented Oct 8, 2024

Feel free to add a pull request to support 3.4 as well. You can look at how this is done with opengl to support different versions.

@TheOnlySilverClaw
Copy link
Contributor Author

I'll have a look. I've also noticed the current bindings don't make use of receiver functions, submodules or anything "fancy", but rather do 1:1 mappings. Is that a deliberate choice?

Just asking because I did that in my version, for example:
https://github.com/TheOnlySilverClaw/glfw.c3l/blob/develop/window.c3i
and would have to change that accordingly.

@lerno
Copy link
Contributor

lerno commented Oct 8, 2024

Yes, I think we should probably think of bindings as a two step process:

  1. The full bindings, trying to match things 1:1 so that people can get started just following along with examples written in C and just port them without having to look up the C3 names and helper functions.
  2. A custom wrapper / binding, which builds on (1) but adds C3 conveniences and can depart arbitrarily far from the "strict" bindings.

So step (1) is always the main priority, and then (2) doesn't necessarily need to be in vendor but could be offered by people from their own repos.

There is an idea for a search where people could register their libraries, and people could search them. Here one could then have several such bindings of style (2) to offer people whatever style they prefer.

Search could get connected to the vendor-fetch functionality as well, allowing as convenient a fetch as vendor would.

@TheOnlySilverClaw
Copy link
Contributor Author

Makes sense. If you want, you can have a look at my version. I've tried adding some namespacing, but other than that, it's nearly 1:1 and pretty complete.

If that's already too much deviation for your taste, I'll see whether I can adapt the 3.4 functions to the vendor style and long-term use those to build my own wrapper around.

@lerno
Copy link
Contributor

lerno commented Oct 8, 2024

I think that eventually, we'll probably have to have someone who goes through all the bindings and make sure they're consistent in style, but that's more as we go towards 0.8, 0.9 thereabouts, for now it's important that people just have bindings so that they can get started quickly. If your style isn't compatible with the other GLFW then you could have a distinct name, for example it could be "glfw34.c3l" and then you'd not need to sync it with the other glfw that we have. Does that sound good to you?

@TheOnlySilverClaw
Copy link
Contributor Author

I think I'll just use and maintain mine separately for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants