On 01/02/2015 04:31 AM, Pekka Paalanen wrote:
On Mon, 22 Dec 2014 14:05:08 -0800
Bill Spitzak <spit...@gmail.com> wrote:
PS: How does an intermediate compositor, which has to both be a server
and a client, use these two libraries at the same time? There appear to
be some name conflicts, such as two different struct wl_display objects.
Those are type name conflicts only. All the duplicate-but-not-the-same
types are opaque, and accessed only inside the correct library where it
came from. Naturally that means that the program writer needs to
always know if a pointer to a wl_display is for the server or client
side and use the corresponding functions.
We shouldn't have any same named public functions in both server and
client libraries with different code, nor any public same named
transparent types with different definitions.
Thanks, that is what I thought was happening. I am still trying to
figure out an introduction text for the two libraries and I think this
information should be added to the libserver one.
The deprecated transparent server side type struct wl_buffer is the
only conflicting one that I know of, and conflicts with an opaque client
side type which is actually a struct wl_proxy. I don't recall having
any others.
Further conflicts may be found in the library internals, like a third
definition of struct wl_buffer local to src/connection.c.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
