Help wanted: Implementing Wine dlls that need access to X11 commands.

[Alexandre Julliard]

Robert North <7ownq0k402 at sneakemail.com> writes:

>         But note that this would reqire some patching to the x11drv
> dll to do the following
>                 1. decode the messages.
>                 2. enable the messages for a given window and display.
>         But I'm assuming that changing the x11drv code could cause
> severe regressions to wine.
>         I'm therefore assuming that it's good manners to avoid
> fiddling with x11drv code till the
>         wintab driver implementation is known to be adequate.

I don't think it would necessarily cause regressions to simply add
handling for new events, since it shouldn't require changing the
existing event handling. But anyway writing a separate prototype first
is certainly a good idea.

>         Now, as it turns out, the methods to interrogate a wintab
> message queue are extremely similar to those to interrogate an X11
> message queue.
>             So that's +1 to giving wintab it's own X11 message
> queue. (Or possibly even one X11 msg queue per tablet context!).
>             A simple X11<->wintab mapping can be implemented, and no
> additional queue data structs are needed in the wintab
> implementation.

I'm not convinced you can avoid managing an event queue for wintab
events; from a quick look at the spec I doubt you can simply map the
wintab functions to X11 queue functions.

>             I think after all that complexity, that's +4 or more to
> X11 message queue implementation, and for wintab at least, avoid the
> wine message queue.

I agree you probably don't want to store wintab events in the Windows
message queue. But that doesn't mean you have to create your own X
connection and event loop, you can simply retrieve the events from the
normal X event loop and store them into the wintab queue.

-- 
Alexandre Julliard
julliard at winehq.com