Add IME support.

[kanryu]

summary

@bjorndm has already posted a PR (#371), but this is an independent implementation.

I needed IME support with Fyne, and I solved this problem with go-gl/glfw.

policy

• make v3.4/glfw
• glfw/glfw is based on https://github.com/clear-code/glfw/tree/im-support
• In fact, the implementation in this branch lacked IME support, so we made some further fixes.

By merging this PR with others, Fyne and many other toolkits and users will be able to implement IME support on their own OS.

IMEs on each os

Windows

Mac

Linux

[dmitshur]

Thanks for preparing this.

One possible way to move forward is for this change to be made available on a go-gl/glfw fork until the IME work lands in GLFW upstream. That is, take this change with little to no modifications (i.e., change the module path in go.mod) and make it available at somewhere like github.com/fyne-io/glfw/v3.4ime/glfw, with a README that describes its content. We can update the README in go-gl/glfw to link to it. One example of a go-gl/glfw variant is https://github.com/goxjs/glfw (i.e., it adds browser support).

That way Fyne and others can start using it now without waiting. Once GLFW 3.4 (and the work in glfw/glfw#2130 or equivalent) lands and becomes available in a released version of GLFW, the go-gl/glfw version will incorporate it, and callers of the v3.4ime variant can switch to it if they'd like.

This is to say I would suggest we keep the scope of go-gl/glfw limited to providing Go package versions of released upstream GLFW versions and features implemented there. What do you think about taking this approach?

[Jacalz]

As one of the developers in the core team of Fyne, it is worth noting that I personally am hesitant about using a GLFW fork. No offence but, in case of any confusion, I think it should be said that this PR comes from a member of our community but not from us directly.

I understand that IME is important for a lot of people but I don't want to deal with having to wait longer for GLFW releases, having to rebase a bunch of patches and to not know the quality of the added commits in the fork. There is work happening upstream on IME support and I'd much rather wait for official support rather than potentially sacrificing on quality and update speed.

This view on the matter is entirely my own and not something that I have discussed further with the rest of the team.

[kanryu]

Thank you for your comment. This PR is more of a suggestion than a request, and I think it is unlikely that this PR will be integrated into the project. This result is clear from the fact that another user's PR has been neglected for many years.

This PR is not so much a result of enabling IME support as evidence that it is difficult, frankly impossible, to integrate it into the current glfw/glfw and go-gl/glfw.

I'm currently working on building a new glfw compatibility layer with a pure Go language implementation, which will have full IME support implemented from the beginning. I think glfw has gone too far into the jungle. It's not anyone's fault, including you. This is a natural progression.

[Jacalz]

I think it is unlikely that this PR will be integrated into the project. This result is clear from the fact that another user's PR has been neglected for many years.

That is a very unfair and incorrect thing to say. Look at the list of merged PRs and you will see that many been merged recently. The oldest one open is waiting for changes upstream, the second oldest is a draft and the one before yours is the only one that has been sitting without a review...

[Jacalz]

This PR is not so much a result of enabling IME support as evidence that it is difficult, frankly impossible, to integrate it into the current glfw/glfw and go-gl/glfw.

It seems to me that this also is rather incorrect. Work is happening upstream in glfw/glfw#2130 (comment) and it is planned for v3.5.0. I understand that it has taken time but I see zero reasoning to suggest that it is impossible to integrate IME. Once a solution is available upstream, I'm more than happy to get IME into go-gl/glfw but not so much as long as that work exists in a fork.

[kanryu]

@Jacalz I appreciate your efforts to review and merge PRs, including yours. However, #371 has already been abandoned for nearly a year, and it is clear that this PR will follow the same path.

Regarding glfw/glfw's IME PR, this PR is already in its third generation, and the first one was posted in December 2015.

• Add IME support for each platform glfw/glfw#2130
• Draft: Add IME support for each platform glfw/glfw#2117
• Better IME support glfw/glfw#658

You're right that the glfw/glfw PR is set for the 3.5 milestone, but glfw-3.3 was first released on April 16, 2019, and glfw-3.4 was released. is February 24, 2024.

[Jacalz]

However, #371 has already been abandoned for nearly a year, and it is clear that this PR will follow the same path.

As explained above, the author of that PR marked it as a draft and as such we have not reviewed it, as is practice on GitHub.

You're right that the glfw/glfw PR is set for the 3.5 milestone, but glfw-3.3 was first released on April 16, 2019, and glfw-3.4 was released. is February 24, 2024.

It looks like there is and has been more upstream activity as of recently. There might have been a lack of maintainers during that long period. v3.5 doesn't have to be years away just because of the cadence between previous releases but I do see your frustration.

[kanryu]

@Jacalz Thank you for the announce! I've accepted many PRs for projects I own, but none of them were drafted because they were all small PRs. That's what GitHub's draft PR means. I learned a lot. :)

Should I change this PR to draft as well?

[Jacalz]

A PR that is actively worked on but not ready for review is generally marked as a draft

[kkoreilly]

I'm currently working on building a new glfw compatibility layer with a pure Go language implementation, which will have full IME support implemented from the beginning. I think glfw has gone too far into the jungle.

If you do end up making a new glfw implementation based in Go, I would be interested in contributing to that, since I have been planning to do the same thing for a long time, as glfw often acts as an unnecessary and feature-incomplete middleman.

[kanryu]

@kkoreilly So you have your own toolkit project too!

I modified the gioui base layer and succeeded in running the most basic glfw sample program through the go-gl/glfw compatible API. Currently, operation has been confirmed on Windows and Mac OS.
This is currently a private project, but if certain results are met, it will be released under the MIT license. Please send me email if you are interested.

[kanryu]

@kkoreilly Hi,
I've created the glfw alternative implementation you've been waiting for.
The name is mado. Most of the source code is written in Go, and I ported the OpenGL initialization code from glfw, but almost all of it was written in Go.
https://github.com/kanryu/mado

Please let me know if you are interested.

[kkoreilly]

Yes, I am interested. I will try it out and see how it can integrate with my framework, Cogent Core. If it works well, I will import it and contribute to it.

[kkoreilly]

@kanryu, are you planning to develop mado as a fork of gio or as a standalone glfw replacement? There is still a lot of gio GUI code in the repository, and it would be hard for me to import the project in Cogent Core if it contains that. This is also kanryu/mado#4.