Replies: 1 comment
-
Surprisingly, it came back. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The latest KDE Connect android app update came with a note that the app's ability to receive remote mouse input had to be removed, because Google objected to their (ab)use of the Accessibility APIs to implement it.
That's not the sort of decision that's likely to be reversed, so the ability to send remote mouse events to an Android device is probably dead for good. (This doesn't affect the Android app's ability to send remote mouse and keyboard events to Linux, which still works fine. As does the KDE Connect Remote Keyboard input method. Only the remote pointer movements/clicks were disabled.)
My first instinct was to just drop the remote-mouse sending features from GSConnect entirely. (Sadly, as they were added by @wissle less than a year ago.)
But... technically sending remote-mouse events still works, if the other end of the connection is also a Linux device.
Is that a reason to keep it around? Is there really anyone using GSConnect that way? (I can't imagine it, there are much better ways to remotely drive a Linux machine's pointer from another Linux machine. But, it's possible.)
If the "touchpad" interface to the Remote Input dialog is kept, it'll need logic to determine whether the paired device supports remote mouse events, so that the interface can be conditionally shown only when supported. (So, keeping it is not a zero-effort choice, is my point. It'll involve some effort either way; it's probably more work to keep it than to drop it, honestly.)
Beta Was this translation helpful? Give feedback.
All reactions