Description of problem: the newly released libgxim-0.3.2-3 breaks kyeboard input in xterm Version-Release number of selected component (if applicable): libgxim-0.3.2-3.fc10 How reproducible: always Steps to Reproduce: 1.login in graphical mode (gnome in my case) 2.open an xterm 3.try to type whatever in the xterm Actual results: no typing and lots of errors in .xsession-errors Expected results: typing should occur Additional info: perhaps checking the updates for basic functionality before release should not be so bad. I checked in koji no F10 version has been built/tested for months
Created attachment 333862 [details] xsession-erros related to the bug .xsession-errors
... checked on a x86_64, same result, the bug is there on x86_64 architectures as well
Thank you for catching this up. just tested on GNOME/GTK+ applications only. this issue seems to be introduced by a patch that fixes a memory leak and no GdkWindow instance happens after unreferencing the object during copying the object. Anyway I'll have a fix of this issue shortly.
*** Bug 488242 has been marked as a duplicate of this bug. ***
Fixed in libgxim-0.3.2-4.fc10.
libgxim-0.3.2-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libgxim-0.3.2-4.fc10
Please vote if it works for you. that would speeds up to push to stable..
i386: it works (5 minute test of course...), I am going to test a x86_64 machine....
... and it works on x86_64 as well (few minutes...) Great responsiveness!! Thanks a lot
I was seeing maximized xterms fail to accept keyboard input, or accepting every other character of input. I just installed libgxim-0.3.2-4, and the problem has gone away (not a lot of time elapsed, but a good datapoint). Thanks for the quick fix.
Works for me too. Thanks.
for me and my 2nd Life client, too... :-) *OOT! OOT!* -Arne
*** Bug 488307 has been marked as a duplicate of this bug. ***
Works for me too on i386, 10 minute test ...
Updating to libgxim-0.3.2-4.fc10.x86_64 does fix the issue.
Thanks for testing. Although the package isn't yet pushed to testing even, that may be better requesting pushing to stable now.
Updating to libgxim-0.3.2-4.fc10.i386 does allxterm to work again for me, too. Sooner this gets to stable, better for everton, methinks! I also have to commend Akira for his responsiveness on this issue.
after updating to libgxim-0.3.2-4.fc10.i386, i have again keyboard in qemu and wine. thnx a lot!
As an update to comment #15, I have to report a serious regression of libgxim-0.3.2-4.fc10.x86_64 with respect to libgxim-0.3.1-1.fc10.x86_64: When running an application with a high rate of text output in XTERM, then "imsettings-applet" will grab about 10% of the CPU load, altough SCIM is not even enabled. Even worse: when I open "Input Method" while there is an active run in some xterm, then the respective window turns black, and the job is blocked forcing me to execute "killall xterm". Clicking the kill button would not allow to close the window. Both regressions can be overcome by reverting to libgxim-0.3.1-1.fc10.x86_64 for which the load of "imsettings-applet" drops back to virtually 0 and "Input Method" can be launched at will without affecting an active XTERM.
libgxim-0.3.2-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 488495 has been marked as a duplicate of this bug. ***
*** Bug 488601 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > As an update to comment #15, I have to report a serious regression of > libgxim-0.3.2-4.fc10.x86_64 with respect to libgxim-0.3.1-1.fc10.x86_64: > When running an application with a high rate of text output in XTERM, then > "imsettings-applet" will grab about 10% of the CPU load, altough SCIM is not > even enabled. Even worse: when I open "Input Method" while there is an active > run in some xterm, then the respective window turns black, and the job is > blocked forcing me to execute "killall xterm". Clicking the kill button would > not allow to close the window. > Both regressions can be overcome by reverting to libgxim-0.3.1-1.fc10.x86_64 > for which the load of "imsettings-applet" drops back to virtually 0 and "Input > Method" can be launched at will without affecting an active XTERM. Can you file a bug separately please? That might be a side-effect to take care of memory leaks perhaps though. but let me try to analyse and see if there are any possibilities to improve a performance.
*** Bug 488445 has been marked as a duplicate of this bug. ***
I should have more comment about black-out issue. this basically happens if there are no replies expected from XIM server, correctly something you have in XMODIFIERS envvar. There may be a potential issue in xterm as well since it doesn't support reconnecting XIM session when disconnected accidentally though, it's a different issue that looks like IM doesn't work after switching etc. libgxim aims to not block any events and trying to keep its working as minimum even if IM itself doesn't work. so if you have a certain step to reproduce that, that would be really helpful to get rid of that issue. Anyway, when in doubt, please feel free to file a bug against libgxim. I'll have a look and try to fix that as far as possible. Thanks,
*** Bug 488411 has been marked as a duplicate of this bug. ***
*** Bug 489131 has been marked as a duplicate of this bug. ***