GNOME Bugzilla – Bug 450716
New API to change global IM
Last modified: 2009-01-14 17:38:45 UTC
Currently there is no way to change the global IM used by GtkIMMulticontext programmatically. This would be useful, for instance, to switch to the multipress IM on application startup without having to make it the default for all locales by changing the IM module configuration. To facilitate this, I propose to add two new public functions to GTK+: G_CONST_RETURN gchar * gtk_im_multicontext_get_global_context_id (void); void gtk_im_multicontext_set_global_context_id (const gchar *id);
Created attachment 90578 [details] [review] Patch to add the proposed API This patch implements the proposed API. This solution is not perfect, as changes to the global IM aren't picked up by already existing GtkIMMulticontext instances until the next focus change. There shouldn't be any adverse effects beyond that, however. Another patch that adds API for switching a GtkIMMulticontext's slave IM on an individual basis will follow in a separate bug.
Not sure an app-callable api is really what we want here. Wouldn't it make more sense to add a setting to control this desktop-wide ? Or maybe I am misunderstanding the use case here, and non-desktop-wide is exactly what you want here...
of course, a setting still allows applications to override the value.
Created attachment 91213 [details] [review] Remove the global context id and allow per-multicontext ids I think exposing the global context id through API would be a mistake, it's an internal detail of how the multicontext is currently implemented and a pretty ugly one at that in my opinion. I have been thinking about the related problem of how to change the context id desktop-wide, and to that end here's a quickly put together patch that: - Completely removes the global context ID - Taking hints from your patch, allows the application to get/set the id on a per multicontext basis so that you can assign for example a multipress context to a specific widget. - Introduces a gtk-input-method-context-id GtkSetting for holding the default desktop-wide context. Using a settings manager it will then be possible to make desktop-wide changes to the id of all multicontexts that are not set programmatically or explicitly by the user.
Created attachment 91219 [details] [review] Remove the global context id and allow per-multicontext ids, patch 2 Patch updated with the necessary GDK bits so the X property to GtkSettings bridge works, also properly in diff -p format this time around.
That's fine with me. Thanks. Matthias?
The setting-related parts of the patch look fine to me, but gtk_im_multicontext_get/set_context_id() is not going to be useful, since im contexts are not exposed as part of the public api - they are private members of GtkEntry/GtkTextView.
Thanks Tomas for your work. (In reply to comment #7) > The setting-related parts of the patch look fine to me, but > gtk_im_multicontext_get/set_context_id() is not going to be useful, > since im contexts are not exposed as part of the public api - > they are private members of GtkEntry/GtkTextView. Yes. I was planning to expose these members in another patch to allow switching the context per widget. This seems cleaner to me than adding the necessary API directly to GtkEntry/GtkTextView. I'm open to better ideas, though.
Hmm, I'm not convinced that is a good idea. None of the imcontext api is usefully callable by applications. And I have a hard time coming up with a use case for per-widget im contexts. If anything, what may be necessary is a way to turn off input methods per-widget. we already do that for password entries.
> I have a hard time coming up with a use case for per-widget im contexts I've mentioned this use case several times: A embedded device has only a numeric keypad (0,1,2,3,4,5,6,7,8,9, for instance). When entering data into a numeric field, the default input method will be fine. When entering data into an alphanumeric field, the multipress input method would allow, for instance, "abc" to be entered.
I don't understand why, on such a device, you wouldn't use multipress for all input fields.
Because it's tedious to type in numbers with multipress.
And this is what happens on most mobile phones, probably including your own. Phone number entry is single press, but contact names are multi-press.
A related bug is bug 346780
Yes, bug 346780 seems to be about adding API to specify input methods per widget (actually, about "turning off" the input method per widget, presumably falling back to the default input method).
Could we please move forward somehow on this? Does anyone still disagree that we should want to be able to programmatically change the input method?
So, is bug 346780 enough for your needs Murray?
Behdad, I replied to that in comment #15. The description of that bug's patch is "Attached patch adds gtk_im_context_set_im_mode() API. This function passes a string attribute to GtkIMContext". So that seems to allow modification of the behavior of one GtkIMContext, rather than the selection of a different GtkIMContext. I also don't see how the application coder would have access to the active GtkIMContext to even change its behavior in this way.
Bug 502446 contains the solution I currently favor for setting im contexts, adding a setting.
Ok, here is a proposal: We add "im-context" properties to GtkEntry and GtkTextView, which reflect the selected item in the input methods context menu. Applications can then set that to override the global context id.
Sounds good to me. Presumably you could set it to NULL to use the global input method again.
Yes. Note that this would change the behaviour or the input methods context menu, which so far sets an application-wide id, not a per-widget one. Not sure everybody will like that change, but imo the context menu is a thing of the past anyway, which is why we hide it by default nowadays. Having system-wide input methods (a la scim) with per-widget overrides sounds like a fine approach to me.
(In reply to comment #22) > Yes. > > Note that this would change the behaviour or the input methods context menu, > which so far sets an application-wide id, not a per-widget one. Not sure > everybody will like that change, but imo the context menu is a thing of the > past anyway, which is why we hide it by default nowadays. Having system-wide > input methods (a la scim) with per-widget overrides sounds like a fine approach > to me. Looking at my use of input methods, I wonder if that makes it hard to use some input methods. I'm usually only interested in SCIM personally, which allows me to change the Input mode either application wide or desktop wide through a system tray icon. Is this possible with other Input Methods as well?
Created attachment 119561 [details] [review] patch Here is a patch which does this for GtkEntry. If we decide to go down this route, it will have to be extended to GtkTextView as well. There's an unrelated change to the input method context menu as well.
One question about settings part. what's different between one in your patch and existing Gtk/IMModule? having a capable to change immodule per widgets sounds good to me though, delivering the change through XSETTINGS affects to all of widgets on the desktop. which sounds duplicate to Gtk/IMModule. do we really want to have separate settings for that?
Actually the above comment is for the patch at Comment #5.
The proposal, as implemented in my patch is to a) Have a Gtk/IMModule xsetting, for desktop-wide input method selection (this is the preferred way of selecting input methods) b) Have a way to override the desktop-wide selection programmatically, by setting the im-module property on an entry. The use case for that is explained in comment #10 c) Change the input method context menu to set change the input method only for the individual entry, not application-wide. Part c) is the behaviour change that we are slightly worried about. Note though, that we don't show the input method context menu by default, since a) is the preferred way of selecting input methods. Also note that it is still possible to change input methods application-wide (by explicitly setting the gtk-im-module setting), but GTK+ doesn't offer a ready-made solution for that - you'd basically have to construct a menu similar to the context menu for that, and make that available somewhere in your app.
(In reply to comment #27) Thank you for the explanation. I confess patches not marked as obsolete was still alive. that sounds good to me.
I guess this patch needs to be updated now that the GtkSetting has been committed via a patch in another bug.
A part of that patch committed from bug #553086. I've tried to update the rest of the patch so it compiles again, but some of the conflicts are hard for me to figure out.
Created attachment 126333 [details] [review] updated patch
Here is a patch against current trunk which adds the ::im-module property to both GtkEntry and GtkTextView. I'll commit this shortly, if nothing else comes up.
That would be great. Thanks.
* gtk/gtk.symbols: * gtk/gtkimmulticontext.[hc] (gtk_im_multicontext_set_context_id): New function to set the context id on a GtkIMMulticontext. * gtk/gtkentry.c: * gtk/gtktextview.c: Add a ::im-module property that can be set to override the global setting for the im module to be used.
I wonder if this property should be in GtkEditable and its other implementations: http://library.gnome.org/devel/gtk/unstable/GtkEditable.html#GtkEditable.implementations and also in GtkCellRendererText.
It wouldn't really help. GtkTextView is not a GtkEditable (I don't know why), and the other implementations of GtkEditable are the 1.x era text widgets. GtkSpinButton is covered by being derived from GtkEntry. GtkCellRendererText is not an editable widget.