[immodule-qt] introducing QT_IM_SWITCHER environment variable
yamaken at bp.iij4u.or.jp
Tue Aug 10 11:02:44 EEST 2004
At Mon, 09 Aug 2004 15:23:05 +0900,
yamaken at bp.iij4u.or.jp wrote:
> At Fri, 6 Aug 2004 23:48:45 +0900,
> takumi at asaki.jp wrote:
> To satisfy these contradictive two requirements, I suggest
> following new scheme.
> - Introduce 'imsw-none' switcher plugin
> - 'imsw-none' reads QT_IM_MODULE or the equivalent of qtrc, and
> create the specified input context using
> - Once the input context has been created, imsw-none does
> nothing further. It only participates with instantiation
> rather than proxing QInputContext like QMultiInputContext
> The imsw-none isolates IM-switcher issues from libqt, and it's
> benefical for developers as I said in the 'pluggable
> IM-switcher' opinion. For example, input method developers may
> be agreed with introducing generic environment variable to
> specify default input method regardless of GUI-toolkits such as
> IM_MODULE. We can easily follow the new convention without
> updating libqt itself if imsw-none is adopted. Only updating
> imsw-none plugin is required.
I've implemented imsw-none as described above. See r66 of the
trunk. Now we can disable IM-switcher by following
setenv QT_IM_SWITCHER imsw-none
setenv QT_IM_MODULE xim
> Although user and developer requirements can almost be satisfied
> with above scheme, a little compromise is required.
> Although the variables are configured as follows,
> setenv QT_IM_SWITCHER imsw-none
> setenv QT_IM_MODULE xim
> Following configuration is still also valid and works properly.
> setenv QT_IM_SWITCHER xim
> It confuses ordinary users. Although ordinary users will not
> imagine such configuration, weird users will favor such
> configuration and publish their configuration memo to the
> world. It will confuse victims that googled with 'QT_IM_MODULE'.
> To prevent such unwanted happening, we should restrict the
> plugins that can be specified by QT_IM_SWITCHER as real
> IM-switchers. It can be actualized by checking whether the
> specified plugin has the 'imsw-' prefix.
Above restriction is also implemented. See r67 of the
trunk. This restriction has changed the configuration convention
for system integrators as follows.
- valid configuration
setenv QT_IM_SWITCHER imsw-none
setenv QT_IM_MODULE iiimqcf
- following configuration has become invalid
setenv QT_IM_SWITCHER iiimqcf
> > But there is one problem, If delete qtrc support.
> > How can I get list of InputMethods I can set to QT_IM_* env?
> I can't imagine good solution. Any ideas?
> Generate the list and save it into a file such as
> 'inputmethods.dir' may be sufficient. But when should we execute
> it? What should executes it?
I still have no idea about it. But I've brought a incomplete
solution. The filename of input method plugins are renamed as
following simple form. You can get a identifier name of the
input method by stripping 'libq' prefix from the filename.
$ ls $QTDIR/lib/plugins/input
The simple naming convention rather than long
'qfooinputcontextplugin.so' style name is preferable for Qt
plugin. See following result.
$ grep -h TARGET immqt/immodule-qt-x11/trunk/plugins/src/*/*/*.pro
Although the naming convention provides identifier name of the
input methods, this is not a solution for some input method
plugin that contains multiple input methods such as uim.
YamaKen yamaken at bp.iij4u.or.jp
More information about the immodule-qt