Improve support for non-gnome Input methods

this post means:
gtk2 support dynamic change of imput methods by context menu.
and there's no context menuitem for the change in mozilla textarea or input::text.
so cannot change input methods on the fly.

shanjian: do you know what does he mean? Do we have problem in Linux-IME?

Currently XIM support is disabled in GTK2 due to the problem
of bug 176514. We should mark this as invalid or dup.

XIM is enabled, so this is relevant.

gtk2 by default on all text input areas has certain options on the menu that
pops up when you right-click. These options allow one to select the current
input method, and enter certain special Unicode control characters as well.
mozilla has completely replaced the gtk2 menus with its own menu, removing this
functionality.

This means that it's impossible for users to change the current input method
while running mozilla. The only way to change the input method is to quit
mozilla and restart it with the GTK_IM_MODULE environment variable set to
something different.

In fact, many users might not realize that they can set the GTK_IM_MODULE
variable. (e.g., export GTK_IM_MODULE=xim for XIM) If they don't know this,
then they won't be able to use any input method at all. Perhaps it should be in
the release notes.

Would it be possible to add the menu for gtk2 input module selection to the
Mozilla's menu (for textinput area)? How about adding a pref. entry to disable
Mozilla's menu so that in its place gtk2 input module menu pops up on
right-clicking? Yet another possibility is to bind the gtk2 input module menu to
something other than right-clicking (if that's possible) such as
shift+right-clicking. Or, we can do the other way around binding Mozilla's menu
to shift+right-clicking while keeping gtk2's.

I'm just thinking loud here...

Owen, does any of what I wrote above make sense?

I'm not sure how much work it is to do that. I've never looked into what it
would take. Right now we just have a single input context for the entire
browser window, so things could be challenging as well.

This might be a good impetus to have input contexts on only the various text
boxes. Of course, that might cause problems with findasyoutype. Sigh.

Support of gtk2 input module selection would be a nice step forward, since XIM
is more or less dependent on setting the LANG variable.

IMHO, it is not correct to use LANG to set _input method_, though obviously it
sometimes coincides. This use of LANG is not internationalization in the
multilingual sense, just multi-monolingual.

So, supporting an more flexible and already working way of selecting input
methods would be very welcome!

shanjian is no longer working on mozilla for 2 years and these bugs are still
here. Mark them won't fix. If you want to reopen it, find a good owner first.

give it to blizzard for now

Mass Reassign Please excuse the spam

I understand that the way to do it is:
1. Make the XUL popup menu implement GtkMenuShell.
2. Populate it with gtk_im_multicontext_append_menuitems.

(In reply to comment #11)
> I understand that the way to do it is:
> 1. Make the XUL popup menu implement GtkMenuShell.
> 2. Populate it with gtk_im_multicontext_append_menuitems.

That will only work for XUL-using applications. Embedders need a way to get at the Gtk IM context.

Hello everyones,
I confirm this bug his really anoying fore people using more than one input method system at a time.
I use scim with anthy to write in Japanese and XIM with unikey or gtk-unikey to write in Vietnamese. Because it is not possible to change the input method direcly in Firefox I need to close all instances of Firefox and reopen with the right GTK_IM_MODULE variable set.

The discussion is on how to implement the input method switch for every input box. I suggest you simplify the problem by just giving one gtk-box somewhere (for exemple it could be an element of the toolbar).
When wanting to change input-method a right click on this box of the toolbar and it is changed for all Firefox. (^^)

Maybe see bug 247777 that speaks about pango and seems to be a cue for you.
Thanks all for your work, I would be so happy to see this bug fixed.

Guillaume

This is going to be fixed on Chrome, see http://code.google.com/p/chromium/issues/detail?id=31008

I also consider this bug annoying, albeit minor.

*** Bug 247777 has been marked as a duplicate of this bug. ***

Created an attachment (id=422912)
Patch v0.1

This patch succeeded to change the IM by hidden menu.

So, we can append some native menus to our XUL menu. But I need to implement the mechanism. I'll try to fix this bug after bug 520732.

Moving all open keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.