Bug 161250
Summary: | Strange cell behavior on window focus, data entry, etc. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Aaron Gaudio <madcap> |
Component: | iiimf | Assignee: | Akira TAGOH <tagoh> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | eng-i18n-bugs, hdegoede, hensonneilneil |
Target Milestone: | --- | Keywords: | i18n |
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-09-29 05:30:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Aaron Gaudio
2005-06-21 18:54:04 UTC
I cannot reproduce either of the two problems using the current rawhide tree and metacity with click to focus as windowmanager. This could mean that the problem is fixed in newer gtk/gnome-libs in rawhide or that it is sawfish specific (more likely). Unfortunatly I don't have an FC4 install to test plain FC4. Please: -try this under rawhide and/or -file a bug against sawfish and/or -file a bug upstream* *Even if this is a gnumeric bug as a packager I'm not going to be able to fix it Okay I've experimented a little more. First, let me say I mispoke... I don't use sawfish anymore I'm running metacity (latest from FC4). Sorry for that confusion. I tried running a vnc server with twm and could not reproduce the problem. Then I ran a vnc server with metacity and could not reproduce it. After that, I tried gdmflexiserver to get another real X server, logged into a Failsafe session and tested with both twm and metacity- could not reproduce. Yet it continued to happen on my main session. After all this, I think it is an iiim issue. I had iiim running on my main server and none of the others. After shutting down the iiim service, removing the gnome-im-switcher-applet (which has started locking up anyway, and doesn't provide the chinese language that it ought to) and re-logging in, lo and behold gnumeric no longer has this behavior. So... perhaps this should be re-opened and assigned to the iiim category... Ok, reopening and asigning to iiim. Tago, Reassigning to you (after changing the component to iiim) read above why. Does it happen when you press ctrl+space to deactivate the input method after you finished to enter the data into the cell? I'm not sure what exactly are you doing during editing at the cells. I don't see any relation why this is IIIMF issue ATM. please let us know further information with the exact steps you did. I didn't do anything other than have the iiim daemon and gnome-im-switcher-applet (gimlet) running. I did not hit cntrl-space, in fact I am currently unable to add a language other than ASCII to gimlet (even though I have the le-chinput module installed). Nevertheless, when I ran gnumeric with GTK_IM_MODULE unset (I have it normally set to 'iiim'), gnumeric ran as normal. Gnumeric also runs normally now when I do not have gimlet running (but I can still have iimd running and GTK_IM_MODULE set to 'iiim'). Whether this is a gnumeric bug or an iiim bug, I dunno. Ok, which locale are you using then? My locale is the default (no $LANG set), which I assume is either C, or en_US. You mean you logged into the desktop from gdm with the English language (en_US) right? if you aren't sure which locale are you using, please try 'locale' on the terminal program like gnome-terminal. I logged into gdm without selecting a language. Typing locale produces this: LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= I can try forcing this to en_US and see what happens... Okay... logging in after manually selecting 'en_US' seems to keep gimlet from freezing up, and Chinese is once again listed as an available language (and in fact can be used). However, the gnumeric problem persists. I am setting GTK_IM_MODULE=iiim in my ~/. bashrc, so everything in my desktop has it by default. If I run gnumeric using 'GTK_IM_MODULE= gnumeric', I don't get the problem. The problem exists no matter what language I have selected via gimlet (Latin, ä¸æ, or ASCII). I've also tried logging in as another user without GTK_IM_MODULE set, in the en_US locale, with gimlet running, and I get similar behavior in gnumeric when I manually set GTK_IM_MODULE=iiim. Of note- when using iiim, gnumeric doesn't let me use the chinese input when editing a cell (by clicking the cell and editing it), but if I go to the input window and type, I can enter in Chinese there. Maybe this just boils down to poor input method handling in gnumeric? If you concur, I'll refile this upstream. But I think the issue with the 'POSIX' locale messing up gimlet is a real problem. Maybe it's a holdover from my FC4 upgrade? Is there a way to set the 'System Default' locale in gdm to be en_US? Ok, confirmed. though there is a workaround for this issue on gnumeric as other applications works, the real problem is in IIIMF. I'll investigate this then. I'm sorry, we do not have enough time to do fix this issue. please contact upstream directly if you really need to get this fix. thanks. This seems to be fixed in the latest FC5 release of gnumeric anyways. Thanks. If you care about social media security, i find free phone spy apps cheacting spouse: https://celltrackingapps.com/free-android-spy-apps-cheating-spouse/ |