On Tue, 15 Sep 2020 15:31:40 +0200 Jan Bruns <c...@abnuto.de> wrote: > Pekka Paalanen wrote: > > >> What I can tell about wl now is that I haven't yet identified lines of > >> text or code about it, that might probably be of not so much relevance, > >> given specific sets of workflows. That's bad news to me, a > >> disappointment, because making things easier for the distant future was > >> my only motivation for focussing on wl a bit. > > > > Sorry, but I do not understand what you are talking about. If your goal > > is not to write a program that uses Wayland in your preferred language, > > then what is it? > > > > What workflow are you referring to? > > Well, why was it almost necessary to ask this mailing list about basic > API usage?
Hi, I would think that writing language bindings for libwayland that does not already have any bindings for the target language is quite an advanced use case. After all, you won't be using the normal libwayland API, but you have to use the low-level API and write a code generator that suits your target language while using the low-level API correctly. You have to understand precisely how the XML definitions are turned into concepts on the wire, which is something you'd never care about if you used the ready-made C or other language bindings. That is definitely not something I would recommend anyone starting to learn Wayland to begin from. You get hit by the full complexity and historical baggage all at once. Even the normal libwayland API is considered something mostly for toolkit developers. Wayland itself is a fairly low-level protocol. You need quite a lot of "meat" around it in a client to have it actually show a window. Writing a full Wayland protocol marshalling implementation in a new language from scratch is also an advanced topic in my mind. You don't need to really know the libwayland low-level API, but you need even more knowledge about how the XML maps to data on the wire and how object IDs are managed. Again you would need to know none of that if you were to use ready-made language bindings. I don't see anything "basic" in what I understood that you aimed to do: use Wayland from a language that has no (I assume) prior art on Wayland. > For example, the vulkan API claims to support a "wayland" interface. > Great words, relative to the situation the protocol probably doesn't yet > deliver the functionality required to fulfill that claim. What that > mentioned interface really is about is called libwayland. But what > happens if the wayland protocol gets to the point of supporting the > claim directly, without libwayland interaction? What do you mean by all that? > Would they introduce > structures named like > > VK_STRUCTURE_TYPE_WAYLAND_NOLIBWAYLAND_SURFACE_CREATE_INFO_KHR or > VK_STRUCTURE_TYPE_DIRECTWAYLAND_SURFACE_CREATE_INFO_KHR, in addition to > the existing VK_STRUCTURE_TYPE_WAYLAND_SURFACE_CREATE_INFO_KHR? I cannot guess what you are thinking here. If Vulkan didn't use actually implemented types from *some* Wayland implementation in its API, what could it use? For comparison, VkXcbSurfaceCreateInfoKHR uses libxcb types in the API, so you are forced to use libxcb if you want to use that. Likewise in EGL, you are forced to use libX11 if you want to use the EGL X11 platform, and libwayland-client if you want to use the EGL Wayland platform. In any case, Wayland per se is not tied to any particular implementation, even through libwayland is the authoritative implementation. You are free to write a Wayland protocol implementation from scratch with your own language. If the implementation is correct, it will have no trouble as a client communicating with a Wayland compositor written in C and using libwayland-server, for instance. Or vice versa, your own compositor in your own language can well accept any existing client written in any language. It is also possible to replace libwayland in one process with a completely different but ABI-compatible implementation. Just make sure all pieces in the process use the same implementation. Between processes, each process can use a totally different Wayland implementation if you want to, as long as they all talk the same binary wire format. Thanks, pq
pgpjh2ToeDb2s.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
