Thomas Adam schrieb:
Hi Chtistian,
On Wed, Aug 31, 2011 at 06:54:37AM +0200, Christian Ehrlicher wrote:
sorry for the late reply but I think I found the culprit. There are
some hacks in events.c/focus.c (focus_force_refresh_focus and
refresh_focus) which seem to steal the focus from the focus proxy
and therefore kill the xembed implementation in qt.
In the case of ddd which still exhibits this, the events are so fast that
any client (FVWM in this case) would simply get confused as to which window
is supposed to receive focus.
Interesting - I've another focus problem (qt is loosig focus when a
popup menu is closed, but only sometimes - when I do the same action
again all works fine. Is this maybe related?
Thanks for looking in to this though. I think we can do better than this,
and I'm not necessarily proposing we introduce another BugOpts option. Most
notably there's lots of cases where looking at the specific focus model and
taking action on it is needed -- the "hack" you speak of, from my own
investiagations really does apply to actions which are explicit. Your
example application shows this well.
The comment to these functions is also interesting:
/* This takes care of some buggy apps that forget that
* one of their dialog subwindows has the focus after
* popping up a selection list several times (ddd,
* netscape). I'm not convinced that this does not
* break something else. */
Is it possible to add a config option so the user can choose if he
needs the hack or not?
Possibly -- but I've another idea I'll try out at the weekend, if that's OK?
I'll let you know what I come up with.
No problem - now that I've a valid (and simple) testcase I can test if
you need some help.
Christian
