[Bug 43711] XReparentWindow __wine_x11_whole_window

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=43711

--- Comment #2 from Stan <markau0 at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.