Trejkaz
- trejkaz
- trejkaz
- Australia/Sydney
- Yes
- No
MC-39201
Mouse buttons stop working after activatingExposéMouse buttons stop working after activating Mission Control
I know this one will sound stupid when first read, but please hear me out.
Number formatting.
Currently item stacks use String.valueOf to format the number of items. This assumes that the entire world wants to see these digits:
0123456789
But for example in some Arabic locales, though, the users want to see these digits:
٠١٢٣٤٥٦٧٨٩
Instead, I would like Minecraft to use NumberFormat.getIntegerInstance().format(value). The formatter can be cached for reuse and has fast-path rendering so I would even hope that performance not be a problem.
For message strings, if any happen to contain numbers I would hope that MessageFormat is already being used, and ideally ICU's as Java's doesn't deal with Arabic well either.
I know this one will sound stupid when first read, but please hear me out.
Number formatting.
Currently item stacks use String.valueOf to format the number of items. This assumes that the entire world wants to see these digits:
0123456789
But for example in some Arabic locales, though, the users want to see these digits:
٠١٢٣٤٥٦٧٨٩
Instead, I would like Minecraft to use NumberFormat.getIntegerInstance().format(value). The formatter can be cached for reuse and has fast-path rendering so I would even hope that performance not be a problem.
For message strings, if any happen to contain numbers I would hope that MessageFormat is already being used, and ideally ICU's as Java's doesn't deal with Arabic well either.
I want to relate another story, just in case it's the same issue, to avoid having to open yet another duplicate.
I had built my bed with one square of air around each side except for the head, which worked fine. Later, I had mined out the blocks underneath the bed, planning to replace the floor material, only I had forgotten to bring the replacement. Getting the replacement required going outside and it was night, so I went to sleep. On awaking, I was placed inside stone somewhere and died. It was a hardcore playthrough so I didn't get a chance to investigate exactly where I got placed.
Also I should add that I know it's only F3 to bring up that screen, but for other reasons of Mac OS intercepting F3, I found I had to hold control. It looks like that is no longer the case though, after changing my work keyboard preferences to act as F keys by default, F3 by itself now brings up the stats.
In other words, now F10 triggers the problem instead. orz
I guess this bug's scope just got wider. It also affects mouse buttons and also occurs when doing actions other than fullscreen.
And still occurring with the combination of OS X 10.9, Java 7u45, Minecraft 1.7.2.
Rafael might be right about it being LWJGL. It could also be Java itself, because there is a similar quirk in AWT/Swing where if you press the mouse on a window and release it outside the window, the application gets a mousePressed but no mouseReleased event. Applications (and frameworks) have been working around it by listening for other events. That issue itself supposed got fixed in Java 8 but I'm not sure if it got back-ported to 7.
I can't speak for this ticket itself, but the issue I reported which was marked as a duplicate (
MC-39201) appears to have been fixed some time before 14w30c. The current behaviour is that letting go of the mouse button while Mission Control is up immediately stops the mouse action, so no buttons are down on re-entering Minecraft.It certainly affected the gameplay for me, because I wasn't able to use the mouse anymore after it happened.
I would settle for the ability to rebind "next slot" and "previous slot" to be anything other than "mouse wheel up" and "mouse wheel down". Why are these two actions the only ones that I can't reconfigure? Anyone with a reasonably modern mouse is going to be annoyed by this.
Confirming that Japanese at least still doesn't work on Mac OS X 10.11. It behaves the same as before - latin characters come out even if I'm not using the English input method.
I find it hard to call this "fixed" when it still doesn't work for many people...
Maybe change your wording to "thanks to Grum for fixing this bug for some of us". The rest of us will continue waiting and expect a fix some time before 2035.
@Kumasasa I know (I'm already watching it). I was addressing someone who claimed that this bug has been fixed, when it has not actually been fixed yet.
The rest of us have been seeing this forever... so it does sound different on the surface, but maybe it's just two different symptoms for the same problem.
I'm not sure this is better, lol... I just tested it for Japanese.
If I hit 'T' and then type てすと, the characters appear nowhere. The IME window does pop up below the Minecraft window, seemingly in the right position even, and with the right contents. If I press Enter, I expect this to enter the text as it already is, but nothing is entered and it just closes the IME. If I press Space, it does correctly go into the IME choices, but pressing Enter from those doesn't input the resulting choice either.
Additionally, if Japanese input is enabled while you're not in the chat field, the IME triggers when it should probably be disabled, which results in a bit of comedy:
I should add, direct instantiation of DecimalFormat is slightly evil as well, as it too bypasses locale preferences. It's possible to get a NumberFormat from the factory method and then set the precision on it, and this is good enough for most situations.
I'm not sold. If you're showing the wrong content to the user after they selected their language, it's a localisation bug.