[PATCH V2] wayland.xml: add "enum", "bitfield" and "is_bitfield" attributes
dev at mgautier.fr
Wed Sep 24 02:01:55 PDT 2014
Le 22/09/2014 23:47, Jason Ekstrand a écrit :
> I would certainly like to do this, but wl_output.transform is
> always passed as a signed integer and I'm not sure if this
> is a
> bitfield or not. I assumed it is, because you can
> reconstruct "270", "flipped_90", "flipped_180" and
> out of "90", "180" and "flipped". Or is this just a
> It's both... More in a couple of lines
> Also, is there a reason why some enumerations are passed as
> a signed integer (wl_output.subpixel) and others aren't?
> > So, what do other people think of the idea in this patch?
> I'm a little unsure. I think trying to completely solve this
> problem in a way that will truly make strongly typed languages
> happy is insanity. That said, I'm cautiously ok with defining
> bitfields and enums as long as we are very careful in scoping
> what "bitfield" and "enum" mean. A "bitfield" should have
> only power of two values and the result should always be
> interpreted as an OR of those values. An enum should have
> every possible value enumerated. If anyone has a good example
> of something that validly doesn't fit into either of these,
> please speak up.
> xdg_shell.resize_edges. It is both a bitfield (top / left / right
> / bottom edges are powers of two) and an enum (top right / bottom
> left corner convenience values, with top / bottom being left out
> as it is undefined).
> That's an example of an enum with cleverly chosen values so that you
> can do bitfield-like things. What I'm more concerned about is
> something where it would be impractical to actually enumerate all of
> the possibilities in the protocol spec but it's not a bitfield either.
xdg_surface.state seems to correspond to the description.
It's an enum, but DE can extend this enum with its own values.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel