Enums, bitfields and wl_arrays

[Daniel Stone]

Hi,

On 8 October 2015 at 21:13, Daniel Stone <daniel at fooishbar.org> wrote:
> On 5 October 2015 at 21:31, Victor Berger <victor.berger at m4x.org> wrote:
>> In this case, for a "closed" enum, the binding can decide to ignore any
>> value received on the wire that is not described in the XML, as anyway, the
>> client would not know what to do with it (and if they knew, they should be
>> using a more recent version of the binding).
>
> This should never happen. The compositor is responsible for tracking
> which version the client has bound, and not sending it values it
> doesn't know what to do with.
>
> I've heard mention that xdg-shell allows this, but I also can't see it
> anywhere in the spec. Jasper?

Whoops ...

9:18 PM <Jasper> daniels, sorry, what were we talking about with enums?
9:20 PM <daniels> Jasper: people are concerned that xdg-shell has
'open' enums, in that a compositor can send a configure event with
enum values unknown to the client
9:20 PM <Jasper> daniels, that's correct
9:20 PM <daniels> Jasper: bollocks, really?
9:20 PM <Jasper> daniels,
http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n321
9:23 PM <daniels> Jasper: ah, i see - that does make quite a bit of sense
9:23 PM <daniels> Jasper: but i do wonder if we should bound that by
what the client actually supports, e.g. don't send gnome-specific
values unless the client has bound gtk_shell
9:23 PM <Jasper> daniels, the state mechanism is designed to solve a
very specific race condition, so we don't want people inventing their
own protocols to do the same.
9:24 PM <daniels> Jasper: oh, indeed
9:24 PM <Jasper> daniels, I would be fine with that, but I'm not sure
it helps Rust clients.
9:24 PM <daniels> Jasper: indeed, more of a general musing
9:24 PM <daniels> Jasper: thanks for pointing that out; not sure how i missed it

How does that play with Java/Haskell/etc? Would that just degenerate
into a plain undecorated uint, or ... ?

Cheers,
Daniel