IME support
bjorndm opened this issue · 6 comments
I would like to work on getting IME support into the go language wrapper of GLFW. While this is only a PR I need it downstream in Fyne. Any suggestions on how to help out with this are welcome.
Carrying patches downstream can be problematic and is often, but not always, quite a big burden for maintainers.
I don’t personally know how much the upcoming glfw 3.4 release (on their master branch) compares to the stable v3.3.x releases that we are currently using. It may or may not be problematic to backport to the older release depending on how much the code has changed in between (before that PR was merged into the master branch).
As someone that has maintained Linux packages before, I am not a huge fan of carrying patches downstream. They often break when there are new releases (such as new minor v3.3.x releases in this case) and thus require manual intervention to get them working. That manual intervention can be both tricky and time consuming sometimes. We only carried patches when it was absolutely necessary for having the package working. Everything else could wait for the next release.
No offence, but the best option is, in my opinion, to just wait for the v3.4.0 release of glfw. I absolutely understand that it isn’t ideal for you but it is a huge PR and the cost of maintaining it as a patch just feels problematic to me.
@Jacalz Thanks for the heads up. I certainly understand your point of view. I'll probably have to make a personal or corporate fork of glfw of go-gl/glfw and Fyne and bear the burden myself like that, but I hope to contribute back once this gets merged upstream. However the glfw upstream is extremely slow so I can't afford to wait for that at least for the relevant project I have. So , I guess this issue here is on hold until further notice.
Yeah, they are unfortunately quite slow with their releases. I totalt understand that you have to do it that way and can't wait.
One option that might be doable is to carry a v3.4 branch for testing of the upcoming release. I would suspect that it could be helpful for other purposes as well (testing but also to make the switch to v3.4 faster once it gets releases as stable)
Well, a v3.4 branch might be helpful, but I still have to see how I will do this. I was considering naming my branch of glfw glfwff (ff for fast forward or fully featured) and then also using that in my clone of this project.
Actually a 3.4 branch would be very useful because the internals of glfw have changed (see the master branch) so the cgo code will also have to change significantly.