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 "flipped_270" out of "90", "180" and "flipped". Or is this just a coincidence? 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.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
