Bug 497484 - Please export some APIs for creating im context by context id
Please export some APIs for creating im context by context id
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gtk2 (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 495690
  Show dependency treegraph
 
Reported: 2009-04-24 03:04 EDT by Peng Huang
Modified: 2010-06-28 08:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 08:11:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Peng Huang 2009-04-24 03:04:36 EDT
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:
Comment 1 Matthias Clasen 2009-04-24 10:14:55 EDT
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.
Comment 2 Peng Huang 2009-04-24 19:49:15 EDT
(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?
Comment 3 Matthias Clasen 2009-04-24 22:19:06 EDT
> 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.
Comment 4 Bug Zapper 2009-06-09 10:30:21 EDT
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
Comment 5 Bug Zapper 2010-04-27 09:54:26 EDT
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
Comment 6 Bug Zapper 2010-06-28 08:11:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.