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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> And you never explained in enough detail why we would need to know
> about "devices" when we use other event types.  You said something
> about keyboards, but I still don't understand why we would care about
> the type of a keyboard.
>
> What other kinds of input could need this information, and why?

Well as another example, artist-mode might want to behave differently
with an "eraser" pointer, removing pixels from the picture instead of
adding them.  Different keyboard might have different layouts (and input
methods want to behave differently), or lilypond-mode might want to
insert notes directly from a MIDI keyboard while allowing typing from a
normal keyboard.

> That was not yet demonstrated.  Though every system has some notion of
> "input device", the information they expose could be utterly different
> and not necessarily appropriate for us.  Your additions express
> devices as strings, and strings don't necessarily carry any useful
> information to explain the significance.  And I don't think you have
> explained anywhere what aspects of the "devices" we'd want to know
> about, and why.

We want to know whether a device is a mouse, trackpoint, eraser, pen,
puck, device control, keyboard, touchscreen, touchpad or MIDI keyboard,
and whether or not it's a different device from some other device, and
also tell apart a single device from anotherq whenever possible.

What would you think about allowing the device structure to be something
other than a string (i.e. window-system dependent, like the argument to
drag-n-drop events), that should be treated as opaque except when passed
to functions like `device-class', and probably `device-equal'?

> I'm sorry, but this just repeats what you said already, and what I see
> in the code you installed.  It doesn't get me closer to understanding
> the real issues.  What is the "device type" and what is its
> significance?  Are you again thinking only about regular mice vs
> touchpad? if so, I already suggested an alternative way to implement
> that.  If "device type" is about something more general, please
> describe those more general aspects, and please try making that
> description as close to exhaustive as possible, because we need to see
> the general picture, not just its few isolated corners.

No, I was thinking of different kinds of devices as well.  The list I
chose to document in `device-class' should be a fairly exhaustive union
of what the window systems we currently support have.  They are (in no
particular order) keyboards, mice, joysticks, erasers, styluses, pucks,
device controls, touchscreens, tablet buttons, MIDI keyboards and test
devices.

Emacs currently doesn't have support on the C level for getting events
from devices outside those categories, at least on X and PGTK.

> And I suggested an alternative for dealing with these differences: new
> kinds of input events.  AFAIU, going that way will completely avoid
> introducing the notion of a "device" into input events.

That won't be very flexible, and it'll be very difficult for the user to
write customizations for some new kind of device (or just a different
device) without adding an entirely new kind of input event for it.  

> I'm still waiting for enough examples of this to even agree that it's
> an issue, let alone an issue we want to solve in Emacs.
>
>> The user could, for example, have a graphics tablet with buttons and an
>> ordinary mouse connected to Emacs at the same time, and want the buttons
>> on those two devices to behave differently.
>
> We do? why?  I think we definitely DON'T.  Emacs is not a GUI toolkit,
> it is a client of such toolkits.  We use toolkits because we do NOT
> want to deal with device-dependent behavior, we want to use
> device-independent abstractions.  If some device is unable to do
> something, it will not produce events that express that functionality,
> and the corresponding Emacs commands will not be invoked.  That is all
> I think Emacs needs to support each input device as appropriate.

To most programs, the graphics tablet buttons are just mouse buttons.
In Emacs, they will just send mouse-1 through 8 when clicked.

And what if the user has two ordinary mice connected, and wants one to
behave differently from the other, in effect giving him an extra set of
mouse buttons?

> I don't think I understand.  What would you like Emacs to support in
> conjunction with Xkb, and what will Emacs have to learn about that for
> it to "understand" those "configurations" (and what are those
> "configurations", btw, i.e. what discerns one "configuration" from
> another?).

The simple use case of having two different keyboards behave
differently.  In my own specific case, they are printed with different
layouts (one is US International, the other is Russian), but X only
allows one keyboard layout for both the keyboards to be active.

So to me, it would be nice to have different input methods for each
individual keyboard, in order to not have to manually switch input
methods each time.

But I'm sure this feature will be much more generally useful as well.

Thanks.