[PATCH libinput] Add libinput_device_pointer_has_button over the plain has_button

[Peter Hutterer]

On Mon, Feb 16, 2015 at 01:19:38PM -0800, Bill Spitzak wrote:
> On 02/16/2015 01:05 PM, Peter Hutterer wrote:
> 
> >besides, this doesn't really help, you usually want to know if a device has
> >a specific button well before you get the first event. so the real source
> >to use here would be the capability. That could make sense, I'll have a look
> >at this, the API would be something like:
> >
> >libinput_device_has_button(LIBINPUT_DEVICE_CAP_POINTER,
> >                            button);
> 
> Yes that sounds like what I was thinking of.
> 

I had a look at this and I don't think this is a good idea, it makes the API
inconsistent and harder to use.

First, two out of the current five capabilities don't make sense for this
call. keyboard and touch don't have buttons.
This call also doesn't really work for tablet devices, or at least only
inconsistently - on those it's the tool that has the button, not the tablet
itself.
The logical extensions of this API are _has_key() and has_axis()
has_key() only makes sense on keyboard and buttonset devices, so a generic
version is worse than a specific one.
has_axis() is even more complicated, we use different enums for axes in the
tablet and buttonset case so again a generic version of this call won't
work.

So I'll stick with the libinput_<type>_has_button approach.

Cheers,
   Peter