I tested on Windows with the latest nightly version.
Rev: MuseScoreNightly-2018-06-20-0941-master-dff4fcc
OS: Windows10(64bit)
IM: Google Japanese IM
Preference -> General -> Language -> "システム言語" (System Language(ja_JP))
Serious problem:
MuseScore crashed when I pressed special key sequence for Japanese IM.
example of key sequence for crash reproduction:
double clicking at title on score sheet
Japanese IM On
key press: a
key press: ctrl-i (Crash at this time)
ctrl-i is used to convert inputting characters to full-width katakana.
Similarly, these keys pressing also crashed.
ctrl-u (convert to full-width hiragana)
ctrl-o (convert to half-width katakana)
ctrl-p (convert to full-width alphabet)
The above key sequences are reproducible procedures, but it seems that there are other cases of crashing during key inputting via IM.
I encountered a crash several times while using IM on/off, F6, F7, F8, and F9 key.
Improved, but CJK characters are still not working well when I type lyrics or texts on Mac.
OS: macOS High Sierra (10.13)
Arch.: x86_64, MuseScore version (64-bit): 3.0.0.19499
revision: 0526317
CJK Characters are not shown till pressing ENTER.
These should appear immediately after typing letters as like MuseScore ver 2.3.2.
Attached two file, how behaving in ver3 beta and ver2.3.2
> So, it works, but appearance of the symbols is different, isn't it?
No. Although he(kazuma yamamoto) answered "yes", I think he made a misunderstanding your(Anatoly-os) reply.
The displayed symbol itself is correct as he expects, not different.
I think that he reported a problem about "behavior" not "appearance" of text during key inputting via IM.
That situation is "it works, but not very fine."
OS: Windows 10 (10.0),
Arch.: x86_64,
MuseScore version (64-bit): 3.0.0.4133,
revision: 0526317
IM: Google Japanese Input
> Problem 1:
> Inputting text via IM is not displayed(not appeared) until press [Enter] key or [→] key.
It occurred.
> Problem 2:
> The conversion candidate selection window of IM is not appear.
It was displayed, but it was displayed at a different position from the expected position.
I think improvement is necessary.
It is better to locate that window near the text cursor, same as in the version 2.3.2.
ok, so I've installed the chinese input method, and see that I can input chinese text, but as the previous comment of this thread illustrates, the input method window does not appear directly under the cursor (as I recall that problem before) and the inputted roman alphabet characters user inputs don't appear at all while typing...only appear once press spacebar (causing the input method to complete the conversion), and then see the resulting chinese text in musescore.
I think having the IME appear directly below cursor is more important than having intermediate latin appear, so I will focus on that first...
I've also just built 3.0 master on Arch Linux Mate with IBus input method, and found a similar problem with position of the input method popup window. While in windows the popup was below the score view, however in linux the popup appears somewhat in a random position on the scoreview. I can drag the input window around, however when i type a new letter on keyboard, the input window jumps back to its original random position.
So there is probably something in the Qt wrapper to dictate exactly where whatever OS input method popup appears.
Thank you very much for solving the problem of CJK input !
Even though I don't have any programming knowledge, I can imagine it takes you a lot of works.
I'm so much appreciate.
One thing it's differ from Windows situation.
On macOS (10.13 High Sierra),
The input method window (The conversion candidate selection window) does NOT appear at all.
@Jojo, I've updated my windows build to Qt 5.12 (and verified that I'm running 5.12 from Help->About Qt), but unfortunately the position of the input method is way out of place still.
doing debugging, added some qDebug messages for all the QInputMethod signals, and found that the Qt is getting notified when the text position is moved around, but the area rectangles (for inputMethodCursor, inputMethodAnchor, and inputMethodInputItemClip) are always have left=0, top=0, right=0, bottom=0. So I'll continue investigating...
I believed I've fixed the problems of the input method appearing in the incorrect position (underneath the scoreview) and sometimes getting disabled...see my PR fix: https://github.com/musescore/MuseScore/pull/4345
Also I don't know how all IMEs work for displaying pre-edit strings...I'm testing the Windows 10 IME but notice it doesn't display any pre-edit string...and musescore current master doesn't display pre-edit string either, so in that case user doesn't see any latin characters of pre-edit string while being inputted...but I think other IMEs do display the pre-edit string in the IME...so I just don't know what the proper protocol musescore is supposed to follow...but as it is my PR above isn't concerned with that question, as it just fixes IME window positioning.
I’m so much appreciate for your many efforts..
Thank you very much!
I’ve just installed Google Japanese IM on Mac,
And here also doesn’t display pre-edit string, and the input method window is not directly under the cursor.
I tested MuseScoreNightly-2018-12-08-0922-master-a9203cb.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4346, revision: a9203cb
IM: Google Japanese IM and Microsoft Windows 10 IME
The problem about "the IM window position" is not solved,.
(although it's position was changed.)
(to re-emphasize for anyone paying attention...this PR only fixes cursor position for Win...there is still an issue on my linux machine. And I haven't attempted to fix display of pre-edit strings...I'll look into this now...)
Oh, I'm sorry, I misunderstood that your PR has already been merged to master branch and reflected to nightly build.
I tested your pointed version you builded, MuseScoreNightly-2018-12-07-2116-master-00abf80.
It seems that the cursor positioning(the IM window positioning) issue is fixed!
ericfontainejazz's version MuseScoreNightly-2018-12-07-2116-master-00abf80:
The related problem on Linux I described I can't seem to figure out though...that almost seems like a problem with the linux input editor, or even possibly Qt...so I'm not going to worry about that.
I downloaded your build MuseScoreNightly-2018-12-09-1518-master-d3b8501, and tested.
It seems that the problem about pre-edit string is also fixed!
Great!
Previously the InputMethod would appear at the bottom center of ScoreView. This is because someone's previous commit broke the main if statement in ScoreView::inputMethodQuery such that it would always fail. That resulting in undesired default fallback behavior which caused the cursor to appear below the bottom of the ScoreView, rather than immediately below the TextBase element that user wants to input to. Fixing that if statement allows my original code to work again.
Additionally I noticed sometimes input editor would fail to work after unselecting the text element. Turns out that was because the query for Im::Enabled was set to isEditing(). I found by always returning true for that case for TextBase objects, that resulted in the InputMethod to always work on subsequent edits.
There was also a problem with the pre-edit string not appearing while inputting, which was a result of forgetting to update the score after layout when inputting each character of pre-edit string.
Also added dummy slot functions for all signals that InputMethod can produce...right now just outputting debug messages. In the future might end up responding to those signals, although for now leaving as empty skeleton functions.
Comments
Critical is reserved for crashes and corruptions
In reply to Critical is reserved for… by Jojo-Schmitz
Critical to normal
OK!
kazuma yamamoto's report is on Mac environment, so I tested on Windows.
Rev: MuseScoreNightly-2018-03-28-0907-master-49068cc
OS: Windows10(64bit)
IM: Google Japanese IM
Although it is not very good, I could enter CJK characters via IM.
It seems it is degrade to the states before ericfontainejazz's fix.
https://musescore.org/en/node/43681#comment-662596
Problem 1:
The positioning of the input method frame.
Problem 2:
Special key sequence for IM, 'Ctrl-', 'F7', 'F8', 'F9' and so on is stolen by MuseScore.
https://musescore.org/en/node/43681#comment-663911
relates to #272131: [EPIC] Text editing issues
cjk character input should work in latest versions
In reply to cjk character input should… by [DELETED] 3
Thank you!
But CJK characters are still not working for my environment, MacOS high sierra 10.13.5
I tried the ver 3.0 revision 6b8a646
I could only test on a linux machine. MacOs seems to be special.
Can someone test this on windows?
In reply to I could only test on a linux… by [DELETED] 3
OK, I'll ask it to Windows users.
In reply to I could only test on a linux… by [DELETED] 3
I tested on Windows with the latest nightly version.
Rev: MuseScoreNightly-2018-06-20-0941-master-dff4fcc
OS: Windows10(64bit)
IM: Google Japanese IM
Preference -> General -> Language -> "システム言語" (System Language(ja_JP))
Serious problem:
MuseScore crashed when I pressed special key sequence for Japanese IM.
example of key sequence for crash reproduction:
double clicking at title on score sheet
Japanese IM On
key press: a
key press: ctrl-i (Crash at this time)
ctrl-i is used to convert inputting characters to full-width katakana.
Similarly, these keys pressing also crashed.
ctrl-u (convert to full-width hiragana)
ctrl-o (convert to half-width katakana)
ctrl-p (convert to full-width alphabet)
The above key sequences are reproducible procedures, but it seems that there are other cases of crashing during key inputting via IM.
I encountered a crash several times while using IM on/off, F6, F7, F8, and F9 key.
OK, here is the another situation from Windows user.
He tested Japanese inputting on Windows 8.1.
and he even can't input any Japanese, then crash.
Using inputting method of Microsoft IME and ATOK 2015
In reply to OK, here is the another… by kazuma yamamoto
Improved, but CJK characters are still not working well when I type lyrics or texts on Mac.
OS: macOS High Sierra (10.13)
Arch.: x86_64, MuseScore version (64-bit): 3.0.0.19499
revision: 0526317
CJK Characters are not shown till pressing ENTER.
These should appear immediately after typing letters as like MuseScore ver 2.3.2.
Attached two file, how behaving in ver3 beta and ver2.3.2
So, it works, but appearance of the symbols is different, isn't it?
In reply to So, it works, but appearance… by Anatoly-os
Hello Anatoly-os
First of all, Thank you very much for your all hard working for ver 3!
I'm very very excited :)
>Yes, it works, and true, appearance of the symbols is different.
Way of CJK Appearance in ver2.3.2 is better than ver3
You're welcome :) thank you for being here and using MuseScore!
Gotcha, let's see what we can do.
In reply to You're welcome :) thank you… by Anatoly-os
It's my pleasure!
Hope it will solve.. Ver 3 is really AWESOME ! Thank you!
In reply to So, it works, but appearance… by Anatoly-os
> So, it works, but appearance of the symbols is different, isn't it?
No. Although he(kazuma yamamoto) answered "yes", I think he made a misunderstanding your(Anatoly-os) reply.
The displayed symbol itself is correct as he expects, not different.
I think that he reported a problem about "behavior" not "appearance" of text during key inputting via IM.
That situation is "it works, but not very fine."
That situation is very similar to this:
https://musescore.org/en/node/43681#comment-220561
kazuma yamamoto's report is a Mac version behavior, but it is very similar to the past Windows version states.
Problem 1:
Inputting text via IM is not displayed(not appeared) until press [Enter] key or [→] key.
Problem 2:
The conversion candidate selection window of IM is not appear.
At later, I will also test on Windows version, and try to report that state.
(Edited: to the correct URL.)
In reply to > So, it works, but… by knoike
Yes! That’s the thing I wanted to explain, appearance is correct, what I expect.
But behavior is not good as ver.2.3.2
Thank you!
In reply to > So, it works, but… by knoike
I tested this issue by "for Windows Version".
OS: Windows 10 (10.0),
Arch.: x86_64,
MuseScore version (64-bit): 3.0.0.4133,
revision: 0526317
IM: Google Japanese Input
> Problem 1:
> Inputting text via IM is not displayed(not appeared) until press [Enter] key or [→] key.
It occurred.
> Problem 2:
> The conversion candidate selection window of IM is not appear.
It was displayed, but it was displayed at a different position from the expected position.
I think improvement is necessary.
It is better to locate that window near the text cursor, same as in the version 2.3.2.
Ver. 3.0 BETA (3.0.0.4133)
![V3_for_Win_4.png]( "V3_for_Win_4.png")
Ver. 2.3.2
![V2_for_Win.png]( "V2_for_Win.png")
ok, so I've installed the chinese input method, and see that I can input chinese text, but as the previous comment of this thread illustrates, the input method window does not appear directly under the cursor (as I recall that problem before) and the inputted roman alphabet characters user inputs don't appear at all while typing...only appear once press spacebar (causing the input method to complete the conversion), and then see the resulting chinese text in musescore.
I think having the IME appear directly below cursor is more important than having intermediate latin appear, so I will focus on that first...
I've also just built 3.0 master on Arch Linux Mate with IBus input method, and found a similar problem with position of the input method popup window. While in windows the popup was below the score view, however in linux the popup appears somewhat in a random position on the scoreview. I can drag the input window around, however when i type a new letter on keyboard, the input window jumps back to its original random position.
So there is probably something in the Qt wrapper to dictate exactly where whatever OS input method popup appears.
Hello ericfontainejazz
Thank you very much for solving the problem of CJK input !
Even though I don't have any programming knowledge, I can imagine it takes you a lot of works.
I'm so much appreciate.
One thing it's differ from Windows situation.
On macOS (10.13 High Sierra),
The input method window (The conversion candidate selection window) does NOT appear at all.
Maybe the brandnew Qt 5.12.0 (officially released today) helps here?
In reply to Maybe the brandnew Qt 5.12.0… by Jojo-Schmitz
@Jojo, I've updated my windows build to Qt 5.12 (and verified that I'm running 5.12 from Help->About Qt), but unfortunately the position of the input method is way out of place still.
doing debugging, added some qDebug messages for all the QInputMethod signals, and found that the Qt is getting notified when the text position is moved around, but the area rectangles (for inputMethodCursor, inputMethodAnchor, and inputMethodInputItemClip) are always have left=0, top=0, right=0, bottom=0. So I'll continue investigating...
I believed I've fixed the problems of the input method appearing in the incorrect position (underneath the scoreview) and sometimes getting disabled...see my PR fix: https://github.com/musescore/MuseScore/pull/4345
any CJK folks have requests about what IME's to test (I only have linux & win dev environment setup at the moment)...I know there used to be a popular google one, but when I go to https://www.google.com/inputtools/services/features/input-method.html and click the "Windows" link (https://www.google.com/inputtools/windows/) I get a 404...so sounds like google discontinued their Windows IME.
Also I don't know how all IMEs work for displaying pre-edit strings...I'm testing the Windows 10 IME but notice it doesn't display any pre-edit string...and musescore current master doesn't display pre-edit string either, so in that case user doesn't see any latin characters of pre-edit string while being inputted...but I think other IMEs do display the pre-edit string in the IME...so I just don't know what the proper protocol musescore is supposed to follow...but as it is my PR above isn't concerned with that question, as it just fixes IME window positioning.
In reply to any CJK folks have requests… by ericfontainejazz
This is the Google Japanese IM I use.
https://www.google.co.jp/ime/
(I thins that the tool you pointed out is "for online apps" not "for desktop apps".)
In reply to any CJK folks have requests… by ericfontainejazz
Yes, the problem 1 we reported about "pre-edit string" has also occurred in Windows 10 IME, not only Google Japanese IM.
Hello ericfontainejazz
I’m so much appreciate for your many efforts..
Thank you very much!
I’ve just installed Google Japanese IM on Mac,
And here also doesn’t display pre-edit string, and the input method window is not directly under the cursor.
I tested MuseScoreNightly-2018-12-08-0922-master-a9203cb.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4346, revision: a9203cb
IM: Google Japanese IM and Microsoft Windows 10 IME
The problem about "the IM window position" is not solved,.
(although it's position was changed.)
Google Japanese IM:
![MuseScore_GoogleIM_2018-12-08.png]( "MuseScore_GoogleIM_2018-12-08.png")
Microsoft Windows 10 IME:
![MuseScore_MS-IME_2018-12-08.png]( "MuseScore_MS-IME_2018-12-08.png")
(to re-emphasize for anyone paying attention...this PR only fixes cursor position for Win...there is still an issue on my linux machine. And I haven't attempted to fix display of pre-edit strings...I'll look into this now...)
Noike or Kazuma (or whoever wants to be a guinea pig), if you want to test out my PR on Win, it is at: https://ci.appveyor.com/api/buildjobs/i5wdpvrtl42r8tro/artifacts/MuseSc… ...and let me know if it fixes the cursor positioning issue.
In reply to (to re-emphasize for anyone… by ericfontainejazz
Oh, I'm sorry, I misunderstood that your PR has already been merged to master branch and reflected to nightly build.
I tested your pointed version you builded, MuseScoreNightly-2018-12-07-2116-master-00abf80.
It seems that the cursor positioning(the IM window positioning) issue is fixed!
ericfontainejazz's version MuseScoreNightly-2018-12-07-2116-master-00abf80:
![MuseScore_GoogleIM_2018-12-09_eric_ver.png]( "MuseScore_GoogleIM_2018-12-09_eric_ver.png")
:) Thanks for the confirmation. I'll try to get the pre-edit string working now...
Wow! great !
I can’t test it on Win though,
Looks (NOIKE’s atacthed file) the cursor positioning is fixed!
Thank you very much!
I believe I've fixed the problem of the pre-edit string not appearing...turns out the score was missing an update after each keystroke
The Win rebuild of my PR should happen in the next 30 mintues or so...in case NOIKE wants to test, just go to https://ci.appveyor.com/project/MuseScore/musescore/builds/20878795 and go to "Artifacts" and download the .7z
The related problem on Linux I described I can't seem to figure out though...that almost seems like a problem with the linux input editor, or even possibly Qt...so I'm not going to worry about that.
In reply to I believe I've fixed the… by ericfontainejazz
I downloaded your build MuseScoreNightly-2018-12-09-1518-master-d3b8501, and tested.
It seems that the problem about pre-edit string is also fixed!
Great!
I thank for your many efforts!
Windows10, Google Japanese IM:
![MuseScore_Google_IM_Good_2018-12-10.png]( "MuseScore_Google_IM_Good_2018-12-10.png")
Windows10, Microsoft Windows 10 IME:
![MuseScore_MS-IME_Good_2018-12-10 (1).png]( "MuseScore_MS-IME_Good_2018-12-10 (1).png")
Fixed in branch master, commit 11a754d6db
fix #269036 IME Cursor rect, enable, update
Previously the InputMethod would appear at the bottom center of ScoreView. This is because someone's previous commit broke the main if statement in ScoreView::inputMethodQuery such that it would always fail. That resulting in undesired default fallback behavior which caused the cursor to appear below the bottom of the ScoreView, rather than immediately below the TextBase element that user wants to input to. Fixing that if statement allows my original code to work again.
Additionally I noticed sometimes input editor would fail to work after unselecting the text element. Turns out that was because the query for Im::Enabled was set to isEditing(). I found by always returning true for that case for TextBase objects, that resulted in the InputMethod to always work on subsequent edits.
There was also a problem with the pre-edit string not appearing while inputting, which was a result of forgetting to update the score after layout when inputting each character of pre-edit string.
Also added dummy slot functions for all signals that InputMethod can produce...right now just outputting debug messages. In the future might end up responding to those signals, although for now leaving as empty skeleton functions.
Fixed in branch master, commit 9943f89ad5
Merge pull request #4345 from ericfont/269036-InputMethod-positioning
fix #269036 InputMethod Cursor rect & enable & update
ericfontainejazz
Sooo great!
I also tested the recent nightly build on Mac and it works as well !!
Literally, You saved our MuseScore life in the near future!
Thank you so much for all your works :)
:) and thanks for testing!
Automatically closed -- issue fixed for 2 weeks with no activity.