There are some abundant words caused by miscopying, sorry.

(In reply to comment #0)
> 1.輸入組字字元時輸入區不見了
>   The disappearance of the HIME input box when inputting character combination
> keys.

Can you please provide exact steps (click by click) to reproduce this problem, and maybe even attach a screenshot?


> 2.Commit時（按Enter一下）會直接執行搜索動作（通常是搜索Wikipedia），而不是輸出commit字串於textbox中。
>   When commit string to the search bar(by pressing enter *once*) gnome-shell
> will directly perform the search process(usually is searching the Wikipedia),
> but not insert commit string into the search bar.

I don't understand this either - what are the steps to reproduce this, what is the expected outcome, and what is the actual outcome?

André Klapper, 
Thanks for reply.
I will need some time to provide more information.

André Klapper,
If you don't mind please reply to https://github.com/caleb-/hime/issues/244        as well, since I'm not actually a developer of HIME input method.
I'm still finding some spare time to provide more apparent information.
Thanks.

(In reply to comment #4)
> André Klapper,
> If you don't mind please reply to https://github.com/caleb-/hime/issues/244    
>    as well, since I'm not actually a developer of HIME input method.
> I'm still finding some spare time to provide more apparent information.
I think that should be the other way round - ask them to come and comment here. Why should we go discuss on a bug tracker for a software we don't know about, with comments in Chinese we don't understand? ;-)

Step to reproduce:
 Step 1, Click Activities on the top-left corner
 Step 2,  Click on the search bar
 Step 3, Press ctrl-space(to switch to chinese input)
 Step 4, Type
Result: The input box is invisible
Expected: The input box is visible

(In reply to comment #6)
>  Step 3, Press ctrl-space(to switch to chinese input)

Nothing happens here on a default Fedora system (which is no surprise). 
What are the steps needed before doing this, to have chinese input?

(In reply to comment #7)
> (In reply to comment #6)
> >  Step 3, Press ctrl-space(to switch to chinese input)
> 
> Nothing happens here on a default Fedora system (which is no surprise). 
> What are the steps needed before doing this, to have chinese input?

Install hime

(In reply to comment #8)
> Install hime

On Fedora 16:

$:andre\> sudo yum install hime
Setting up Install Process
No package hime available.
Error: Nothing to do

Need working steps to follow in order to reproduce...

(In reply to comment #9)
> (In reply to comment #8)
> > Install hime
> 
> On Fedora 16:
> 
> $:andre\> sudo yum install hime
> Setting up Install Process
> No package hime available.
> Error: Nothing to do
> 
> Need working steps to follow in order to reproduce...

H.I.M.E. is a very lately forked input method and is not surprising that it is not exist in Fedora.
These is some details how to install H.I.M.E. in 
https://github.com/caleb-/hime/wiki/prebuilds-and-auto-build-scripts-of-distros

or you may try install other known input method like ibus or scim...

I spent a few hours writing a document describe the problem, maybe helps a little...
CJK input method compatible problems software developers should avoid. | https://docs.google.com/document/d/1HB3juffu0KgSUyg15y8hBZOLcJdHK9KDVPFyCwqHh-I/edit

I assumed that the information provided above is sufficient, help yourself if the status changing is inappropriate.

fix the above wiki link:
https://github.com/caleb-/hime/wiki/%E5%90%84%E5%80%8BLinux%E7%99%BC%E8%A1%8C%E7%89%88%E6%9C%AC%E9%A0%90%E5%85%88build%E5%A5%BD%E7%9A%84%E5%A5%97%E4%BB%B6%E4%BB%A5%E5%8F%8Aauto-build-scripts-|-Prebuild-packages-and-auto-build-scripts-for-each-of-linux-distributions


for building hime yourself see:
https://github.com/caleb-/hime/wiki/Build-H.I.M.E.%E6%89%80%E4%BE%9D%E8%B3%B4%E7%9A%84%E5%A5%97%E4%BB%B6%E5%88%97%E8%A1%A8%EF%BC%88%E4%B8%8D%E5%AE%8C%E6%95%B4%EF%BC%89-|-Dependencies-for-building-H.I.M.E.-%28incomplete%29

You understand that GNOME developers might not be very interested in installing a component they don't know about and that is not present in common distributions just to understand what the problem is, right? If you're developing an input method, you have to do the work to integrate it with existing desktop environments...

(In reply to comment #12)
> You understand that GNOME developers might not be very interested in installing
> a component they don't know about and that is not present in common
> distributions just to understand what the problem is, right? If you're
> developing an input method, you have to do the work to integrate it with
> existing desktop environments...

@Milan Bouchet-Valat
Although this report is made initially for H.I.M.E. input method, its also exist in other input method (including those "present in common distributions" ones, like ibus(ibus-chewing), scim(scim-chewing), all in similar problems) , I believe there is flaws existed in keyboard event handling part of GNOME shell (search bar).

Not until this problem is solve, most of the CJK users can't properly search via the search bar...

(In reply to comment #12)
> You understand that GNOME developers might not be very interested in installing
> a component they don't know about and that is not present in common
> distributions just to understand what the problem is, right? If you're
> developing an input method, you have to do the work to integrate it with
> existing desktop environments...

You can try installing ibus and it will have the same problem.

Installing ibus chewing:
yum install ibus ibus-chewing

Generally speaking, the problem is must at gnome-shell side.
The problem is, input method must have the HIGHEST priority for key event. Which can not be guaranteed by gtk.

So gtk application developer must carefully try to avoid "eat" any key event. I know there are some case, key event must be explicitly processed on the application, but even in this case, it should be passed to input method first.

In this case, Chewing is one of the input method (no matter in ibus, hime, gcin or fcitx), which must use "Enter" to commit. But gnome-shell process the enter key event before input method, and cause this problem.

For this case the problem is in ui/viewSelector.js around line 134, it use key-press-event and process KEY_Return, so input method cannot work correctly.

In the other words, key-press-event and key-release-event should have lower priority than input method, which can simply avoid all similar problem.

(In reply to comment #15)
> For this case the problem is in ui/viewSelector.js around line 134, it use
> key-press-event and process KEY_Return, so input method cannot work correctly.
Ah, this is an interesting information. Are you able to make input methods work when you remove these lines?

(In reply to comment #17)
> (In reply to comment #15)
> > For this case the problem is in ui/viewSelector.js around line 134, it use
> > key-press-event and process KEY_Return, so input method cannot work correctly.
> Ah, this is an interesting information. Are you able to make input methods work
> when you remove these lines?

Yes, but the problem is not only limited to KEY_Return.

Actually other key processed in this file (direction key, for example) is also used by many input method, but it's not commonly used, so seems nobody mention this yet. That's said, Every Keyboard event, should be passed to input method first.

Actually Qt provides a different interface for im module, which is seem to use X11 Event filter, which make sure Key event is passed to input method, seems because of this Qt application rarely meet similar problem.

(In reply to comment #18)
> Yes, but the problem is not only limited to KEY_Return.
So I guess the question is: can you identify the place where this could be fixed for the general case?

(In reply to comment #19)
> (In reply to comment #18)
> > Yes, but the problem is not only limited to KEY_Return.
> So I guess the question is: can you identify the place where this could be
> fixed for the general case?

I'm not familiar with the internal implementation of gnome-shell or clutter, but as far as I check.. seems in st?

maybe st-entry or st-im-text, I'm not sure.

This is a duplication of 658325

*** This bug has been marked as a duplicate of bug 658325 ***