After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 737583 - Fix static placement of Chinese IME window
Fix static placement of Chinese IME window
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
unspecified
Other All
: Normal minor
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2014-09-29 12:26 UTC by Michael Bauer
Modified: 2014-10-02 23:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Untested patch (3.10 KB, patch)
2014-09-30 22:29 UTC, Michael Natterer
none Details | Review

Description Michael Bauer 2014-09-29 12:26:47 UTC
Tested with standard Pinyin IME on Mac. It should work by the user typing Pinyin, opening a suggestions window automatically and displaying the different suggestions and then inserting them.

This works in Gimp but what does not work well is the alignment. In other programs (tested Firefox and LibreOffice), the OS places the suggestions window 
near the cursor and moves the window along as you type. It cannot be manually repositioned (as far as I can tell).

In Gimp, the window appears, as do suggestions and they are inserted correctly. However, it insists on placing the suggestions window in the bottom left of the Gimp window and since I cannot reposition it (and would have to do so every time I type since it autocloses), it makes typing very annoying because my eyes have to keep jumping between the cursor area and the bottom left of the window.
Comment 1 Jehan 2014-09-29 13:14:09 UTC
As said on the mailing list, I can reproduce such a placement with ibus on Linux too. I believe it places the suggestion relative to the widget, which I think is the GimpCanvas in the case of a text in the canvas. When writing in other elements of GIMP though, for instance in some text field, or renaming a layer with Japanese, etc. the suggestion window is correctly placed (next to the text being inputted), likely because the containing widget is smaller.

We should check what kind of control over the IME suggestion windows we can have. This may be a GTK+ issue more than a GIMP issue (though there may be something to do in GIMP too to tell where the text cursor is placed, I don't know), since Input Methods are dealt automatically through GTK+ (--with-included-immodules configure option).

As also said on mailing list though, this is not high priority. It still works. Just it's not optimal. I'll have a look when I can make some time (but I will only be able to confirm any fix on the Linux side).
Comment 2 Michael Bauer 2014-09-29 13:36:55 UTC
Just re-tested using the current release and spotted an additional problem, in addition to the placement. In LO, when you type beijing the Latin characters [bei jing] are displayed until the user selects the required characters. In GIMP, you're flying blind i.e. you can't see what you typed. Which is a problem because if you mistype, you can't see where you mistyped or even how far back you need to delete.

I'm surprised this is not ranked higher priority, CJK is a big number of users...
Comment 3 Jehan 2014-09-29 14:03:20 UTC
> In GIMP, you're flying blind i.e. you can't see what you typed. Which is a problem because if you mistype, you can't see where you mistyped or even how far back you need to delete.

You don't see the western characters, but do you see the first suggestion in the target characters at least? Because that's what happens with ibus under linux. If I type 'a' with ibus-anthy on, I don't see 'a' but 'あ'. And the fact is that this is what I want. We have to see that non western-character users don't care at all about our characters. They only "bare" with them because they are not given the choice and all their keyboards come with prominent ASCII alphabet written on. But when they type, they just want to see their own native language on the screen when possible. And I can assure you, they don't need to see the western character on screen to know when they mistyped and to fix back.
Rather they need to see the target characters to go much faster, because most of the time, the first suggestion will be right (the first suggestion being statistically the most used), so a quick check allow them to go further without even bothering with the suggestion box.

Or are you saying they see *nothing* at all on screen under the cursor, neither western nor eastern characters. It is just blank until you select something? In this case, yes that is more annoying.

> I'm surprised this is not ranked higher priority, CJK is a big number of
users...

GIMP is made by volunteers. We work first on what we believe is more important. If some other dev swoops in and announces this is a major issue and wants to work on a patch for this, we will be happy of it and changing the priority. This is all about personal priorities.
There is no company, no share holders thinking for us and telling us what is priority. It does not mean we don't acknowledge issues, but we have to make our own priority list. So yes CJK users are big = big market (but we are not a company, again). And we'd be more than happy to accept CJK-using devs if they want to handle related issues. I believe I am one of the only current GIMP dev using regularly Asian languages (and when I say "regularly", that's not even that often anymore).

Also Input Methods are not utterly broken. From your report, I gather they are mostly working but simply not optimal.
Comment 4 Michael Bauer 2014-09-29 14:27:44 UTC
I realise these projects rely on volunteers but even so, within a pool of volunteers, priorities can be ... suggested. 

I'm not getting into a philosophical debate about the pros and cons of Kotoeri ;) I'm simply comparing the way it works elsewhere on OSX and the way it works in Gimp, anything else is not mine or indeed our problem!

When in Hiragana mode, it indeed automatically goes to Hiragana immediately with a vowel or, with a consonant, once you hit the vowel after the consonant. If Kotoeri finds a Kanji match, it will display this in addition to the Hiragana.

But you're mixing up Chinese with Japanese here, this is the Pinyin bug. Just tested again with OSX Pinyin input in Safari, there is displays the Pinyin AND the option of characters. Which is actually the most common way of displaying for Pinyin-esque entry methods.
Comment 5 Michael Natterer 2014-09-29 22:07:05 UTC
We don't call gtk_im_context_set_cursor_location(), will fix.
Comment 6 Jehan 2014-09-29 23:02:10 UTC
Mitch, what about the second issue where the user says latin characters are supposed to be displayed for Chinese input before selection, but they are not? I see some gtk_im_context_get_preedit_string() that we display as a text_tool->preedit_label text. Is that it? Could it be broken somehow in some cases?
Could you fix this too, since you seem to know this API?
Thanks.
Comment 7 Michael Natterer 2014-09-30 07:40:29 UTC
I have fixed this bug here (not tested and not pushed) and I can probably
fix the other, but somebody needs to tell me how I can get an input
method like that on linux. Half an hour googling last night didn't bring
me closer to any input method that has its own GUI.
Comment 8 Jehan 2014-09-30 09:44:41 UTC
Mitch,

You need to install ibus and ibus-anthy (anthy is the Japanese IME, but it has the same placement issue. I could not reproduce the second issue though, but maybe it is Pinyin specific. You should find some ibus-* for this, I don't know a name out of my mind), and whatever dependency needed by your package manager.

Then run it, and in the IBus preferences, go to "Input Method" tab, by default there will be probably 1 input method with a keyboard symbol and the name corresponds to your layout. Keep it (that will be to write "as usual"), then click the "Select an input method" list, click "Show all input methods", then again, and select "Japanese" > "Anthy" (don't take the Japanese subitem which looks like a keyboard, it only changes the layout, it won't make you output Japanese). Then click "Add". Then close. You may have to restart IBus, maybe even to log-out/in from your user session.
When IBus is running in background, the default shortcut to switch input methods is ctrl-space. You'll see the keyboard icon change in the system tray, if you have one.

Now go to any program, and begin writing (syllables: a ba ka, etc.), it should transform. To get the suggestion list, type twice the space bar.
I'll go to IRC later if you have any problem.
Comment 9 Jehan 2014-09-30 10:09:11 UTC
For pinyin, there seems to be a package called simply ibus-pinyin. Install it, then you can add it in IBus preferences, same as you added Anthy.

I don't know how this input method works though, since I don't speak/write Chinese. I assume it won't be as easy as Japanese (the just-syllable one). Maybe just type things at random and see. :P
Comment 10 Michael Bauer 2014-09-30 10:20:15 UTC
All Pinyin IMEs I'm familiar with start suggesting characters at the CV stage and offer close matches at the CVC state and get quite good at the digram stage.

Open syllables should bring suggestions, for digrams just try some city/province names like Beijing, Shanghai or Fujian.
Comment 11 Michael Natterer 2014-09-30 22:08:27 UTC
I did that (ibus) was already installed, but I have to call ibus-setup
manually (it does not show up in the gnome prefs), and I cannot switch
to any input method I added. The panel icon and super+space only ever
show the input sources added via the gnome keyboard prefs. I think there
is something broken with this stuff in gnome 3.14 (debian unstable).
Comment 12 Michael Natterer 2014-09-30 22:29:11 UTC
Created attachment 287486 [details] [review]
Untested patch

Attached patch calls gtk_im_context_set_cursor_location() when
we draw the text tool cursor.
Comment 13 Michael Natterer 2014-10-02 22:12:33 UTC
Fixed in master and gimp-2-8:

commit 90b7f24190d5f2d7934742de17ddc5560a01a5ef
Author: Michael Natterer <mitch@gimp.org>
Date:   Wed Oct 1 00:26:48 2014 +0200

    Bug 737583 - Fix static placement of Chinese IME window
    
    Call gtk_im_context_set_cursor_location() whenever we draw the text
    tool cursor or start a preedit sequence.
    
    (cherry picked from commit 7ee69c3053ef2fa32deb82ca65f54e0f038f5ac6)

 app/tools/gimptexttool-editor.c | 39 +++++++++++++++++++++++++++++++++++++++
 app/tools/gimptexttool-editor.h |  1 +
 app/tools/gimptexttool.c        |  8 +++++++-
 3 files changed, 47 insertions(+), 1 deletion(-)
Comment 14 Jehan 2014-10-02 22:23:19 UTC
Tested. Works well. I just wondered why you have the suggestion start to the bottom-right corner of the preedit box, rather than the bottom-left. Wouldn't it make more sense?

Also have you had some chance about this second issue that the user reported about preedit string being different as expected for pinying im?
Comment 15 Michael Natterer 2014-10-02 23:11:42 UTC
We pass the extents of the preedit box as cursor rectangle, how the IM
GUI actually get placed is not under our control.