<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 8, 2014 at 7:51 AM, Stephen Lee <span dir="ltr"><<a href="mailto:stephenl7797@gmail.com" target="_blank">stephenl7797@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hey, I'm working on my own window manager and I'm having a hard time tracking through the Weston code to see where a function is registered as part of an interface. Right now I am looking at surfaces. I guess my question is more related to the relation of surface and shell surface. In the main compositor file, their is a struct called surface_interface which is passed into 'wl_resource_set_implementation' along with a resource 'wl_surface_interface'. Okay, that is clear enough, but now in shell.c their are a bunch of functions in the 'shell_surface_implementation' struct which again has a resource created and implemented for 'wl_shell_surface_interface'. Also in the module_init their is a global created to 'bind' the compositor to another struct for 'desktop' stuff. How do all of these things relate? Is surface similar to a base class and shell_surface similar to an inherited class?</div>


</blockquote><div><br></div><div>Hey<br><br></div><div>So, there's four different objects you've found: wl_compositor, wl_surface, wl_shell and wl_shell_surface.<br><br>These are four different protocol objects and you can all find their interfaces separately in the protocol XML file [0]. That's what the "interface" structs are implementing inside Weston: the request handlers for these interfaces.<br>

<br></div><div>wl_shell_surface is a "role" for wl_surface, which is sort of like an inherited class, but not quite. Instead of saying "wl_shell_surface extends from wl_surface", you make a wl_surface, and then make a wl_shell_surface from that wl_surface, which tags it as a wl_shell_surface. You can mostly treat it as inheritance for the purposes of understanding.<br>

<br></div><div>A wl_surface is a bag of bits where you can attach an output buffer, and also get pointer input on and so forth. Attaching a wl_shell_surface role allows you to put the window on screen, drag it around, make it resizable, maximize it, etc. These are things that other UIs like cars, TVs, and some tablet interfaces might not want, so they're hidden in an optional portion of the spec.<br>

<br></div><div>Then there's the two factory objects. The way protocol extensions work, there's a series of globals, which is how these objects get created in the first place. The wl_compositor global creates wl_surfaces, and the wl_shell global creates wl_shell_surfaces.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div></div>