fyne
fyne copied to clipboard
fyne-io
The input method is located outside the app
The input indicator box is located outside the app.
windows and mac.
like this:
Can you expand on what loads these input boxes? are they plugins or certain settings in the operating systems. Perhaps some steps to reproduce on an English keyboard?
The example I use is "fyne. IO /fyne/ CMD /fyne_demo/".
My system input box does not use third-party plugins.
I use a Chinese keyboard.
macOS 10.15.2
windows 10
Thanks, can you point to any documentation about how to enable these pop-ups so we can test?
+1 for this issue and also using Chinese input method on linux simply doesn't work, I understand this is a really an issue of upstream glfw, but it is pity that seems the fix has to wait till 3.0; it is really important for application that needs to support language other than English; I love the simplicity/extensibility of fyne, that's why I chosen fyne instead of other GO GUI lib for my application, but then I only found this issue out very late in my development, it is a real bummer ...
+1 for this issue. Here is the info that may help test:
About IME(input method editor): Basicly:
An Input Method Editor (IME) is a software component that enables a user to input text in a language that can't be represented easily on a standard QWERTY keyboard. This is typically due to the number of characters in the user's written language, such as the various East Asian languages.
More info on microsoft or wikipedia.
How to enable an IME on an OS: OS like windows or macOS go with an IME, just need to add the language to the list:
Then users can switch between a simple keyboard input or an IME.
Use Any IME with fyne should reproduce the problem, may have some relationship with GLFW. Hope it's not too hard to fix.
@andydotxyz
There is a GLFW patch available that adds the necessary API to do this. Could we not already apply that patch for Fyne?
Since I would like to use Fyne for writing a Japanese healthcare application, I would like this issue to be solved as soon as possible. If needed I can ask my employer to provide for a bounty for fixing this. Or otherwise I could fix it on the Go side as long as we can use a patched GLFW for support.
https://github.com/glfw/glfw/pull/2130
Fwiw, Raylib also is fixing this issue, this is how I found that patch: https://github.com/raysan5/raylib/pull/2809
@bjorndm I am one of the maintainers both here and in that project. Thus, I responded on the ticket there with my thoughts about carrying that patch downstream.
While I understand that it is problematic for you, I personally don’t feel comfortable maintaining such a big patch. I hope you understand my reasoning :)
@Jacalz I understand. I will probably make a personal or company fork of all 3 projects to deal with this. I hope to contribute back though.
The glfw PR is huge and an amazing step forward. It will require to do the work that was done for raylib, but in Fyne. @bjorndm if you pick this ahead and start working on integration in Fyne. You could maybe have it ready to when it get merged upstream. I think everyone here is looking forward for this to be available and there is a need for this feature in Fyne.
@The problem is that upstream progress on GLFW is extremely slow. So even at that level I will have to make a fork, if a bounty doesn't work.
https://github.com/bjorndm/glfwff/releases/tag/3.4.1 I have the fork with the IME patch and some other feature merged in. Also, this is based on the master branch of GLFW so it's likely to become 3.4 compatible in the future. There are some internal changes to GLFW from 3.3, which do make merging older PRs a bit more difficult...
I changed the name to GLFWFF because technically I think the zlib license requires this.