[Feature Request] Toggle clickthrough #3

Closed
opened 2026-09-16 01:27:36 +02:00 by thingsiplay · 13 comments
thingsiplay commented 2026-09-16 01:27:36 +02:00 (Migrated from github.com)

Every time I start the app, I have to toggle this manually, reposition both windwos (controller and history), then toggle clickthrough option in main menu again. It would be nice if we can toggle this quicker without using the main menu on the fly. I have three ideas (but don't mind any other idea too):

  1. either by clicking with middle mouse button on the controller or history will toggle, or
  2. while holding keyboard meta key (or any other modifier, but I move windows by holding meta key) the clickthrough is toggled until I leave the key, or
  3. a good old shortcut on keyboard would toggle the option
Every time I start the app, I have to toggle this manually, reposition both windwos (controller and history), then toggle clickthrough option in main menu again. It would be nice if we can toggle this quicker without using the main menu on the fly. I have three ideas (but don't mind any other idea too): 1. either by clicking with middle mouse button on the controller or history will toggle, or 2. while holding keyboard meta key (or any other modifier, but I move windows by holding meta key) the clickthrough is toggled until I leave the key, or 3. a good old shortcut on keyboard would toggle the option
Khyretos commented 2026-09-16 05:43:00 +02:00 (Migrated from github.com)

Hey i took your sugestion and im implementing the following:

  • when hovering over a controller window or a input window you can middle click to toggle drag to move and click through this would be a build in feature that is standard.
  • there will be a dropdown next to "drag to move" and "click through" where you can define a shortcut key that if held and you are hovering one of the windows, it will enable the option and when the shortcut is released it will go back to its original state.
  • i will also make the software remember the position and ssize of where you last left them. but this will not really work well on a tiling manager like hyprland (which is what i use) but should work fine on KDE or windows.

hopefully you agree with the changes

Hey i took your sugestion and im implementing the following: * when hovering over a controller window or a input window you can middle click to toggle drag to move and click through this would be a build in feature that is standard. * there will be a dropdown next to "drag to move" and "click through" where you can define a shortcut key that if held and you are hovering one of the windows, it will enable the option and when the shortcut is released it will go back to its original state. * i will also make the software remember the position and ssize of where you last left them. but this will not really work well on a tiling manager like hyprland (which is what i use) but should work fine on KDE or windows. hopefully you agree with the changes
thingsiplay commented 2026-09-16 06:12:55 +02:00 (Migrated from github.com)

Wow, are you joking? How could I not agree? :D Thank you for taking your time and looking into it this quickly.

As for the position remembering, it's actually Wayland that does not remember or does not support it. Its a long standing issue with Wayland. I think KDE on Wayland does some internal tricks to remember it, but I don't know. That's not a priority to me anyway. I will test it when its out and report any issues then.

Wow, are you joking? How could I not agree? :D Thank you for taking your time and looking into it this quickly. As for the position remembering, it's actually Wayland that does not remember or does not support it. Its a long standing issue with Wayland. I think KDE on Wayland does some internal tricks to remember it, but I don't know. That's not a priority to me anyway. I will test it when its out and report any issues then.
Khyretos commented 2026-09-20 07:18:14 +02:00 (Migrated from github.com)

Ok as it stands:
i have changed some things:

  • there is now a right click menu to "reset view" and to toggle "click through" and "drag to move" in the controller window (not really relevant to this isssue but i thought id mention it)
  • there is now a checkbox for the user to opt in called "Enable Shortcut Monitoring" which makes it possible for you to assign a keyboard shortcut to enable "click through" or "drag to move" for both the controller window and the input history window. you will notice they will be greyed out if the checkbox is not ticked because i dont want users to think my software is monitoring keystrokes or shortcuts without their explicit permission (even though this software is basically a keylogger/game) this also means that the shortcut will toggle the checkbox everytime its pressed, even though you will not see it (becuase i imagine you have the settings window minimized) it will toggle regardles of whether it is in focus or not
  • there is indeed a limit in wayland where it does not report the positions of its windows (or at least i have no smart way of getting these for now) so unfortunately i cannot save the last position which confirms what you said.

i hope this satisfies your requirements. v1.3.0 is building as we speak. the release became bigger due to another feature request i got through discord so i decided to do a minor bump.

Ok as it stands: i have changed some things: * there is now a right click menu to "reset view" and to toggle "click through" and "drag to move" in the controller window (not really relevant to this isssue but i thought id mention it) * there is now a checkbox for the user to opt in called "Enable Shortcut Monitoring" which makes it possible for you to assign a keyboard shortcut to enable "click through" or "drag to move" for both the controller window and the input history window. you will notice they will be greyed out if the checkbox is not ticked because i dont want users to think my software is monitoring keystrokes or shortcuts without their explicit permission (even though this software is basically a keylogger/game) this also means that the shortcut will toggle the checkbox everytime its pressed, even though you will not see it (becuase i imagine you have the settings window minimized) it will toggle regardles of whether it is in focus or not * there is indeed a limit in wayland where it does not report the positions of its windows (or at least i have no smart way of getting these for now) so unfortunately i cannot save the last position which confirms what you said. i hope this satisfies your requirements. v1.3.0 is building as we speak. the release became bigger due to another feature request i got through discord so i decided to do a minor bump.
thingsiplay commented 2026-09-20 09:13:26 +02:00 (Migrated from github.com)
  • The Right Mouse click menu appears when on the gamepad model. But only if Click through is disabled. Because off course once enabling it, right click goes through.
  • And unfortunately the Shortcuts do not work for me. I am on KDE Wayland and the Shortcuts have no effect. Pressing or holding shortcut does not toggle the Click through state. Enable Shortcut Monitoring is on, then choose and try different keys like "A" or modifier like "Left Ctrl".

As for the window positioning, I can do that manually. That is not an issue.

* The Right Mouse click menu appears when on the gamepad model. But only if Click through is disabled. Because off course once enabling it, right click goes through. * And unfortunately the Shortcuts do not work for me. I am on KDE Wayland and the Shortcuts have no effect. Pressing or holding shortcut does not toggle the Click through state. Enable Shortcut Monitoring is on, then choose and try different keys like "A" or modifier like "Left Ctrl". As for the window positioning, I can do that manually. That is not an issue.
Khyretos commented 2026-09-21 11:34:11 +02:00 (Migrated from github.com)

Can you verify if you user is part of the "Input" group or try to use the keyboard or mouse model. if you see that the models dont react to anything then your user is probably not part of the group and if you want it to work (as in the program listen to your keyboard/mouse events) then you will need to run the following command sudo usermod -a -G input $USER and then restart the pc or session but this command does implicate a security risk.

here is the awnser from the brave browser AI:

Yes, it does present a meaningful security concern. Here's a concise explanation you can relay:

What it grants: Membership in the input group gives the user read access to every device node under /dev/input/ — that is, all keyboards, mice, touchpads, and any other evdev input device. This means:

  • Keylogging: Any process running as that user can silently capture all keystrokes system-wide, including passwords typed in terminals, browsers, or GUI apps. No root needed.
  • Input injection: The user can also write to /dev/input/uinput, allowing them to synthesize fake keyboard/mouse events (e.g., automate clicks, type commands).
  • Scope is too broad: It's not limited to one device — it's all input devices on the system.

Why it's considered deprecated: The modern, preferred approach is to use udev rules with the uaccess tag, which lets logind dynamically grant access via ACLs only to the active local session, and only for specific devices. This is narrower in scope and doesn't persist across sessions or apply to remote/SSH sessions.

Practical risk: On a single-user personal machine the risk is low. On a multi-user or shared system, it's effectively the same as giving that user a keylogger — any compromised process running under their account can harvest credentials.

Recommended alternative:

# Instead of: sudo usermod -a -G input $USER
# Use a udev rule targeting only the specific device you need:
echo 'SUBSYSTEM=="input", ATTRS{name}=="<device_name>", TAG+="uaccess"' | \
  sudo tee /etc/udev/rules.d/99-specific-input.rules
sudo udevadm control --reload-rules

This grants access only to the named device, only during an active local session, and leaves all other input devices locked down.

Maybe you can specify the device but i cant work around this since it is a security thing in linux.

you can try it for testing purposes and then reverting it. but this is a limitation/risk i cannot work around for now. sorry.

Can you verify if you user is part of the "Input" group or try to use the keyboard or mouse model. if you see that the models dont react to anything then your user is probably not part of the group and if you want it to work (as in the program listen to your keyboard/mouse events) then you will need to run the following command `sudo usermod -a -G input $USER` and then restart the pc or session but this command does implicate a security risk. here is the awnser from the brave browser AI: > Yes, it does present a meaningful security concern. Here's a concise explanation you can relay: > > **What it grants:** Membership in the `input` group gives the user **read access to every device node under `/dev/input/`** — that is, all keyboards, mice, touchpads, and any other evdev input device. This means: > > - **Keylogging:** Any process running as that user can silently capture **all keystrokes system-wide**, including passwords typed in terminals, browsers, or GUI apps. No root needed. > - **Input injection:** The user can also **write** to `/dev/input/uinput`, allowing them to synthesize fake keyboard/mouse events (e.g., automate clicks, type commands). > - **Scope is too broad:** It's not limited to one device — it's *all* input devices on the system. > > **Why it's considered deprecated:** The modern, preferred approach is to use **udev rules with the `uaccess` tag**, which lets `logind` dynamically grant access via ACLs **only to the active local session**, and only for specific devices. This is narrower in scope and doesn't persist across sessions or apply to remote/SSH sessions. > > **Practical risk:** On a single-user personal machine the risk is low. On a **multi-user or shared system**, it's effectively the same as giving that user a keylogger — any compromised process running under their account can harvest credentials. > > **Recommended alternative:** > ```bash > # Instead of: sudo usermod -a -G input $USER > # Use a udev rule targeting only the specific device you need: > echo 'SUBSYSTEM=="input", ATTRS{name}=="<device_name>", TAG+="uaccess"' | \ > sudo tee /etc/udev/rules.d/99-specific-input.rules > sudo udevadm control --reload-rules > ``` > > This grants access only to the named device, only during an active local session, and leaves all other input devices locked down. > Maybe you can specify the device but i cant work around this since it is a security thing in linux. you can try it for testing purposes and then reverting it. but this is a limitation/risk i cannot work around for now. sorry.
thingsiplay commented 2026-09-21 12:13:28 +02:00 (Migrated from github.com)

Hmm, those commands are for Xorg / X11 I think (or XWayland, which is not Wayland), so not for my system. As I thought, on Wayland there is this global hotkey problem I think. But I have a different idea.

Maybe a toggle could be added to the Taskbar Icon.

Hmm, those commands are for Xorg / X11 I think (or XWayland, which is not Wayland), so not for my system. As I thought, on Wayland there is this global hotkey problem I think. But I have a different idea. Maybe a toggle could be added to the Taskbar Icon.
Khyretos commented 2026-09-21 12:18:27 +02:00 (Migrated from github.com)

Thats a great idea! Ill add them in the next patch.

But i did have to add these in my system as well and im using cachyos/hyprland. So maybe its worth the try or maybe look at the wayland alternative to this.

Also does the keyboard and mouse model work for you?

Thats a great idea! Ill add them in the next patch. But i did have to add these in my system as well and im using cachyos/hyprland. So maybe its worth the try or maybe look at the wayland alternative to this. Also does the keyboard and mouse model work for you?
thingsiplay commented 2026-09-21 12:58:13 +02:00 (Migrated from github.com)

OK, so good news, it works. I was hesitant to try this sudo usermod -a -G input $USER command. But after you mentioned that you had to use it in CachyOS, I had to, because I'm on EndeavourOS and these use the same base Archlinux.

And indeed, now toggle shortcut works, keyboard and mouse work too (it didn't before). Input History and the model, mouse, keyboard, gamepad, shortcuts. No complains about the functionality at this point! Thank you so much for this.

The only thing is, I'm not entirely sure about the security aspect using the "input" group. In the end, having the toggle in the taskbar could be a "satisfying" workaround of this problem. I guess this is a solved issue now? The very least this information (also that udev is recommended over input group) should be noted in the README, for Wayland users.

OK, so good news, it works. I was hesitant to try this `sudo usermod -a -G input $USER` command. But after you mentioned that you had to use it in CachyOS, I had to, because I'm on EndeavourOS and these use the same base Archlinux. And indeed, now toggle shortcut works, keyboard and mouse work too (it didn't before). Input History and the model, mouse, keyboard, gamepad, shortcuts. No complains about the functionality at this point! Thank you so much for this. The only thing is, I'm not entirely sure about the security aspect using the "input" group. In the end, having the toggle in the taskbar could be a "satisfying" workaround of this problem. I guess this is a solved issue now? The very least this information (also that udev is recommended over input group) should be noted in the README, for Wayland users.
Khyretos commented 2026-09-21 13:00:57 +02:00 (Migrated from github.com)

Happy to know it works, and yes i will note it in the readme because it is something users should be made aware of.
dont close the issue, when i add the taskbar functionality you can close it. :) thank you for the feedback!

Happy to know it works, and yes i will note it in the readme because it is something users should be made aware of. dont close the issue, when i add the taskbar functionality you can close it. :) thank you for the feedback!
Khyretos commented 2026-09-22 05:22:53 +02:00 (Migrated from github.com)

So the tray icon has the possibility now to toggle click through and drag to move, unfortunately for my system i need to open the tray icon 2 times if i want to disable both checkboxes because after confirming an action it inmedeatly closes and i to open it again to toggle the other one. I tried making it so it stays open, but this is something i was not able to fix. maybe its because of my system maybe its a linux thing. but at least it works. so hopefully v1.3.1 works for you.

So the tray icon has the possibility now to toggle click through and drag to move, unfortunately for my system i need to open the tray icon 2 times if i want to disable both checkboxes because after confirming an action it inmedeatly closes and i to open it again to toggle the other one. I tried making it so it stays open, but this is something i was not able to fix. maybe its because of my system maybe its a linux thing. but at least it works. so hopefully v1.3.1 works for you.
thingsiplay commented 2026-09-22 06:50:38 +02:00 (Migrated from github.com)

It works... but there are issues.

Tray Icon
It works, the menu entries will toggle the settings. That it closes after an entry selection is normal. My only complain would be, that the menu entries are too nested. And there is a little issue, but that should be discussed on a dedicated tracker.

Click-Through and Shortcut
I'm not sure if this was the behavior before, but when Click-Through is disabled, I can no longer move my window. The issue is following... See I use the Meta or Windows key (known as Left GUI here) to hold to move any window on my system. And that is also set as the key to toggle here.

Global system shortcut key to move window: Left GUI

  • Click-Through: OFF and Left Alt - I can move the 3dco+ window with my Meta key. No need support from your app and your shortcut is not needed.
  • Click Through: OFF and Left GUI - Your app takes over Left GUI shortcut. I can no longer move window. But I want the Left GUI to be able to move the window, as this is my global shortcut for every window and application.
  • Click Through: ON and Left GUI - Now it moves. Your app takes over Left GUI shortcut. I can move.
  • Click Through: ON and Left Alt - Now it does no longer move. Instead I can rotate with Left Alt.

My suggestion is, regardless of any current mode, as long as the shortcut is hold, Click-Through should switch temporarily and stay ON. If someone doesn't want that, then shortcut can be disabled.

It works... but there are issues. Tray Icon It works, the menu entries will toggle the settings. That it closes after an entry selection is normal. My only complain would be, that the menu entries are too nested. And there is a little issue, but that should be discussed on a dedicated tracker. Click-Through and Shortcut I'm not sure if this was the behavior before, but when Click-Through is disabled, I can no longer move my window. The issue is following... See I use the Meta or Windows key (known as Left GUI here) to hold to move any window on my system. And that is also set as the key to toggle here. Global system shortcut key to move window: Left GUI * Click-Through: OFF and Left Alt - I can move the 3dco+ window with my Meta key. No need support from your app and your shortcut is not needed. * Click Through: OFF and Left GUI - Your app takes over Left GUI shortcut. I can no longer move window. But I want the Left GUI to be able to move the window, as this is my global shortcut for every window and application. * Click Through: ON and Left GUI - Now it moves. Your app takes over Left GUI shortcut. I can move. * Click Through: ON and Left Alt - Now it does no longer move. Instead I can rotate with Left Alt. My suggestion is, regardless of any current mode, as long as the shortcut is hold, Click-Through should switch temporarily and stay ON. If someone doesn't want that, then shortcut can be disabled.
Khyretos commented 2026-09-23 05:37:47 +02:00 (Migrated from github.com)

So right now v1.3.2 should behave exactly as you described i just need you to test it as i cannot reproduce it due to the nature of hyprland.
the idea is that holding the shortcut for "drag to move" triggers the "click through" to ON (it does not show it visuall but it does so internally). since this is a very niche feature it is only documented so please verify this for me and hopefully we can close the issue :D

So right now v1.3.2 should behave exactly as you described i just need you to test it as i cannot reproduce it due to the nature of hyprland. the idea is that holding the shortcut for "drag to move" triggers the "click through" to ON (it does not show it visuall but it does so internally). since this is a very niche feature it is only documented so please verify this for me and hopefully we can close the issue :D
thingsiplay commented 2026-09-23 12:05:51 +02:00 (Migrated from github.com)

It works like described as before. Little bit inconsistent, because I cannot move window when click through is ON. But it works overall, once a setup is found. There are ways to switch to on and off.

It works like described as before. Little bit inconsistent, because I cannot move window when click through is ON. But it works overall, once a setup is found. There are ways to switch to on and off.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
khyretos/3dco-plus#3
No description provided.