Red Hat Bugzilla – Bug 161250
Strange cell behavior on window focus, data entry, etc.
Last modified: 2007-11-30 17:11:08 EST
Description of problem:
Under certain (common) circumstances, gnumeric acts as if I have started typing
in a cell when I haven't, which forces me to enter Escape to cancel it, or else
it ends up overwriting cell data.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Window Focus problem-
1. Enter some data into some cells in gnumeric sheet
2. Leave the cell selection on a cell with data in it
3. Change window focus to another window in your window manager (I'm using
sawfish with [sloppy] mouse focus)
4. Change window focus back to gnumeric
Data Entry problem-
1. Enter some data into a cell
2. Select the cell directly above the cell you entered data into in step 1.
3. Enter data into the selected cell and press 'Enter'
In the window focus case, the gnumeric begins editing the currently selected
cell as soon as window focus returns to gnumeric.
In the data entry case, gnumeric begins editing the cell immediately below the
cell you just entered data into.
In the window focus case, nothing should happen when focus is returned to the
In the data entry case, the cell immediately below the edited cell should be
selected, but editing should *not* begin.
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.
-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:
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.