Support international input

[kkoreilly]

For example, when using a Japanese romaji virtual input method, the input menu is put in the corner of the window and does synchronize with events well. This is related to #9 and #568.

[kkoreilly]

We could do this if go-gl/glfw#371 is ever merged, or if we fold glfw into goosi (see #274).

[ddkwork]

gio seems to be implemented through this, but I still don't understand, currently core is specifying the font through the global setting to display Chinese?

https://github.com/go-text/typesetting
https://github.com/go-text/typesetting-utils
https://github.com/go-text/render

[kkoreilly]

I am going to figure out a good approach to international input, international fonts, and translation soon when I do my implementation of internationalization.

[ddkwork]

We could do this if go-gl/glfw#371 is ever merged, or if we fold glfw into goosi (see #274).

Let's slowly study the PR that can't be merged for two years, but I don't recommend merging the code into the core module because it's not convenient for us to pull its updates. Therefore, we should fork one, and its repository updates are not very frequent. This way, there are few conflicts when pulling, and it's easy to merge. Then, we can replace it in the module to your fork address

[kkoreilly]

We are going to see what happens with go-gl/glfw#392, and then we may consider forking glfw.

[ddkwork]

I don't think there's much hope, I used to play Fyne when I saw him deal with some issues and PR situations, compared to you, one in the sky and one underground, you are the kind of talent with good skills but very modesty, and he is not, let's start anew, no accident, that PR will continue to die in a few months.

…

---Original--- From: ***@***.***> Date: Tue, Feb 27, 2024 23:41 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [cogentcore/core] Support international input (Issue #698) We are going to see what happens with go-gl/glfw#392, and then we may consider forking glfw. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[kkoreilly]

Thanks! If there is no motion on that PR by the time I start working on internationalization, we will fork glfw.

[ddkwork]

okay

…

---Original--- From: ***@***.***> Date: Wed, Feb 28, 2024 00:11 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [cogentcore/core] Support international input (Issue #698) Thanks! If there is no motion on that PR by the time I start working on internationalization, we will fork glfw. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[andydotxyz]

gio seems to be implemented through this, but I still don't understand, currently core is specifying the font through the global setting to display Chinese?

https://github.com/go-text/typesetting
https://github.com/go-text/typesetting-utils
https://github.com/go-text/render

As I do some work in the go-text project I can provide a little context. Those packages handle how text is displayed (typesetting is the layout and complex language rules, render is rasterising the information to image/screen).
As both Gio and Fyne use those packages for text handling it's not a differentiator with regards to international support.
The input (IME and more) relates to the OS level input and event handling framework and there isn't anything we can do at the text handling level to take care of it for you.

[kkoreilly]

Yep, there are three main parts of internationalization: fonts, translation, and input. We know how to implement international fonts, and the issue for that is #568. We know how to implement translation, and the issue for that is #9. This issue is for international input (IME) support, which must be implemented at the OS driver level. There are four separate PRs in different places that each implement that: glfw/glfw#658, glfw/glfw#2130, go-gl/glfw#371, and go-gl/glfw#392. If none of these PRs are merged by the time we get to international input support, which should be in a few weeks, then we will likely have to maintain a fork of go-gl/glfw with an IME PR merged.

[andydotxyz]

Cool, seems like you have it covered then :)

[kkoreilly]

Yes, we are planning to switch over to go-text soon. Cut and paste for core.Text is a separate issue (#1051), and we will likely have better text styling as part of go-text. Thanks for the ping!

[bjorndm]

I would love to see this happen but the main problem is that the upstream GLFW project doesn't seem to accept any new features anymore, likely due to the maintainers lacking resources and time.

Ebitengine now supports internationalized input on some platforms but it uses an internal fork of GLFW.
I feel we really need to work together to make a Go language replacement of GLFW that Fyne, Ebitengine, Cogent Core, etc. could then all use. It might be a good idea to base ourselves on SDL3 since that is much more complete that GLFW is.

[bjorndm]

SDL3 supports all mobile platforms, and the web browser, even Nintendo DS (free but under NDA) .

https://wiki.libsdl.org/SDL3/README/ios
https://wiki.libsdl.org/SDL3/README/android
https://wiki.libsdl.org/SDL3/README/emscripten

Edit: SDL3 fully supports IME:
https://wiki.libsdl.org/SDL3/Tutorials/TextInput

[bjorndm]

There afaik unfortunately no completed Go wrapper for SDL3 yet, which would be preferable over a SDL2 wrapper...

[kkoreilly]

@bjorndm @gedw99 Thanks for these suggestions!

I definitely appreciate the issues with depending on upstream libraries that are written in other languages and largely unmaintained. I participated some in the initial effort for https://github.com/kanryu/mado, but that hasn't happened, partially because I have been busy working on Cogent Core. As you @bjorndm mentioned there, it is somewhat difficult to make something based entirely on the Gio API given how it is structured. I am not completely sure if SDL is the solution, but it is certainly an interesting possibility.

In general, I do not have a ton of time to dedicate to things like this, but I would definitely be willing to contribute some time if there is a viable idea that would work for both us and other GUI frameworks such as Fyne, Gio, and Ebitengine. The go-text project is a good example of how collaborative efforts between Go GUI frameworks can be successful, and I am open to collaborations.

The tricky thing is that there are many differences between the backends of our GUI frameworks, and I am not sure how much work it would be to make a single unified API. However, I do think there is potential, and so if other Go GUI framework developers are interested, and if it seems like the benefits would be worth it for the work involved, I would be interested in participating.

Just to provide some context, we are currently working on #1457, which contains major improvements to rendering and text logic. In addition to performance and structure improvements, it enables international font rendering through go-text (#568) and character-specific text selection and copying (#1051) on all platforms. It should also substantially improve web performance by rendering text directly through HTML canvas (#1056 (comment)). As such, we will focus on that until we have it merged, ideally in around a week, but it may take longer.

After that, I should have some more time for things like this, but I will still be busy with various things. We also have #9 (translation) to implement, which is separate from this but related. Regardless, I would be glad to hear your thoughts on how to proceed.

[bjorndm]

I think if we want to collaborate we will have to get the author of ebitengine, Hajime Yoshi, and everyone else on board. I myself only have Linux machines for development so I can only contribute a Linux port. But with X11 and Wayland, I think such a port needs very little C.

[kkoreilly]

@gedw99 @bjorndm Thanks for the responses. We will turn back to this in a few weeks after we finish things such as #1457. I agree that we need to contact other Go GUI framework developers if we want to collaborate on something; if others are not on board, then there is no advantage to rewriting things in a separate project.

[bjorndm]

Thanks. This might also serve as inspiration: https://github.com/hajimehoshi/guigui