Re: master 3b41141708: Expose the name of an event's input device to Lisp

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That suggests a different strategy: produce different input event
> types from each such device.  That'd leave the device dependency to
> low-level code, and let the application level deal with event kinds
> and not with device types.  I think this is a better abstraction, if
> it's possible/feasible.

I don't think it's feasible, especially since there are too many
different kinds of events, and with some of them those dfferent kinds of
events simply cannot work.  (Think single character keyboard events.)

> We have been burned by modeling the application-level features on the
> particular X implementation and low-level details.  It took us
> literally decades to get rid of X-specific code and features, let
> alone API names, and move to exposing more general and more adaptable
> APIs to applications.  I was there when this hard lesson was learned,
> and I'd rather we didn't repeat those mistakes.

This API is not X specific at all; in contrast, an X-specific API would
be to expose the list of device valuators and "classes", containing
various flags.

> Let's see from the get-go how this kind of functionality can be
> expressed in device-independent and window-system independent ways,
> and design the APIs accordingly.  For that, we need to define what are
> the aspects that applications would like to know about when dealing
> with these input events, and then see how this could be abstracted or
> generalized to any input system we support now and can envision to
> support in the future.  E.g., what about GPM and xt-mouse on TTYs?
> what about window-systems that aren't based on X? etc. etc.

When designing this feature, and why I purposely didn't design it based
on the X concepts of device axises and classes, I worked from two
directions: it should be possible to extract the type of a device
(i.e. tell between a touchpad, a keyboard, a pointer, and a piano), and
when possible (i.e. supported by the window system), it should be able
to tell individual devices apart.  The current API achieves the first
goal by giving each device a "name", which contains enough information
to determine the device type, and it also achieves the second goal by
guaranteeing that the device names are unique to each device on window
systems which support that, such as X and Wayland.

Each window system can then define a function for `device-class', which
returns the type of a device based on the name given to it.

This feature was already implemented not just on X, but also on PGTK,
which means it also works well with the very different input subsystems
of Wayland and Broadway.  I also wrote the code to make it work with NS,
but it hasn't been tested yet.  As for gpm-mouse and xt-mouse, their
mouse movement is simply reported as the "core pointer" device, which
tells any code that might want to perform a specific action based on the
device type that the type could not be determined.

> That doesn't mean you want to know about the device, it rather means
> you want to know the keyboard layout: an entirely different aspect,
> and not specific to any OS.

You would still need to be able to identify the keyboard in order to
know its keyboard layout, at least on X.

> IMNSHO, it's too bad we rush into implementing such features without
> any discussion.  See above about the alternatives that, at least at
> this time, seem much better to me than dragging the low-level device
> type information to the application level, and in global stateful
> variables on top of that.

> Which once again favors the alternative that would work by defining
> new kinds of events.  That alternative has no compatibility issues.

IMHO we cannot simply define new kinds of wheel events that purposely
separate touchpads from mice, or mouse-movement events which separate
trackpoints from mice.  That would mean, from the perspective of the
user, mice would continue to "work as before", but trackpads would not.
Or a keyboard with a Greek layout would not work as it used to, while a
keyboard with an English one would.

It's also not possible to consistently give an individual keyboard a
different keyboard layout under X, since the part of the keyboard
extension for that only works with the obsolete version of the input
extension, not the new one that some programs such as Emacs and most of
the modern toolkits now support.

I'm sorry if I rushed things, and I'd be happy to listen to any
suggestions you might have.  Hopefully, your concerns have also been
addressed.

Thanks in advance!