Interfaces to objects

[Jasper St. Pierre]

On Mon, Aug 11, 2014 at 7:10 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> 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.
>

OK, sure. It's never going to come across as an error on the wire, though.
It's just never going to find the global, and likely spew an error message
to the user and die, or spin forever waiting for it to show up.

You weren't clear here.

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.
>

wl_display has an 'error' event which is required to be a fatal error to
the client. For subsurfaces, it will send out an error telling you that the
surface already has a role. I don't think Weston will send out errors if
you have a surface that has the role of the cursor, simply because it's not
really marked as a surface role internally. This is a Weston bug that we
should fix.

We're talking about standardizing on role behavior in the xdg-shell thread.

 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.
>

The expected use case for surface roles is to create them immediately after
the wl_surface, as right now you cannot repurpose a surface as a different
role.

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.
>

Can you give an example for this? We've talked about adding more utility
methods like libwayland-cursor. That we do without standardizing on
internal data structures right now.

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140811/da28dda2/attachment-0001.html>