Re: [2/5] winex11: Splitted functions X11DRV_FocusOut and X11DRV_ReparentNotify

[Alexandre Julliard]

Sebastian Lackner <sebastian(a)fds-team.de> writes:
> ---
>  dlls/winex11.drv/event.c |   99
> +++++++++++++++++++++++++++-------------------
>  1 file changed, 58 insertions(+), 41 deletions(-)

These should go in the patches that need them. Also you should start
your series with reparent support, the rest doesn't make sense without
it.

-- 
Alexandre Julliard
julliard(a)winehq.org

[2/5] winex11: Splitted functions X11DRV_FocusOut and X11DRV_ReparentNotify

[Sebastian Lackner]

Am 25.09.2013 12:19, schrieb Alexandre Julliard:
> Sebastian Lackner <sebastian(a)fds-team.de> writes:
> > ---
> >  dlls/winex11.drv/event.c |   99
> > +++++++++++++++++++++++++++-------------------
> >  1 file changed, 58 insertions(+), 41 deletions(-)
>
> These should go in the patches that need them. Also you should start
> your series with reparent support, the rest doesn't make sense without
> it.

Well, if its just the ordering of the patches, thats surely something I
can change.

Concerning reparent support: The specification states that
-------------------
The protocol is started by the embedder. The >window ID of the client
window is passed (by unspecified means) to the embedding application,
and the embedder calls XReparentWindow()< to reparent the client window
into the embedder window.

Implementations may choose to support an alternate method of beginning
the protocol where the window ID of the embedder is passed to client
application and the client creates a window within the embedder, or
reparents an existing window into the embedder's window. Which method of
starting XEmbed is used a matter up to higher level agreement and
outside the scope of this specification.
-------------------

This means both methods are valid:
* either the client (=wine) passes its own x11 window id to the parent,
which does the reparent
* or the client itself does the reparent with the x11 window id from the
embedder

So far Pipelight [1] uses the first method, which at my opinion is
definitely preferred, as it wouldn't make that much sense to implement a
user32 -> winex11 interface, which expects xwindow-ids instead of hwnds.
A normal wine application doesn't have any way to know these xwindow ids
of foreign applications, so in fact this whole method is only possible,
when there is a linux application on the other side.

[1]
http://fds-team.de/cms/articles/2013-08/pipelight-using-silverlight-in-linux...