Enums should be their own type so could specify that you are passing an enum by using type="enum.<enum name>". For the error event where any enum can be passed, we could use type="enum". When the enum is specified in another interface, we could use type="enum.<interface>.<enum name>". I'm not sure how this should interact with multiple versions or how it currently does. We could also just use type="enum" for these cases. Adding enums as types serves as documentation and adds type safety for generated code in languages which features such for enums. The effect on C source and ABI should be none.
Given that enum are also used for bitfields, we should add a separate type for that. So I suggest we use type="enum" and type="flags", and reference the enum using enum="<enum-name>" and perhaps reuse the interface attribute to specify in which interface the enum resides.
Bitfield enums should be specified in a linear fashion. This makes the value attribute on enums less required, could that be removed or made optional? I noticed that wl_shell_surface.resize is missing the values 3 and 7. Where those previously defined values? Could those be specified with an unsupported attribute instead of defining values?
(In reply to comment #2) > Bitfield enums should be specified in a linear fashion. This makes the value > attribute on enums less required, could that be removed or made optional? > > I noticed that wl_shell_surface.resize is missing the values 3 and 7. Where > those previously defined values? Could those be specified with an > unsupported attribute instead of defining values? The resize enum is laid out such that you can bitwise-or LEFT and BOTTOM and get LEFT_BOTTOM.
Oh, that should be a bitfield then. To maintain your precious backwards compatibility we could add none, top_left, bottom_left, top_right and bottom_right as presets. Say: <preset name="top_left" value="top left" />
(In reply to comment #4) > Oh, that should be a bitfield then. To maintain your precious backwards > compatibility we could add none, top_left, bottom_left, top_right and > bottom_right as presets. Say: <preset name="top_left" value="top left" /> What problem are you trying to fix?
The problem of finding out which values are valid for arguments when reading protocol files and the lack of type safety when generating interfaces for other languages.
Note that adding this does not have to break backward compatibility with existing C source code, ABIs or protocol files. I just think that making these things higher level in the protocol files makes them easier to understand, and allows better code and documentation to be generated from them.
Not going to change this, what we have works well enough and we can document the use of enums where necessary.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.