From Fedora Project Wiki
(Imported from MoinMoin)
m (1 revision(s))
(No difference)

Revision as of 16:27, 24 May 2008

Input Method and Desktop Integration


Improve input method integration on the desktop so that input methods can be started, stopped, and switched dynamically.


  • Name: AkiraTagoh

Current status

  • Targeted release: Fedora 10
  • Last updated: 2008-03-19
  • Percentage of completion: 90%
  • Remain to be completed
  • Qt/KDE support
  • Implement code in Qt to switch immodule against QtSettings dynamically.
  • XIM support
  • --(Implement code to switch XIM server.)--
  • Implement a dummy XIM server acting for @im=none.

Detailed Description

Currently there are annoying limitations when using input methods on the desktop: for example it is necessary to restart the desktop to enable or disable an input method. There are also key conflicts between input methods and applications. This feature plan is to improve the integration at the toolkit level to fix the above issues.

Benefit to Fedora

This feature will improve the usability for people who use input methods, and also for those who don't and are annoyed with input method hotkeys conflicting with applications hopefully, because input method could be being started/stopped as needed and take an effect without restarting. this feature would be useful and helpful for Live image.


This feature can be broken down into:

1. disabling/enabling the input method without restarting the desktop, which means the input method is being started/stopped as needed. 1. changing the input method without restarting the desktop 1. hotkey configuration

Test Plan

1. --(make sure all the changes, including enabling/disabling/changing the input method is applied immediately for GTK+ applications)--

1. --(build an infrastructure to bring up the input method on demand)-- 1. --(im-chooser support)-- 1. --(apply to the GTK+ applications on Xfce)-- 1. apply to the Qt applications 1. apply to the X applications

User Experience

Users isn't required to restart the desktop to do something for the input method.


Patches to gtk+, input methods, other toolkits, and desktops need to be accepted upstream.

Contingency Plan

Revert to current xinput.d and environment variables system as a fallback.


Promoting on flash movie is:

Release Notes

not yet.


Q: what is the plan to make it work with qt qt4 wx-widgets and all the other windowing toolkits we support?

  • MatthiasClasen: Worst-case, they will require a re-login to make input method changes effective, as before. But I believe that KDE support is on the agenda for this feature.
  • AkiraTagoh: Right. surely KDE support is included in this plan and it's a next target at this moment. I'm not sure if other toolkits has an own XSETTINGS manager, which is required to make this working. if there are, we can support it too. otherwise it's out of scope for this plan.
  • MatthiasClasen: rdieter recently put a kde xsettings manager into rawhide.
  • KevinFenzi: Xfce has xfce-mcs-manager to handle xsettings, will it work with this? That would be delightful.
  • AkiraTagoh: Thank you for useful info. then we need to add a XSETTINGS stuff, "Gtk/IMModule" and something for Qt(and something if xfce has own input method module mechanism). I'll take a look later anyway.
  • KevinKofler: xsettings-kde is only a compatibility thing for non-KDE (GTK+ mainly) applications in KDE. It also currently doesn't work with KDE 4. KDE applications don't use xsettings at all, instead, setting changes which applications should dynamically adapt to are communicated through KGlobalSettings, which is implemented using KIPC (which uses an X11 atom called "KIPC_COMM_ATOM" internally) for KDE 3 apps and through D-Bus for KDE 4 apps (yes, they use separate notification mechanisms, so you need to call out to both to get the changes applied everywhere). Qt-only apps also use their own setting change notification mechanism (through an X11 atom called "_QT_SETTINGS_TIMESTAMP_" and reloading their config file). So this will be a lot more work than just running xsettings-kde.

Q: Implications to QT/KDE?

  • MatthiasClasen: Isn't this the same question ?

Q: Heading to upstream GNOME?

  • MatthiasClasen: All the Gnome patches are upstream, afaik.
  • AkiraTagoh: Or you mean heading im-chooser itself to GNOME?

Q: Describe what this means to people who don't know what "input method" means?

  • MatthiasClasen: While an interesting question, how is this related to accepting this feature ? This feature will be useful for people who do know what "input method" means...
  • AkiraTagoh: Indeed, they won't see, and don't even need to see chooser UI. even if this feature is applied, they won't see any difference between older release. but this improves for people who do know what "input method" means, regardless of they are a native speaker.
  • KevinFenzi: I think the thing here is that if we tout this as a cool new Feature, it might be nice to have some background information on what a "input method" is, so people who don't use input method now will go: "COOL, I can use that"?
  • AkiraTagoh: Ok, it's free to learn any languages. everyone may wants to use "input method" at some time. will update.
  • JesseKeating: That's basically what I was looking for. The ability to advertise it in a way that it makes sense even to those that have never used an 'input method', instead of having seemingly technobabble.

Q: Did you talk to an interaction designer for the chooser?

  • MatthiasClasen: Again, this seems to fall outside the 'feature sanity' scope that we use for acceptance of features. But to answer the question anyway, I have had some back-and-forth with Akira about the chooser UI. Note quite an interaction designer...

Q: What is the scope of input method? Will it let me pick and choose shortcuts to switch keyboard layouts for different languages? What about creating custom superlayouts that can produce any character from several languages of choice?

  • MatthiasClasen: "Input method" means exactly the same it has always meant: a method of interpreting sequences of keystrokes and convert them into sequences of characters. These methods are usually language- (or script-) specific, and usually make use of some framework, such as xim or scim. Selecting keyboard layouts is somewhat related, but this feature is not about exploring ways to combine input methods and keyboard layouts. And "custom superlayouts" are definitively not part of it. You don't need _any_ input method to "produce any character from several languages" anyway: GTK+ lets you enter any Unicode character by typing Control-Shift-u <hex code>.