I wrote: >My department has just "upgraded" me to a new machine running FC6 - >I was previously running FC5. > >Among the several things that no longer work properly, one is >window-manager related, but rather odd. Here's what happens. > >I have a very simple desktop: a few windows, mostly xterms and >emacsen, controlled by an IconMgr in the top right. I use SloppyFocus. > >The following undesired behaviour happens: >get a window (xterm) say, move the mouse in, and type - all ok. >move the mouse to the icon manager entry for the window, and then >through the entries for some iconified windows - our window should >remain focussed. Move the mouse out in to the root window. Our window >should still have focus. Indeed, it is still highlighted, but it loses >keyboard focus - or at least doesn't respond to keyboard events. It >doesn't regain focus until the mouse has been moved into another open >window and back again. > >I most often see this when opening a window from the icon manager: >usually I then don't have keyboard focus in it. >However, it's not quite that simple, as occasionally things work when >I expect them not to. > >What I find really odd is that I'm running the exact same fvwm binaries >(fvwm 2.4.18 (or 2.4.20 - it doesn't matter)) as I was before in FC5, but >still this odd behaviour happens, so there must be some change in the >X server or the libraries to make it happen.
and Dominik reasonably asked me for the minimal example. In the course of constructing the minimal example, I noticed that my editing was being interfered with: ctrl-SP brought up an input method box, instead of setting mark in my XEmacs. On looking around, it appears that FC6 sets up something called SCIM as the input method for all programs. Once I'd disposed of SCIM, I was no longer able to re-create the problem above! I'm therefore assuming (unless and until I see the problem again) that the problem above is some kind of bad interaction with SCIM, and I don't need to look at it further.
