Entering CJK characters fails on Windows

Came up again in http://musescore.org/en/node/45031

Well, I'm definitely not a Japanese user, but I tried with Google Japanese Input on my laptop.
I was able to insert Japanese characters in the title text field in the wizard, and also in other texts fields (for example the headers and footers text fields in the Style...->General... menu) and these were maintained also after save and reload.
But if I double click a text in the score, Japanese characters cannot be inserted. There seems to be some sort of "out-of-focus" behavior, see the video here: http://musescore.org/en/node/42346#comment-214386
This happens for all texts directly accessed from the ScoreView, e.g. title, composer, lyrics, texts in frames, et cetera.

See also the other comments by Shoichi in the same thread.

I tested it at MuseScoreNightly-2015-02-17-1109-db79435.

OS: Windows8.1(64bit)
IM: Google Japanese IME, Microsoft Japanese IME. (both)

Entering Japanese Characters(String) to TextBox in New Score Wizard is OK, works fine.

It seems that the problem is occurs when entering on the score sheet.
My situation is similar to ABL's report.　Conversion window is not appear. Rarely appearing or flickering.
https://www.screenr.com/0WzN
http://musescore.org/en/node/42346#comment-214386

Summarize of my test result:
1/
New Score Wizard -> OK.

2/
Double clicking at title, composer, lyric etc. on the score sheet, and then Entering -> NG.

3/
http://musescore.org/en/node/42346#comment-214006
"Add -> Text -> Title" is NG. it became same situation as 2.

Thank you for the test.
So now we know that Qt Widget are ok with the microsoft or google input method.
In db79435, there is no way to enter japanese character in text element in the score.

Werner did some changes in e7591d1d63. Now it's possible to enter japanese characters but in a completely "blind" way. I can for example double click a title, press S and E (with microsoft input method on, hiragana) and get a japanese character once I exit the text edit mode. I don't see the list UI displayed on normal widget, and I don't see any characters in the text before exiting text edit mode.

I confirm lasconic's tests also on my laptop with Google Japanese Input under Windows 8.1.
I can see the list UI and I can navigate or click one of the options. After text input, the string is not updated (even when pressing the spacebar); however I found that if you press the right arrow the displayed text is updated without exiting text edit mode. So the sequence is: double-click the text, digit the characters and possibly select the desired character from the dropdown list, press enter to confirm, press right arrow to update the displayed text.
Windows 8.1, commit d94de6552

I confirmed it , too. at MuseScoreNightly-2015-02-18-1308-e7591d1.
The result is the same as ABL's report.
Although it is a little unnatural, but Japanese entering is now possible.
The trigger for text update was also works by operation of IM off as well as the right arrow key.

If possible:

The position of list UI for conversion candidate selection will changed dramatically during key inputting via IM.
It is unnatural and inconvenient.
It is different from the behavior of other many Japanese application software.
To improve this, the following functions(methods, slots, signals...) of QInputMethod class is useful or related?

http://doc.qt.io/qt-5/qinputmethod.html

keyboardRectangle(), keyboardRectangleChanged(), show(), update(),... .

Here is an interesting article http://www.kdab.com/qt-input-method-depth/

I am a user of Musescore version: 2.0.3, revision: 3c7a69d under Microsoft Windows 10.
There is a minor problem with inputting text in Korean characters.
When creating a new score, text inputs for Title, Subtitle, Composer and Lyricist etc. exhibit no problem whatsoever just as using Microsoft Word. But the problem shows up only after finishing the new score setup and start entering or editing Korean texts, and that, only with a few specific characters. Let me explain.

Each Korean character consists of a combination of a consonant and a vowel, or a consonant and a vowel and a consonant, forming a syllable. So each Korean character requires 2 or 3 key-strokes ('consonant-vowel' or 'consonant-vowel-consonant'). Two(2) of consonants (They are double consonants, 'ㄲ' and 'ㅆ') and two(2) of vowels ('ㅒ' and 'ㅖ') require 'SHIFT+ a
key ('r', 't', 'o' and 'p' respectively)'. Any character that ends with one of those four(4) will not be entered correctly, instead, only the last stroked key entry will be entered. For example, if I want to enter '예', I would key in 'ㅇ' - 'ㅖ', that is, 'd' - 'SHIFT+p' in sequence. In this case, I get 'ㅖ' instead of '예'. Another example is; if I want to enter '있', I would key in 'ㅇ' - 'ㅣ' - 'ㅆ', that is, 'd' - 'l' - 'SHIFT+t' in sequence. In this case, I get 'ㅆ' instead of '있'. Whenever the last key is combined with SHIFT key, previous key entry is discarded and only the last key entry will be entered.
However, those specific characters are not so many, I improvise by entering required characters in an empty box (eg. copyright box) during new score setup, and copy and paste them where needed.
Another minor problem is; the key entries are temporarily held in abeyance before constructing a whole character, and Microsoft input method IME is intelligent enough to know if one character is completed. For instance, if you leave the text entry session (eg. click NEXT), the last entry should be taken as the last key stroke of the character being entered. But Musescore discards the previous key strokes in abeyance, loosing the last character fully keyed in.

Hope my description of the problem be clear and understandable.

And you are volunteering to fix this? If not better unassign yourself from this issue.

@Kyung Sup Lee Input for double consonant in Korean should be fixed in MuseScore 2.1. The version is not released but we offer nightly builds. See https://musescore.org/en/download#Nightly-versions It would be great if you could install a nightly and test it for Korean text input.

Is there anything that needs to be done for this issue?

I installed the Window's Simplified Chinese Input when I was testing the supplemental unicode support (although I think most simplified is handled by basic unicode). I seem to be able to input simplified chinese into every field。 Windows IME handles the translation from pinyin (in the case of chinese input) to Unicode, and musescore seems to be displaying and handling the simplified chinese properly.

Yes, the positioning of the input method frame in Japanese could be better.
For Korean, I believe we are good but I would prefer to have confirmation from a korean speaker.
The problem described by knoike as "After text input, the string is not updated (even when pressing the spacebar)" is solved I believe.

on 2.1dev I'm able to type Hiragana and it displays fine. I notice that windows has a little cloud predictor window popup at the bottom center of MuseScore's window...is that what you are reffering to? There seems to be quite a few different input methods in Window's IME dock menu... Is there an issue report you can point me to?

I'm Japanese.
It is CJK related problem so I also tested it at MuseScoreNightly-2017-02-23-2229-2.1-f30d2ad.

The problem described by knoike as "After text input, the string is not updated (even when pressing the spacebar)" is solved I believe.

I confirmed it better than previous ver. .
This problem seems to be mostly solved except some shortcut key bind is conflicted.
If these shortcut key is used in the while entering characters via IM, during inputted text is disappear(may be deleted).

(example for conflicted shortcut key)
Ctrl-i:
in MuseScore: Apply "Italic font" to selected string.
in IM: Decide "KATAKANA string" to during inputting string.

There may be other conflicts. (Ctrl-u, Ctrl-p,... .)
I think that Japanese peoble often use Ctrl-i for KATAKANA and Ctrl-u for HIRAGANA, and so on.

I think better that shortcut key for MuseScore is ignored or disalbed while entering characters via IM.

Thanks...I do notice the string disappearing. I see it disappear the moment that I press Ctrl (without pressing a subsequent letter to complete the command).

Pressing F2 (or any other F-key) will also kill the string.

But Shift or Alt don't seem to kill the string.

So as you say the "key bind is conflicted". But I'm trying to wonder how exactly the conflict occurs...

I also notice that if I type japanse, then press spacebar, then type some more japanse, that only the most recent portion of text after the last spacebar is killed.

Capslocks kill it too. Also for some reason now, the Alt is killing it too. I don't know why it wasn't earlier.

I'm noting that QtCreator 4.1.0 on Windows 10 does NOT have this bug. That means that this is not an inherent problem with Qt. I also notice that the Window's Cloud prediction popup displays right below the text I'm inputting in QtCreator (unlike musescore where the prediction popup displays below the ScoreView).

I'm noting that this string kill glitch is not present in the Plugin editor:

Nor in the NewScore wizard input text boxes:

And also you can see the windows cloud predictor popup is correctly displayed immediately below the text input...

So this issue is probably specific to ScoreView...

Yes, as you know now, the Text element is entirely custom in MuseScore while the input controls in the new score wizard, in the plugin editor or in Qt are all Qt Widget based and so inherits from Qt IME handling. The Text element in the ScoreView uses a lower API for performance reason, but they lack all the niceties of the Widget based text. It's not limited to IME, we had to reimplement copy/paste, the whole cursor navigation system and we don't have undo/redo either.

Regarding Ctrl, Alt etc... killing the IME, we had a similar problem with Shift in Korean. I fixed it here https://github.com/musescore/MuseScore/commit/159fa41a9850ac30672ab2421…
Maybe we should do the same with all pure modifier keys?

So this issue is probably specific to ScoreView...

Yes, I think so. (Previously, as I reported)

https://musescore.org/en/node/43681#comment-219911

It seems that the problem is occurs when entering on the score sheet.

Actually this seems to be fixed in 3.0-dev 6c36ccc ...I'm just testing it out now... So something must have changed between 2.1-dev and 3.0-dev...

I don't know if there is a specific commit responsible for fixing this...it which case it should probably go into 2.1, or maybe this is something to do with Qt libraries that have been updated for 3.0?

I don't think we did anything special in 3.0, so it must be Qt 5.6. Which problem specifically is fixed?

The problem that seems fixed in 3.0-dev (apparently by Qt 5.6) is the unintentional killing of the string currently being inputted when the user pressed Control/Alt/Function or another special key. Maybe a japanese native speaker could test out a 3.0 nightly to verify this.

There is still the minor issue of the cloud predictor popup displaying below the score view instead of immediately below the text cursor.

Actually this seems to be fixed in 3.0-dev 6c36ccc

Maybe a japanese native speaker could test out a 3.0 nightly to verify this.

Is the "3.0-dev 6c36ccc" "MuseScoreNightly-2017-02-23-1650-master-6c36ccc" ?

I also tested it.

When I Ctrl-i pressed, the inputted text via IM is *not* disappear and *not* deleted.
Its key sequence was not worked for IM and worked for MuseScore. Italic font mode was set.

Although it is a slightly unnatural, this is a better behavior than "MuseScoreNightly-2017-02-23-2229-2.1-f30d2ad".

If possible,...
key sequence while inputting characters via IM(during IM status is ACTIVE),
do not passthrow it over IM to MuseScore.

Is the "3.0-dev 6c36ccc" "MuseScoreNightly-2017-02-23-1650-master-6c36ccc"

Yes.

When I Ctrl-i pressed, the inputted text via IM is *not* disappear and *not* deleted.
Its key sequence was not worked for IM and worked for MuseScore. Italic font mode was set.

I'm verifying that I experience the same behavior on that 3.0 master.

If possible,...
key sequence while inputting characters via IM(during IM status is ACTIVE),
do not passthrow it over IM to MuseScore.

Out of curiosity, I tried what happens when I type japanese into QtCreator. QtCreator seems to do the desired thing when press Ctrl-i...it cycles through different japanese words. So that answers the question that Qt is not at fault. I also tried typing japense text in the New Score wizard, and I am able to use Ctrl-i to cycle through different japanese words. So it seems ScoreView class is at fault, and not the top level mscore class.

I'm reading some Qt literature about this... I'm also going to step through the debugger at ScoreView::event(QEvent* event) and inspect the state of event when pressing a special key to see what happens...I'll report back one I recompile musescore master....

I'm trying to search the Qt docs to see if there is some flag to indicate that an IME is being used, and what language it is, but I haven't found that yet. Cause we would only want to disable the keys for the particular languages whose IME uses those keys.

Ok, so I placed a breakpoint right inside the if (event->type() == QEvent::KeyPress && editObject) block of ScoreView::event(), and I'm reporting that breakpoint is not caught while typing Japanese characters. But the moment that I press Ctrl, that breakpoint is caught.

I guess I need to implement http://doc.qt.io/qt-5/qobject.html#eventFilter for class ScoreView... Actually no...reading the docs it seems that that just eats the event...I need to propagate the event upwards...I'll try event->ignore().

Also, I should ask what are the different Japanese specials key commands that musescore needs to ignore?

Ok. I'm able to intercept the Ctrl here: https://github.com/ericfont/MuseScore/commit/6406013e527a9ba08707e5214a…
and that will ignore it, so that it gets set upwards to the IME.

Now I need to figure how to query http://doc.qt.io/qt-5/qinputmethod.html#details to determine if using Japanese IME...

Fixed in branch master, commit 4a9a216bf8

fix #43681 ScoreView text edit ignore Ctrl/Shift/Alt/Caps for Win Japanese IME

If currently typing Japanese Script, MuseScore ScoreView will ignore these key events, so that they will instead propagate upwards to Windows' Input Method to handle.

Fixed in branch master, commit 200889f68e

Merge pull request #3026 from ericfont/43681-JapIME-ignoreSpecialKeys

fix #43681 ScoreView text edit ignore Ctrl/Shift/Alt/Caps for Win Japanese IME

Fixed in branch 2.1, commit 3ad46c7696

fix #43681 ScoreView text edit ignore Ctrl/Shift/Alt/Caps for Win Japanese IME

If currently typing Japanese Script, MuseScore ScoreView will ignore these key events, so that they will instead propagate upwards to Windows' Input Method to handle.

@knoike, I've told musescore to *ignore* CTRL, SHIFT, ALT, & CAPSLOCK Key Events while typing in Japanese script in a text element on Windows so that the IME gets those Key Events. Please try the following Nightly:

http://ftp.osuosl.org/pub/musescore/nightlies/windows/MuseScoreNightly-…

and tell me if you are able to use all special Japanese Input Method Commands such as Ctrl+I.

I reopen until confirmation.

I am downloading now. While waiting for it... ．

tell me if you are able to use all special Japanese Input Method Commands such as Ctrl+I.

Not limited to Japanese IM,
these special commands (key sequences) is customizable by user,
so if specific key sequences is filtered, It may not be perfect.
　
　
Best solution(as you know):
While IM status is active, Pass all key events to IM.
　
Not Best but Better solution(you are working now);
Filter key events, to pass specific key sequences for IM.
I feel this is ad hoc.
　
　
Based on the above,
Parhaps, I may be able to tell you all of default key sequence of majar two Japanese IM, Google Japanese IME and Microsoft Japanese IME.
Wait a moment. I am investigation now.

Are you suggesting that basically for anything other than LatinScript?

I don't notice an issue with simplified chinese (which doesn't have any special other input methods other than pinyin) nor with hangul (korean) on this 3.0nightly. I really would like some official documentation from Microsoft specifying the possible input shortcuts, but I couldn't find any. Is it common for people to define their own shortcuts with any ordinary keys? I guess if wanted to do for all IM that have pre-edit strings, then would simply remove

QGuiApplication::inputMethod()->locale().script() == QLocale::JapaneseScript

in which case scoreview would always ignore key events if text->cursor()->format()->preedit() is true.

What is "script" you mean?

and

Do you understand what kind of software IM is?

When I said script, I'm referring to Qt's abstraction for Input Methods across all different operating systems, which has a "locale" property:

http://doc.qt.io/qt-5/qinputmethod.html#locale-prop

Which can have the following different Scripts:

http://doc.qt.io/qt-5/qlocale.html#Script-enum

JapaneseScript and LatinScript are two of the possible different scripts that the QInputMethod class exposes via its "locale" property.

I believe IM stands for "Input Method". I have the Windows IME installed for Simplified Chinese, Korean, and Japanese. I've used the Simplified Chinese IME in the past a bit, so I'm a little familiar with their operation.

Thanks.
I have not seen the source code at all, so I do not know the story about "script".

Are you able to successfully press Ctrl+i to cycle through Japanese spellings while typing?

I have not seen the source code at all, so I do not know the story about
"script".

I apologize, sometimes I don't know what is the background of the person I am talking to online! I need to be careful to avoid using Qt-specific coding terminology!

I believe IM stands for "Input Method". I have the Windows IME installed for Simplified Chinese, Korean, and Japanese. I've used the Simplified Chinese IME in the past a bit, so I'm a little familiar with their operation.

Thanks. You are mostly right.

Is it common for people to define their own shortcuts with any ordinary keys?

I think "Yes". Because It is a modification(change), not a definition of all.
Also, the user can choose from several preset keymaps, as you like.

There are a few IM software for Japanese.
Generally, the user chooses as you like.
Default IM is Microsoft IME, but Google IM is used, too.
I think that this situation is the same in other countries using IM software.

So, I said as below;

Not Best but Better solution(you are working now);
Filter key events, to pass specific key sequences for IM.
I feel this is ad hoc.

Are you able to successfully press Ctrl+i to cycle through Japanese spellings while typing?

This cyclic behavior is Microsoft IME only.
In the case of Google IM, decide to KATAKANA string.

　
I tested it at MuseScoreNightly-2017-02-25-1449-master-200889f.

　
Microsoft "Japanese" IME: works fine!
Google "Japanese" IM: works fine!

　
It seems to good modification.

Let's mark it fixed then

Is this issue really fixed? for Chinese and Korean too ?
I tested just only "Ctrl-i" behavior in Japanese environment, and reported "works fine".
I do not know other environments.

Please add Chinese for test, too.
There may be a few other IM for Chinese.

I want to emphasize that my PR was only intending to fix Japanese on Windows IME on 3.0 by having this if statement make musescore's scoreview ignore Key Events on Windows when the pre-edit string is not completed:

#ifdef Q_OS_WIN
      if (editObject->isText()) {
            Text* text = static_cast(editObject);
            if (text->cursor()->format()->preedit() && QGuiApplication::inputMethod()->locale().script() == QLocale::JapaneseScript &&
                ((key == Qt::Key_Control || (modifiers & Qt::ControlModifier)) ||
                 (key == Qt::Key_Alt || (modifiers & Qt::AltModifier)) ||
                 (key == Qt::Key_Shift || (modifiers & Qt::ShiftModifier)) ||
                 (key == Qt::Key_CapsLock))) {
                  return; // musescore will ignore this key event so that the IME can handle it
                  }
            }
#endif

https://github.com/musescore/MuseScore/commit/200889f68ed98e6336fb2f671…
I haven't tested OSes other than windows. If you wanted that to apply to all OSes, just remove the #ifdef. And if wanted to apply to all languages, then would remove the following condition:

"QGuiApplication::inputMethod()->locale().script() == QLocale::JapaneseScript"

And if wanted to have the scoreview text input ignore all key events while in the pre-edit string is not completed, then would remove the rest of that if statement other than the preedit() condition.

Even without my PR, I'm able to type Simplified and Traditional Chinese with both Google and Microsoft IME into musescore text boxes on 3.0-dev, and haven't run into problems, based on my limited understanding. I'm able to switch between Chinese and English with Shift (with google) or via Win-Space (with Windows) , but I don't think. Hangul seems to type ok in 3.0, based on my limited understanding, in that I can type consonants and vowels to form characters and can complete words in musescore. As far as using the spacebar to advance to next note with lyrics, it seems simplified chinese is working easily for me, but I have trouble advancing with space on japanese or korean (but then again I don't really know them).

But I want to emphasize as I mentioned in comment #21, there is something with the upgraded Qt libraries in 3.0 that apparently fixed the string kill glitch:

The problem that seems fixed in 3.0-dev (apparently by Qt 5.6) is the unintentional killing of the string currently being inputted when the user pressed Control/Alt/Function or another special key

Qt must have fixed something before Qt 5.6. But that means that this issue probably can't easily be fixed in 2.1, unfortunately. I'm just trying out the 2.1 build, and unfortunately that Ctrl string kill error is still present on japanese, even though this if statement should be telling scoreview to ignore the Ctrl event.

So in summary, all my fix really handles for sure is the ability to use Ctrl+i (and any IME operations with Ctrl, Alt, Shift) while typing a japanese preedit string on 3.0. But the if statement could be easily modified to say which Scripts will ignore what keys on what OS. I'm also wondering if this if statement should be exposed to preferences.ini, so that it can be easily modified.

But it may be worth asking native speakers to try the 3.0 nightly, so we know what if anything needs to be done for Korean and Chinese.

Well, this issue is explicitly for CJK on windows, and that has been confirmed to be fixed.
So I'm not quite sure why to keep it active?

I've fixed the positioning of the Input Method popup window to appear just below the text's cursor: https://github.com/musescore/MuseScore/pull/3032

Here's how it looks with Window's Simplified Chinese IME on 3.0 master:

I've also verified it working for Windows Japanese and Google's Chinese & Japanese on Windows. Windows Korean doesn't have the popup (unless there is a feature I need to enable?), but I've only tested on 3.0 master because recompiling for 2.1 takes forever on my machine. It should position the same on any OS or IME if Qt's code is properly abstracting the Input Methods. (I expect lasonic will test this on his Mac, at least).

I see this is still marked as "active". Maybe after this gets merged then we can ask for native speakers to verify, and then we can mark this issue as "fixed" (unless there are any other outstanding issues).

I tested on macosx and it's now merged in master and in 2.1. Let's keep this issue active in case we manage to solve the modifier keys issue on 2.1 too.

I'll look into this 2.1 pre-edit string kill glitch now... I'm noticing that even though pressing Ctrl causes the predit string to disappear, however, the IME is still present and still has the predit string in it's own memory, because I am able to continue to add characters to the predit string and see the IME's predicting strings update, and I'm able to select one of the IME predictions to complete the string.

I made a 2.1-specific fix "Do not rely on QInputMethod::locale() for CJK test" https://github.com/musescore/MuseScore/pull/3034

commit message:

Previous fix for #43681 relied on QInputMethod::locale() to return the current script that the InputMethod is set to, and that worked fine for 3.0, but not 2.1.

According to debugger in 2.1, Qt was not properly updating the locale when change languages, since is always returning 0 (AnyScript). Without an easy way to determine if Japanese is being used, the simplest solution is to have MuseScore simply ignore all Control/Alt/Shift/CapsLock while a pre-edit string exists.

This also somehow indirectly fixes the string kill glitch that was present in 2.1 when pressing these modifiers for all languages with pre-edit strings. But I'm not entirely sure why that bug existed in the first place in 2.1, but my best guess is that Qt fixed something between 5.4 and 5.6 related to this.

I also discovered on 2.1 that the slot MuseScore::inputMethodLocaleChanged() (which I added in my previous PR for debugging purposes) is not ever being called when I change languages. Maybe this is related to https://codereview.qt-project.org/#/c/138327/ or https://codereview.qt-project.org/#/c/160618/ or https://bugreports.qt.io/browse/QTBUG-48772 ...but regardless I think this is the simplest solution.

Anyway, I'd recommend that this get merged into 2.1 even though it is a bit of a "hack" and then can ping CJK users to test the 2.1 nightly that results.

The latest PR from @ericfontainejazz is merged. Thanks to his work, I believe we have now a pretty good support of CJK input methods in MuseScore 2.1 and master. Tests of 2.1 nightlies are very welcome. All fixes are in MuseScore 2.1 nightlies starting from d4282933

The one thing I haven't tried to figure out is how to advance to the next note when typing Japanese lyrics. But I can't think of a simple solution, because both the Win & Google Jap IME will grab the spacebar keystroke. So the only advice I have is to switch to latin input in order to press spacebar to advance to the next note. But any good ideas, I'm open. Maybe we need to allow musescore to define a different keystroke for advancing to next note, to facilitate Japanese lyric inputing. Note that Korean and Chinese lyrics don't have this problem.

I tweeted "Looking for testers for CJK Inputting."

https://twitter.com/knoike/status/839165478685696001

I was able to do that operation to press [→(right arrow)] / [←(left arrow)] key.

ex./

Ctrl-l (for start lyric inputting)
do [Enter] [right arrow] re [Enter] [right arrow] mi [Enter] [right arrow]... ．

thanks knoicke, pressing [Enter] [right arrow] seems to work...I'm guessing that's because Enter will finalize the pre-edit string.

Is there still some issue with #92591: Problem with Hangul setting, though?

Thank you, Thomas.
It is OK.

Automatically closed -- issue fixed for 2 weeks with no activity.