Thomas Adam schrieb:
On Tue, Jun 07, 2011 at 12:58:07PM +0200, Christian Ehrlicher wrote:
It looks like fvwm doesn't move the child window to the new position
when it gets reparented. E.g. when I move the child to 0,0 (screen
coords) before reparenting, then reparent it to the new window, the
child still is at 0,0 (screen coords) and not 0,0 (parent coords).
When I do a XMoveResizeWindow to 0,0 afterwards, the child correctly
moves to 0,0 (parent coords). This doesn't look like a Qt-only
problem to me.
It has to be -- FVWM can do nothing about the reparented applications other
than send them the necessary messages about what happens to its frame
window.
Now I only don't understand the problem with the key events. It
looks like the child is eating the keyevents or they're not given to
the parent. This works fine with KDE but I could not find anything
inside kwin sources which could explain this... any ideas?
Well, from [1]:
"Unfortunately, there are no such messages like WindowActivate or
WindowDeactivate in the X protocol. Instead, a window knows that it is
active when it receives keyboard focus (FocusIn event with certain modes) or
looses it (FocusOut event with certain modes). This applies to embedded
child windows only, when the mouse pointer points onto one of the child's
subwindows in the very moment the window manager puts the X focus on the
toplevel window. For that reason, XEmbed requires the embedders to pass
XEMBED_WINDOW_ACTIVATE and XEMBED_WINDOW_DEACTIVATE messages to their
respective clients whenever they get or loose X keyboard"
All FVWM is doing is sending the key event to the application -- be it the
parent or the child because it effectively sees both as two separate
problems due the fact that your child window isn't doing what it's supposed
to with respect to the parent.
I really don't see how this is anything to do with FVWM. xev(1) shows the
event propagation to be doing the correct thing.
Hi,
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.
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?
Thx for your help,
Christian Ehrlicher
