#220 XInputDevice-dependent tool/color/... selection

[Marky Multiouch]

I've been using Xournal on my machines for quite some time, and recently I started using an EPSON Smart Projector that has support for hand and (special) pen detection. Under Linux, the device registers three additional XInput devices: one for hand/touch, and two for two distinct specially tracked pens.

Your code already supports some GdkDevice-checking (e.g. to distinguish between touch and pen input).

What I would very much like is if the toolbar-buttons to select the tools/colors/etc would also recognize with which device they are pressed, so that I could attach, e.g., the eraser to the hand, a thin black line to one pen, and a red thick line to the second pen.
[some other tools (i think e.g. GIMP) do this as well.]

The interface would not need to be changed really: I think it's fine if the toolbar selections simply show the state of the last-changes by any device. "Only" internally (and that's probably a BIG only?) you would have to not store one set of "current" tool-values, but one for each device that got used...

Sidenote 1: Due to some weirdness in the Linux Epson drivers, all three input devices register with the same name. They are, however, of course distinguishable by the value/address of the registered GtkDevice-pointer you get from event->device within on_canvas_button_press_event(...). So you need to distinguish them NOT by name, but by this address (which will not change during the program's execution) --- in fact you already do something similar when storing scroll_event.scroll.device.)

Sidenote 2: Since there should be only a handful of devices (in my case, e.g., one mouse, two pens, one touch) it seems reasonable/quick enough to simply hold an array/list with one entry per device. Each entry stores the current tool selection, color, etc. for this device. When a press-event is recognized, a linear search through this array/list is certainly fast enough.

Thanks for your consideration!

[Denis Auroux]

I suppose this should be on the to-do list indeed. In the meantime, you
should be able to use the xinput command-line tool to remap buttons, so
that one pen sends button press 1,

Look at the entry for the --set-button-map option in the xinput command,
but basically you'd do something like
xinput set-button-map 18 2 to map device with id=18 to button 2
so by mapping one tool to each of buttons 1,2,3 and using the (not very
ergonomic) menus Options -> Button 2 mapping and Button 3 mapping, you
could map two tools to two different pens and the third one to the eraser.

(To set the button 2 mapping pen in the user interface, you first select
it as current tool, then Options -> Button 2 mapping -> Copy of current
brush, which creates a static copy of the current pen settings for
button 2 to use).

Beware that Gnome 3 has its own settings for button mappings, at least
for wacom tablets, and may try to reset the button map; if the wacom
tablet driver for Gnome 3 decides to take charge of your devices then
you need to use dconf-editor to change the button mappings in
/org/gnome/settings-daemon/peripherals/wacom/... otherwise your manual
xinput changes will keep getting overridden.

Of course what you propose would be better in the long run. The
difficulty is that most modern tablet PCs have vastly varying device
lists and IDs over time -- my wacom pen and eraser don't come back with
the same device ID at every boot, so the only way to distinguish them
and recognize what is what when xournal starts up is by name string
(unlike your Epson devices which seem to all have the same name, but
might have more consistent xinput device ids ?); and depending on
whether I'm at home or at office I can have two or three other external
pens, mice, etc., but not the same ones, though their IDs get allocated
dynamically so overlap. So one needs a very robust mechanism for storing
preferences in this sort of world to handle both your needs (device
names ambiguous) and mine (device IDs not stable over time and varying
list of devices).

In the meantime, just offering a short-term solution so you don't need
to wait for me to get my act together and figure out The Right Way to
handle this. I do realize mapping the other tools to buttons 2 and 3 is
quite limited and not very flexible, but it's better than nothing.

Denis

[Marky Multiouch]

Thanks for this work-around, I'll try that (and hope for a more ergonomic possibility in the future!).

Regarding the IDs: Indeed, they also change on my machine after each start-up and depending on when I connect the projector to the machine. The only stability I have is that I get three consecutive IDs for the projector's input devices, and within those three values, they are ordered consistently each time.

However, I start Xournal only after that, so during the program's execution the IDs and GdkDevice-pointers remain stable. I do not really care so much about the issue of changing IDs, because its fine to (re)choose the tool for each device after each program starts.
[Explanation of use case: each device changes its tool often anyhow, so I'm not so much interested in defaults. We often use it in a multi-user scenario, i.e., two people get each their own pen, the third person the touch interface] --- but I see your point that you would like to offer stable defaults in your program...