On 08/11/2014 03:03 PM, Jasper St. Pierre wrote:
wl_shell does exist. It's a global object that is bound by the client, using wl_registry.bind. It's as real as any other object.
What I meant was that the wl_registry::global event with the wl_shell api was not sent if the compositor does not implement the wl_shell_surface api. This makes it impossible to bind an id to the wl_shell surface api.
Since there is no id that can be used in the wire protocol to get the wl_shell::get_shell_surface request, it is as though the wl_shell object does not exist.
Even if wl_shell exists, that does not mean that all wl_surfaces are also wl_shell_surfaces. Cursor surfaces are also wl_surfaces, and those are not wl_shell_surfaces. Subsurfaces are also wl_surfaces, and those are not wl_shell_surfaces.
What exactly happens if you call wl_shell::get_shell_surface with one of these? It does not do a round trip so it cannot fail.
Why are additional objects more expensive?
Creation and destruction sends requests over the wire protocol. To avoid this you must keep them around after first creating them, rather than creating them when needed.
Why would you need cross-platform data structures, and why do you believe that the internals of the data structure has anything to do with the wire format? Multiple toolkits and Wayland compositors exist, and they all have entirely different internal data structures. They all collaborate fine.
For utility functions that are used by more than one toolkit. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
