Bug 131213

I can't reproduce it with iiimf-server-11.4-66.svn1772, can someone
else test it with earlier version a little bit?

Can you reproduce it in im-sdk-12.0 onwards?
I do have older version of im-sdk. If you like I can pass it to you.

My apologies. Did not understand what you meant earlier. Will do a
test on a version between 11.4-66 and 12.0.1 to find out when the
problem starts to emerge.

Tested with 11.4-70.svn1856 and iiimf-le-chinput-0.3-6, the problem
still exist. Will try again with -68 perhaps.

it's just FYI:
First, right now IIIMF do nothing because chinput doesn't call
iml_aux_done_inst().
IMO the location of realizing/destroying the aux object is probably:
1) where the IM is activated/deactivated, like my_conversion_on/off()
    PROBLEM: as you know, it makes slow starting the applications.
maybe you need to fix the aux object to speed up.
2) where the session is created/destroyed, like you already did and on
DestroySC to call aux_done.
    PROBLEM: since the trigger of DestroySC is from the client side
and when it's came from the client side, IIIMCF handle is also
destroyed. so LEs can't do anything for that on DestroySC so that the
session on the client side was disconnected.

although maybe both issues should be fixed, 2) looks hard to fix.

Tested with 11.4-68.svn1833 and  iiimf-le-chinput-0.3-6, the problem
still exist.

Tested with 11.4-65.svn1804 and iiimf-le-chinput-0.3-6, the problem
still exist.

Tested with 11.4-66.svn1833 and iiimf-le-chinput-0.3-6, the problem
still exist. 

I noticed that the version -66 you used has a different svn number.
Maybe you could send me your im-sdk package and I can have a look again.

Thanks.

could you please destroy the aux object itself if the aux object isn't
used anymore as the summary says it?
even if all of window was closed, the aux object process still remains.

tagoh    22386 22322  0 23:14 ?        00:00:00 com.redhat.chinput.status

Reproduce Procedure:
1) Right-Click gimlet -> Preferences
2) Set "use the language currently selected in Quick Access menu"
3) Use cannaLE Japanese
4) Focus in a gtk2 app
5) CTRL-Shift-Space and change to Simplified Chinese
6) CTRL-Shift-Space and change to Japanese

Result:
chinput's auxmenu does not destroy, despite Japanese being the active
LE.  Changing focus to other apps does not make auxmenu go away.  Only
thing that makes it go away is if you switch back to Simplified Chinese.

Tested with im-sdk-12.1-1 on x86_64 machine, the problem still exist
after LE if toggle off.

llim      4470  1.1  0.6 96208 6584 pts/2    S+   20:35   0:00
com.redhat.chinput.status

The aux menu now gets destroyed after I click the (x) button on
application. But I need to check if the process is still there. Moving
to QA queue.


Thanks.

Tested im-sdk-12.1-6 with iiimf-le-chinput-0.3-13, closing the
application using the (x) button does remove the aux from the screen.
However, the process is still running.

root      7318  0.7  2.4 23164 6132 pts/1    S    15:20   0:00
com.redhat.chinput.status

Set it to UPSTREAM, casue right now, hide the aux window is the best
solution so far. 

Aren't you upstream for iiimf-le-chinput? and do you have any bug
tracker for? :) Why I've changed this summary is to avoid the upgrade
problem. right now when people is upgrading LEs, older aux object is
used as long as it's running. IMHO restarting the desktop or so after
upgrading is a bug. I don't think hiding the aux window is *best* anyway.