On 2 November 2011 05:29, source liu <sourceo...@gmail.com> wrote: > But the case is different as the focus method changes, still i can > call up the *speedbar* > by key stroke, but it would no longer get focus as soon as it came > out. (as i should keep the mouse > in the region of emacs to keep emacs to hold focus). so every time i > have to move my cursor > to get the focus of the speed bar, and after i finished the stroke, > the emacs again didnt caught > focus.
Have you changed focus policies in FVWM? Because I suspect a whole lot more given the changes in Emacs that I've seen, that they've decided to do something which changes how this used to work, or more likely, it's a subtle issue with GTK3. > The problem remains when multiple windowed application such as *Gimp* > is launched, but it never > come to so critical as mouse is widely used in them. I've enjoyed so > much in keeping my hand free of > mouse when editor text with emacs. Oh look. Another GTK program. > I would not change back to the way ClicktoFocus, as i'm lovin it, is > there any way or suggestions to drive > away the problem bother me in which i mentioned above to get rid of > moving the mouse back and forth... back > and forth. Well, applications can decide for themselves which windows to focus. And I suspect that's exactly what was happening before. Certainly there's nothing inherent in the way FVWM is handling window focus which would cause the symptoms you're describing. It could more likely be that the windows you're describing, such as the speedbar, are no longer transient. This would explain the behaviour you're seeing almost. There is no way though to know why focus was stolen, although if you wanted to run: xprop -spy -d $FOO Where $FOO represents the windowid of the speedbar, then let the focus change, I might be able to gleam something. But I am not yet in a position to think this is FVWM's fault. -- Thomas Adam
