>> Shouldn't we have the new symbol be in its own stanza in the symbols.map for the client library?
Ah...I didn't know about that. How does this work with the global: * catch in the MIR_CLIENT_8 stanza?
Updated anyway :)
>> With MirPointerInputEventButtons, should we provide a flexible number of buttons?
I've been thinking that once the device introspection API is available it will also be possible to obtain the identifiers for more buttons via that, then you can use the introspection API to query their names etc.
MirPointerInputEventButtons is a bit inflexible though so I've changed
>> Shouldn't we have the new symbol be in its own stanza in the symbols.map for the client library?
Ah...I didn't know about that. How does this work with the global: * catch in the MIR_CLIENT_8 stanza?
Updated anyway :)
>> With MirPointerInput EventButtons, should we provide a flexible number of buttons?
I've been thinking that once the device introspection API is available it will also be possible to obtain the identifiers for more buttons via that, then you can use the introspection API to query their names etc.
MirPointerInput EventButtons is a bit inflexible though so I've changed
MirPointerInput EventButtons mir_pointer_ input_event_ get_button_ state(MirPointe rEvent)
To
bool mir_pointer_ input_event_ get_button_ state(MirPointe rEvent, MirPointerInput EventButton)
This way the button enum is not using flags and it will be easier to expand/use other values in the future.
This way the pointer button enum doesnt have to be flags and wi to expand as time goes on.