Now it is possible to change default input method and enabled input methods with uim-pref, I would like to get these updated information via C API dynamically for uim-xim. It will be used for newly created context and available IMs list sending to uim-im-switcher. Currently uim_get_default_im_name() and uim_get_nr_im() don't reflect uim-pref's updated setting.
I'm working on related issue. Probably default input method update will be available for uim 0.4.6. But enabled-im-list and corresponding IM objects are having a inconsistency problem. See following comments. I would like to resolve it by integrating all IM information into Scheme-side constructs because it is easy to implement and maintain. But it will involve long discussions since some developers want to split Scheme interpreter off from libuim. So this problem will be resolved after 0.4.6. im.scm: ;; Invoking this procedure causes inconsistency between im-list and ;; corresponding IM management entity in C-side ;; (uim_im_array). uim-im-switcher may show IM list in strange ;; order. This inconsistency problem is also preventing IM removal ;; feature implementation. We should resolve it after uim 0.4.6. ;; -- YamaKen 2005-01-25 (define normalize-im-list ;; enabled-im-list cannot be changed once libuim has been ;; initialized. This limitation may be removed after uim 0.4.6. ;; -- YamaKen 2005-01-25 (define enabled-im-list ())
Thanks for the information. I didn't noticed the comments in im.scm. Related to this question, I would like to use C API which retrieves IM's language (and maybe other information) using IM's name. I think current uim_get_im_language(uim_context uc, int nth) type of APIs are not comfortable while updating IM's information on bridges if enabled-im-list is updated by custom.
As I know, almost all uim develpers are feeling the problem (of course me too). - lacking name-based IM information acquisition - unnatural dummy context is required for IM information acquisition But API change is deferred to uim 1.0 to keep backward compatibility. Hiroyuki said that we should change uim API only once until 1.0. So API change of the IM information acquisition should be aggregated into "the big change of uim API" for 1.0. The second problem described above is related to nested-eval and callback queue problem. So we can resolve it once the uim 0.4.6 has been released and callback queue is completely removed from libuim. Would you write draft version of the IM information acquisition API? Let's register it as new bug if you interested in.
Add to the TODO list for uim 0.6.0.
uim_get_default_im_name() may work as you want after r443 of new repository. ------------------------------------------------------------------------ r443 | yamaken | 2005-02-01 10:27:00 +0900 (Tue, 01 Feb 2005) | 23 lines * This commit enables limited version of set-hook invocation with custom-rt.scm. It results that im-default-name and toolbar configurations in running processes are dynamically updated on the fly
This problem is now expected as resolved with recent "IM and context management concentration into Scheme". See doc/COMPATIBILITY for further information. Etsushi, please check whether this problem is resolved.
(In reply to comment #6) uim_get_nr_im() now works as expected. I'll fix Qt immodule code later to correspond the fix.
(In reply to comment #7) > uim_get_nr_im() now works as expected. I'll fix Qt immodule code later to > correspond the fix. This information was incorrect, sorry. It is not fixed with the "IM and context management concentration into Scheme" yet. See bug #2622.
I think r4465 and r4467 fix the problem.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.