Update pimoroni_trackball.py

[regicidalplutophage]

Expose press variable in the constructors of of handlers that had it hardcoded

[xs5871]

The intended solution is to make a completely custom handler:

class NewPointingHandler(TrackballHandler):
    def handle(self, keyboard, trackball, x, y, switch, state):
        if x:
            AX.X.move(keyboard, x)
        if y:
            AX.Y.move(keyboard, y)

        if switch == 1:  # Button changed state
            keyboard.tap(KC.ANY)

When we add a press parameter, then we need parameters for up, down, left, right as well to be consistent, and then the existing implementations become pointless, etc...
Yes the handler implementation is stupid, I think someone just straight copied it from QMK.
In my opinion all this should be handled centrally by the keymap. Same issue with encoders and analog input.

Regardless, it should be on_press instead of press.

[regicidalplutophage]

IMO while this particular trackball is indeed 2 magnetic encoders in a trench coat and each encoder is 2 switches in a trench coat, the action of rotating is conceptually different from the action of pressing.

[claycooper]

2 magnetic encoders in a trench coat

That one made me laugh out loud, thanks.

[regicidalplutophage]

YW!

press is on_press now except for in the KeyHandler where it's a positional argument.

[xs5871]

IMO while this particular trackball is indeed 2 magnetic encoders in a trench coat and each encoder is 2 switches in a trench coat, the action of rotating is conceptually different from the action of pressing.

I don't disagree. I wanted to point out that currently we're reimplementing a keymap (or "eventmap" if you want to address binary press/release events and continous movements equally) seperately for every peripheral, and I don't think that's a good solution.
Even worse: the trackball doesn't do layers, as it should, it's a completely orthogonal mechanism.

[regicidalplutophage]

for every peripheral

If you're referring to the encoder, yeah, encoder module can go and the encoder scanner can become the default way of interfacing with encoders. One caveat is that separate keymap makes user configs cleaner and should be re-implemented for scanners. For example, for each scanner we could add keymap=keyboard.keymap parameter.
Encoder module's code can be cannibalized into separate scanners used when limitations of rotaryio are an issue.

Side tangent to this side tangent:
I've been thinking of re-implementing split as transmitter/scanner system where secondary half would run a completely different program and primary would listen to the secondary via a scanner.

Now, pointing devices are their own thing entirely and can't be simplified into something along the lines of "if up mouse up" because of something to do with square roots... So how do we handle a device that can both be pointing device and an encoder and can switch its function in runtime? Preferably user config shouldn't get too cluttered as a result.

[xs5871]

So how do we handle a device that can both be pointing device and an encoder and can switch its function in runtime?

There's the mid-term goal to directly use KeyEvents from CP anyway instead of decomposing them into position and state. Once that's there, there's nothing stopping us to generalize to any kind of InputEvent.

[xs5871]

This needs better documentation. It looks like the press argument is required, and since no one is looking up the source code when using KMK for the first time, they will copy-paste anything without a care in the world.
Maybe a small subsection about existing handlers, their arguments and an example of a custom one? (That would also reduce the need for a customizable press event)

[xs5871]

I'll amend the docs in the next PR.