Joongi Kim
Assigned
Reported
Comments
Long time no see. I appreciate that this issue is still being tracked and updated. 👍
I confirm that Matthew's analysis is correct and will lower the effort to address this issue, but would like to add one more thing:
In the Korean IME, the completion of IME composition should also happen with the "loosing the focus" event (e.g., when clicking outside of the input field) and "auto-completion of the current word" event (e.g., when pressing the Tab key), not only ESC/RETURN/IME-switch keys.
I have experiences with some applications that had handled this incorrectly (e.g., instead of completing the input but cancelling it upon the focus lost event). For example, a few years ago, the Chromium project made a small mistake on this, and it took a quite while for Korean people to get a correctly working version again of all Chromium and Electron-based apps (e.g., Slack, Microsoft Teams, etc.) until the upstream patch was propagated to all subsequent applications. Yes, that was very painful.
Implementation mistakes in wrong completion/cancellation of composition usually happen with auto-completion features on input fields, either in the browser itself or by the Javascript event handlers, in the web world for example. This could also happen again with the Minecraft's chat command UI since it has support for command auto-completion. We need to keep an eye on it.
As Matthew proposed, the Minecraft app itself should just let all details be handled by the OS IME in most cases by ignoring key presses as "game" inputs when an input field is active. But for the auto-completion feature, it usually requires a fined-grained interaction with the IME. So, to lower the implementation efforts, it would be also a good option to provide a configuration toggle to disable the auto-completion feature for "complex" IME users if it appears to interfere with the IME.
Mojangstas, please keep in mind the above detail if you go to implement the patch.
I don't think this is resolved by the wheel sensitivity option.
In macOS, disabling "smooth scrolling" in Logitech Options takes back the desired "one-slot per one-wheel-click" behavior.
Previous Minecraft versions did work consistently regardless of this option, but since 18w01a, the smooth scrolling option began to destroy the hotbar scrolling in Minecraft.
Though Logitech Options offers "application-specific settings" where I can disable smooth scrolling for specific apps,
it does not help us because Minecraft is a Java-based console program, not a native macOS GUI application, and thus not recognized by Logitech Options.
Still happening with 18w08b snapshot. I think it's related to LWJGL v3 update.
This hasn't happened to me, but the new snapshot 17w43a/b with LWJGL v3 began to have this issue, even with the clicking wheel mode of my MX Anywhere 2 mouse.
If I turn off "smooth scroll" option in Logitech Options, then it works like before, but it feels stuttering in other desktop applications.
Minecraft seems to be interpreting every single-pixel scrolling as a hotbar selection change.
Note that the current latest stable release (v1.12.2) does NOT have this issue no matter what the smooth scroll option in Logitech Options is, either on/off, as long as I use the clicking wheel mode of my mouse.
My environment: macOS High Sierra (10.13), MBPr 15-inch touchbar 2017.
17w43a snapshot now uses LWJGL v3 (all former Minecraft versions used v2) and the Korean IME seems to work well on macOS High Sierra (10.13) finally.
The composition window is invisible, but at least now I can type Korean charcter-by-character without modding!
17w43a snapshot now uses LWJGL v3 (all former Minecraft versions used v2) and the Korean IME seems to work well on macOS finally.
The composition window is invisible, but at least now I can type Korean charcter-by-character without modding!
For a better solution, we need to patch LWJGL as well.
I created a separate issue to continue discussion on that: MC-91132
Finally 15w43a on Windows works well with Korean IME!
The Mac version, however, has some issues on composition of Korean characters and behaves differently with different OS X IME plug-ins. This is what I have expected already, and I think that should be fixed along with lwjgl.
Anyway, thanks a lot!
1.8pre3 looks same regarding this issue.
I (and probably other CJK users) want even a partial solution (for Windows) to be applied before the official release of 1.8, and expect fundamental fixes in collaboration with the LWJGL community in a foreseeable future. (A good example is SDL's text input APIs: https://wiki.libsdl.org/Tutorials/TextInput . IME implementation was a part of community participation in Google Summer of Code 2010.)
The current status of LWJGL can be seen at link #1 and link #2. 😞
I hope I too have some time to study LWJGL/Java/cross-platform IMEs and design + implement LWJGL's IME APIs, but unfortunately I do not have enough time to do it.
I just checked out 1.8-pre2 on Windows 8.1 + Java 1.7, but it still completely ignores IME-based character inputs on the chat input.
@Torabi,
So I suggest the first-step solution (at least for Windows users):
When a text input UI is open and active: Accept any key input even if the event key state says "it's not pressed".
Otherwise: Ignore them just like now.
Unfortunately LWJGL does not have any kind of IME-related APIs, such as enabling/disabling IME. It just delivers WM_CHAR messages like key strokes. We need to collaborate with LWJGL developers to solve this issue ultimately.
In Mac, LWJGL seems to deliver only the first component of the character being composed.
I don't know how IME works on Mac/Linux platform.
BTW, I believe that even a partial solution for Windows users would be much appreciated by CJK users.
I really want to stop copy-and-pasting texts from notepad (or installing 3rd party mods just to play the vanilla version – you know, I have to wait them to update when the new version comes out)!
@Torabi,
The reason that the composition window appears regardless of chat input is open or not: Minecraft does not disable IME while text input is not open. As I mentioned above, automatic disabling/enabling IMEs depending on whether the focus is at text input is another important feature for CJK users. Gameplay keys must NOT go through IMEs (just like now) whereas text inputs MUST go through IMEs.
As I mentioned above again, Windows automatically fall-backs to OS-provided UI (the composition window you see) if the application does not explicitly call IME-related APIs to control rendering of intermediate results of character composition. In such cases, WM_CAHR window message delivers the composition results and LWJGL seems to pass them to Minecraft but the event key state says "not pressed" and thus Minecraft ignores them.
For native Windows application like notepad, the OS-provided text input control internally manages IMEs and character composition process.
1.8 prerelease on Windows 8.1 does not work with IME. Is it postponed to next minor releases?
I've tested 14w34d on a Mac (OS X Mavericks, Java 1.6, OS-default Korean IME) and it did not work completely.
Only the first consonant syllables were typed. (Most Korean characters are composed of two or three syllables, combining consonants and vowels.)
I neither confirm this issue fixed on Windows version (8.1 64bit, Java 1.7, with the vanilla launcher).
Korean IME does not use extra "selection" windows unlike Chinese/Japanese IMEs and just need the composition results to be delivered to the application.
I'll try Mac version and Linux versions soon.
Thanks a lot, @Torabi! 🙂
Yes, I agree that floating IME windows may be invisible or look ugly in the full-screen mode. (We could test and see using the snapshots!)
However I belive that being able to type our native languages is much more important than use of the full-screen mode because Minecraft works and performs well with the default windowed mode.
Ultimately in-game composition window will be the best solution, but it involves huge efforts to modify LWJGL and Minecraft itself.
I think allowing non-ASCII/IME-delivered keyboard inputs is the most cost-effective solution currently.
Mojang, please apply and release the quick fix as a snapshot to allow testing by the public, the CJK users in particular.
If it causes problems to other features, you can simply rollback the changes as many times before. I think snapshots are the perfect place to do such public tests.
If it resolves the input problem to some extent, we could discuss and make decision to close this issue or not.
If you, Mojang, have enough money, then please consider (temporarily) employ CJK Java developers to fix this problem.
Please be agile on this issue.
There are something going on:
https://github.com/LWJGL/lwjgl3/issues/946
https://github.com/glfw/glfw/pull/2130
If glfw/glfw#2130 is successfully merged, then I think finally Minecraft JE developers could add the proper IME support without much effort, as described in this issue.
It took more than 12 years from the first report (MC-2781). Now we are getting there.