FVWM: Problem with xembed and qt

[Christian Ehrlicher]

Hi,

I've a problem with xembed + qt (4.7,4.8) + fvwm2 (2.6.1). The attached
testcase works fine with kde.

How to reproduce:
- compile the two programs (qmake, make)
- start 'x11embedwidget'
- start 'x11embedcontainer <winId>' whith the winid provided by x11embedwidget

On KDE I now see a red window and when pressing a key both applications
receive this event (the widget will receive it twice - don't know if this is
correct but that's another problem).

On Fvwm2 I see a blue window and when I resize the window a small red area
appears. Key events are only visible on both applications when the mouse
cursor is in the blue area. In the red area the embedcontainer doesn't get
keyevents at all.
When I comment out the calls to 'setGeometry(0,0,100,100)' in one of the
applications, I only see the red window. The problem with the keys then only
appears sometimes (maybe depending on the focus).

I hope someone can take a look on this or at least can give me some hints
where inside the fvwm source the xembed handling occours so I can look by
myself.


Thx,
Christian Ehrlicher

[Thomas Adam]

Post by Christian Ehrlicher
Hi,
I've a problem with xembed + qt (4.7,4.8) + fvwm2 (2.6.1). The attached
testcase works fine with kde.
- compile the two programs (qmake, make)
- start 'x11embedwidget'
- start 'x11embedcontainer <winId>' whith the winid provided by x11embedwidget
On KDE I now see a red window and when pressing a key both applications
receive this event (the widget will receive it twice - don't know if this is
correct but that's another problem).

It's correct.

Post by Christian Ehrlicher
On Fvwm2 I see a blue window and when I resize the window a small red area
appears. Key events are only visible on both applications when the mouse
cursor is in the blue area. In the red area the embedcontainer doesn't get
keyevents at all.

That's right again, because one is a child of the other internally.

Post by Christian Ehrlicher
When I comment out the calls to 'setGeometry(0,0,100,100)' in one of the
applications, I only see the red window. The problem with the keys then only
appears sometimes (maybe depending on the focus).
I hope someone can take a look on this or at least can give me some hints
where inside the fvwm source the xembed handling occours so I can look by
myself.

But FVWM isn't doing anything wrong that I can tell -- and FVWM isn't even
XEmbed aware. All that's happened here is yout widget has been reparented
inside the container you've setup -- which itself is managed by FVWM. Key
presses to the application (top-level) will propagate down to the
descendents like any other window.

Of course, this will depend upon the attributes you've set for the container
as to how it is to behave if it is ever reparented.

I've not looked at your source code, as I have no interest and don't
understand Qt; something, incidentally, I want to remain clueless about.

-- Thomas Adam

[Christian Ehrlicher]

Post by Thomas Adam

Post by Christian Ehrlicher
Hi,
I've a problem with xembed + qt (4.7,4.8) + fvwm2 (2.6.1). The attached
testcase works fine with kde.
- compile the two programs (qmake, make)
- start 'x11embedwidget'
- start 'x11embedcontainer<winId>' whith the winid provided by x11embedwidget
On KDE I now see a red window and when pressing a key both applications
receive this event (the widget will receive it twice - don't know if this is
correct but that's another problem).

It's correct.

Post by Christian Ehrlicher
On Fvwm2 I see a blue window and when I resize the window a small red area
appears. Key events are only visible on both applications when the mouse
cursor is in the blue area. In the red area the embedcontainer doesn't get
keyevents at all.

That's right again, because one is a child of the other internally.

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.
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?

btw: you don't make it easy to me to argue pro using fvwm2 in our
environment :(


Christian

[Thomas Adam]

Post by Christian Ehrlicher
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.

Post by Christian Ehrlicher
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.

See also:

http://developer.qt.nokia.com/forums/viewthread/1243

-- Thomas Adam

[1] http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html#id2448072

[Christian Ehrlicher]

Post by Thomas Adam

Post by Christian Ehrlicher
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.

Post by Christian Ehrlicher
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?

"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

[Thomas Adam]

Hi Chtistian,

Post by Christian Ehrlicher
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.

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.

Post by Christian Ehrlicher
/* 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.

-- Thomas Adam

[Christian Ehrlicher]

Post by Thomas Adam
Hi Chtistian,

Post by Christian Ehrlicher
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?

Post by Thomas Adam
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.

Post by Christian Ehrlicher
/* 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

[Thomas Adam]

Hi,

Post by Thomas Adam
Hi Chtistian,

Post by Christian Ehrlicher
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?

Can you send through a minimal application for this? I've never
programmed with Qt before.

-- Thomas Adam

[Christian Ehrlicher]

Post by Thomas Adam
Hi,

Post by Thomas Adam
Hi Chtistian,

Post by Christian Ehrlicher
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?

Can you send through a minimal application for this? I've never
programmed with Qt before.

No, not for this problem - it occurs now and then during 'normal' work
and I ca reproduce it in our application with nearly 90 percent. But as
soon as I try to factor it out into a testcase it works like a charm...

Christian

[Thomas Adam]

Post by Christian Ehrlicher

Post by Thomas Adam
Hi Chtistian,

Post by Christian Ehrlicher
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?

You very nearly took me up the wrong garden path with your focus suggestion,
you know. :P

It has nothing to do with focus at all, and everything to do with
StructureNotify and SubstructureRedirect events.

I should have realised myself when running this under FVWM what was
happening -- the client embedded in the top-level window should never have
been where it is -- it's meant to be the main window inside the reparented
one. That's what I missed early on, so I'm sorry for being slow.

I've a fix here which seems to be working and will commit to CVS over the
weekend sometime.

-- Thomas Adam

[Christian Ehrlicher]

Post by Thomas Adam

Post by Christian Ehrlicher

Post by Thomas Adam
Hi Chtistian,

Post by Christian Ehrlicher
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?

You very nearly took me up the wrong garden path with your focus
suggestion, you know. :P

Hey - the window is loosing the focus so it's a focus problem ;-)

Post by Thomas Adam
It has nothing to do with focus at all, and everything to do with
StructureNotify and SubstructureRedirect events.
I should have realised myself when running this under FVWM what was
happening -- the client embedded in the top-level window should never have
been where it is -- it's meant to be the main window inside the reparented
one. That's what I missed early on, so I'm sorry for being slow.
I've a fix here which seems to be working and will commit to CVS over the
weekend sometime.

This sounds promising - I can test it on monday and will report back then.

Thx,
Christian

[Thomas Adam]

Post by Christian Ehrlicher

Post by Thomas Adam
I've a fix here which seems to be working and will commit to CVS over the
weekend sometime.

This sounds promising - I can test it on monday and will report back then.

See patch attached.

Note that in the case where a window was previously mapped (and hence
already had a requested geometry and gravity set on that window) which had
them been reparented by another, we were always using a gravity which was
incorrect.

As for key-bindings propagating from the reparented instance (child) to the
parent, there's a discrepancy between window managers. FVWM (and TWM
therefore) will send synthetic key events to the application when the
pointer is on its window (FW_W_FRAME(fw)). This is good for your
application, because the XEmbed application is told to forward such requests
through, and in doing so generates a second synthetic key event, which is
why you see the same key propagated from your widget to its container [1].

In the normal case though, what's happening is that your widget window will
typically always receive real key events, and those won't get sent anywhere
else other than to the receiving window. This is correct behaviour.

But this problem I'm describing certainly doesn't have anything to do with
focusing problems with refresh_focus() and friends.

-- Thomas Adam

[1] Using a focus policy of ClickToFocus will increase the likelihood of
sending synthetic events through to the application, because once the window
has focus it will remain that way until clicked elsewhere.

[Harry portobello]

hi,

Post by Christian Ehrlicher
This sounds promising - I can test it on monday and will report back then.

i think i have similar problems to you - was this fixed in fvwm ever?

Harry

[Thomas Adam]

Post by Harry portobello
hi,

Post by Christian Ehrlicher
This sounds promising - I can test it on monday and will report back then.

i think i have similar problems to you - was this fixed in fvwm ever?

I fixed it in CVS, and it will form the 2.6.4 release of FVWM when I release
it.

-- Thomas Adam