Description of problem: I am developing ibus input framework. For gtk I need develop ibus im module. for some cases, I need fall back to XIM. For example, if a user launch an gtk apps with sudo, or executes an X apps in remote host, the ibus im context can not connect to the ibus daemon. In those cases, we want to ibus im context could create an xim im context, and use xim to access ibus. But I can not find any API to do it. Could you export gtk_im_module_create function? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
There is no guarantee that the xim input module is even installed. Fallback between im modules like that is simply not part of the GTK+ im framework right now. If we want it, it needs to be thought out and designed. I don't think just 'exporting a gtk_im_module_create' function is the way to do this. If you need this now, you can manually open the DSO and use it that way. But that is not something I would recommend.
(In reply to comment #1) > There is no guarantee that the xim input module is even installed. I think it is not a problem. If the XIM im module is missed. It just fallbacks to simple im context. And we could also to add Requries in ibus's rpm spec. > Fallback between im modules like that is simply not part of the GTK+ im > framework right now. If we want it, it needs to be thought out and designed. I > don't think just 'exporting a gtk_im_module_create' function is the way to do > this. I haved tried using GtkIMMulticontext and want to use gtk_im_multicontext_set_context_id pick the xim im context. But it failed. Because I need create fallback GtkIMMulticontext in my im context, but the gtk_im_multicontext_new does not have an argument of context_id, so it will cause creating my im context inside it. It will cause recursive. (ibus context creates multicontext, and then multicontext creates ibus context, and etc). I also tried to add wrapper function gtk_im_module_create for _gtk_im_module_create. It works well ibus im context. It just need a little work in ibus im module. If GTK+ does not provide im module related API, I must duplicate the xim module's code into ibus im module. It is not good for maintaining. And for other platforms (Windows, Mac), maybe we also need duplicate some modules' code to ibus. > > If you need this now, you can manually open the DSO and use it that way. But > that is not something I would recommend. Sorry. What's the DSO? Is it SO?
> Sorry. What's the DSO? Is it SO? I meant that you could dlopen the module. Anyway, I don't agree that all these acrobatics are really necessary. If ibus can't work, than it can't. Its ok, users will cope.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.