https://bugs.winehq.org/show_bug.cgi?id=43711
Bug ID: 43711 Summary: XReparentWindow __wine_x11_whole_window Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: markau0@lycos.com CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
I'm not sure if this is a bug or I'm just not aware of how to do it.
When a GetPropA(hWnd, "__wine_x11_whole_window"); is sent from a Wine app to a Linux app and reparented using XReparentWindow, the Wine app's menus and mouse movements are being referenced from the screens 0,0 instead of the Linux parent windows 0,0.
I've tried sending notify events to the Wine "__wine_x11_whole_window" and various other things.
If I add a XEMBED NOTIFY message then the menus and mouse are ok, but Wine's XEMBED is broken when reparenting in a Linux app and produces windows with problems.
https://bugs.winehq.org/show_bug.cgi?id=43711
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=39440 Product|Wine-staging |Wine Component|-unknown |-unknown
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- You opened this bug report in the Wine Staging category, but I do not see how this should be a Wine Staging regression. Moving to the Wine product.
Besides that, reparenting windows without sending proper messages is expected to cause problems. Wine expects that applications correctly follow the XEMBED protocol. It would be more useful to focus your investigation on this part. What is the problem with XEMBED? And can you provide a simple testcase without involving a lot of third party components?
Please note that Pipelight (deprecated now) has been using Wine + XEMBED successfully for a couple of years already. Most of the time when people experience issues with XEMBED, the real issue is that Linux apps do not correctly follow the XEMBED protocol. QT widgets for example have multiple bugs and pass invalid parameters in their notification messages.
https://bugs.winehq.org/show_bug.cgi?id=43711
--- Comment #2 from Stan markau0@lycos.com --- (In reply to Sebastian Lackner from comment #1)
You opened this bug report in the Wine Staging category, but I do not see how this should be a Wine Staging regression. Moving to the Wine product.
Besides that, reparenting windows without sending proper messages is expected to cause problems. Wine expects that applications correctly follow the XEMBED protocol. It would be more useful to focus your investigation on this part. What is the problem with XEMBED? And can you provide a simple testcase without involving a lot of third party components?
Please note that Pipelight (deprecated now) has been using Wine + XEMBED successfully for a couple of years already. Most of the time when people experience issues with XEMBED, the real issue is that Linux apps do not correctly follow the XEMBED protocol. QT widgets for example have multiple bugs and pass invalid parameters in their notification messages.
I opened it in Wine staging because it seemed the best place, maybe it wasn't.
Pipelight does work from what I've seen.
The problem I'm talking about affects multiple programmers, not just me.
A Linux shared library communicates with a Wine server.
The Wine server creates a Windows window and then sends the __wine_x11_whole_window handle to the Linux shared library which then gets a parent handle and reparents __wine_x11_whole_window to it.
After that is when the problems start.
The Linux shared library can't seem to setup an X11 event handler that works with the temporary X11 display that needs to be used, so event handling from the Linux shared library doesn't seem to be possible.
As I've said, the reparent leaves the Windows server with menus and mouse still thinking that the 0,0 origin in the screen/display origin and not the parents 0,0 origin, so even though the reparented window appears within the parent ok, the mouse and menus are not ok.
So if anyone knows what is going on, please let me know.
The other problem is that if XEMBED NOTIFY is included in the reparenting then the mouse/menus are at their expected positions but it leads to screen display issues with things like half the screen sometimes appearing etc etc.
This is some of the Linux shared library code
Without XEMBED NOTIFY, menus/mouse are in the wrong positions.
With XEMBED NOTIFY, menus/mouse are in the right positions but window corruption results.
child is the GetPropA(hWnd, "__wine_x11_whole_window") handle set to the Linux shared library from a Wine server.
display = XOpenDisplay(0); XReparentWindow(display, child, parent, 0, 0); XMapWindow(display, child); XSync(display, false); XFlush(display); XCloseDisplay(display);
then a message sent to Wine server to run ShowWindow and UpdateWindow
With XEMBED NOTIFY
display = XOpenDisplay(0); XReparentWindow(display, child, parent, 0, 0); sendXembedMessage(display, child, XEMBED_EMBEDDED_NOTIFY, 0, parent, 0); XMapWindow(display, child); XSync(display, false); XFlush(display); XCloseDisplay(display);
then a message sent to Wine server to run ShowWindow and UpdateWindow
https://bugs.winehq.org/show_bug.cgi?id=43711
--- Comment #3 from Stan markau0@lycos.com --- btw the above code is actually based on the Pipelight code and it works for Pipelight but not for a Linux shared library coupled to a Wine server.
https://bugs.winehq.org/show_bug.cgi?id=43711
--- Comment #4 from Stan markau0@lycos.com --- Seeing as how I can't use XEMBED, I want to use straight out reparenting with the Wine window GetPropA(hWnd, "__wine_x11_whole_window") but then the reparented child thinks it's at 0, 0 and the parent window might be at 252, 29 or whatever.
How do I get the parent and child to sync when I've only got a Windows message event loop to work with ie DefWindowProc
I've tried sending a ConfigureNotify event to the Wine child window using the parent's x y coords and it doesn't do anything.
https://bugs.winehq.org/show_bug.cgi?id=43711
Stan markau0@lycos.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also|https://bugs.winehq.org/sho | |w_bug.cgi?id=39440 |
-
wine-bugs＠winehq.org