Differentiate long press and move events

[mayanksuman]

Description
Currently actions like Key Sequence, Cycle Preset, and Toggle Spotlight are not available for Next/Back Hold move events in Projecteur 1.0 alpha, which lead to following issue:

1. The Next/Back Hold event can not be temporarily disable as with other input events by having empty key Sequence mapping.
2. Currently there is no way to launch an external program/shortcut by Next/Back hold events (like starting presentation mode (F5), blank screen during presentation (b) on Next/Back Hold events)

Expected behavior
I think that the user should have the option of these mapped action (Key Sequence, Cycle Preset, and Toggle Spotlight) on Next/Back hold event. There might be creative and useful ways to utilize these mapped actions on Next/Back hold events. The official software provide this option and it let user decide what they want to do with Next/Back hold events (Please see #14 ).

Desktop/Linux Environment (please complete the following information):

• Linux Distribution and Version: Debian GNU/Linux bookworm/sid x86_64
• Desktop/Window Manager and Version: GNOME 3.38.6
• Did you built Projecteur yourself?: No (used prebuilt deb from cloudsmith)
• What is the output of projecteur -f ?:

Projecteur 1.0-alpha.97
 - git-branch: develop
 - git-hash: 2e75d28931635f20b65280f74ffcd73948a6982d
 - compiler: GNU 8.3.0
 - build-type: Release
 - qt-version: (build: 5.11.3, runtime: 5.15.2)
 - device-scan: (errors: 0, devices: 1 [readable: 1, writable: 1])

• What is the output of projecteur -d ?:

* Found 1 supported devices. (1 readable, 1 writable)

+++ name:     'Logitech USB Receiver'
    userName: 'Logitech Spotlight (USB)'
    vendorId:  046d
    productId: c53e
    phys:      usb-0000:04:00.3-2
    busType:   USB
    devices:   /dev/hidraw6, /dev/input/event8, /dev/input/event25, /dev/input/event23, /dev/input/event24
    readable:  true
    writable:  true

[jahnf]

You can record a long button press as recording any other button press from the device. You can map a button combination to this, like with any other combination.

But I agree that the docs are not up to date with this information.

[jahnf]

Only for the hold move events the possible action type changes

[mayanksuman]

You can record a long button press when recording the input. You can map a button combination to this..

I tried that one; however it was not working due to two reasons: 1) It is not possible for user to again produce the same long button press events (due to high traffic from device during hold events) 2) in practice, the action for Next/Back Hold Move event worked not the action I wanted.

[jahnf]

Try it with the version on develop
See cbd343d

There is a difference now between a long press and a long press move event

[mayanksuman]

There is a difference now between long press and a long press move event

I understood now and long press is working if I do not move the device. We need to update the docs.

[jahnf]

There is a difference now between long press and a long press move event

I understood now and long press is working if I do not move the device. We need to update the docs.

Actually it doesn't matter how much you move around when recording a long press .. during input mapper recording no long press move events are getting forwarded to the input mapper

[mayanksuman]

There is a difference now between long press and a long press move event

I understood now and long press is working if I do not move the device. We need to update the docs.

Actually it doesn't matter how much you move around when recording a long press .. during input mapper recording no long press move events are getting forwarded to the input mapper

Yes, you are right. However, while executing we should not move the device.

I have found a bug in case when both long-press and move event are defined for same button (say Next button), then holding the button and moving it result in both actions (long-press and move actions).

I think we can put a timeout for long-press event (as it is there for other input event in form of input sequence interval). If we do not receive any move packet from device then we execute long press event otherwise not.

[jahnf]

I know what you mean, but I don't think this is much of an issue. If the user wants to assign both , the user can. I don't think that is possible with the Logitech software.

[mayanksuman]

But while presenting, user should be sure what actions are going to happen (in case if he has defined both long-press and move events). I am checking the code and most probably will post a fix (along with updated docs) soon.

[jahnf]

I argue that if the user assigned both, the user wants to assign both.

The beauty with that is, that the long press is an event as any other... Special handling is only necessary for 'hold move' events

[jahnf]

After thinking about it for a while, my basic idea still stands - I don't want to restrict to the user to either or.
It should be possible to assign actions to both.
The button "long press" is a separate button event as the "long press move" event.

The only difference is that a "move event" does not make sense for certain actions - that is why the possible action selection is restricted and changed in depending on that.

[jahnf]

But while presenting, user should be sure what actions are going to happen (in case if he has defined both long-press and move events). I am checking the code and most probably will post a fix (along with updated docs) soon.

Well it is both, if both is assigned - and therefore intended by the user

1. The action assigned to the long press (e.g. emit a certain keystroke)
2. The move action assigned (e.g. scrolling) - as soon as enough movement is detected in the move events.

[mayanksuman]

Please check the PR #158 .

The only change in that PR is introduction of button release code, which can differentiate long-press and hold move events.

Now user can have the control about whether he/she want 'long-press' action only or 'hold move' action only.

However, on second thought I found that the executing such events separately is tricky from user prospective, so I am closing this issue. We still need to update the docs.