Gestures take a few seconds to react #113
Comments
|
Found the issue, as described in this bug report: bulletmark/libinput-gestures#151 It turns out it has to do with xdotool and having multiple keyboard layouts. The issue can be easily reproduced by typing xdotool key super or xdotool type "aaaaaaaaaaaaaaa" (the more letters, the longer it takes to process). Moreover, for some reason, the delay only occurs with one of the two layouts, the one which is not the default one (the one not on top in "input sources"). |
|
This issue seems to be caused by "xdootool", not "fusuma". For example, to switch to next or previous workspace, set fusuma to following script (as
#!/usr/bin/env bash
if [ $# -gt 1 ]; then
echo "expect 1 argument" 1>&2
exit 1
fi
switch_number=1
if [ $# -eq 1 ]; then
switch_number=$1
fi
current_workspace=$(wmctrl -d | grep '\*' | cut -d' ' -f1)
cmd="wmctrl -s"
to=$((current_workspace + switch_number))
if [ $to -lt 0 ]; then
exit 0
fi
$cmd $to
~/.config/fusuma/config.yml swipe:
4:
left:
command: 'sh ~/desktop_switcher.sh 1'
right:
command: 'sh ~/desktop_switcher.sh -1' |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
If I could make native extension for xdotool, this issue may be solved. |
where should i type xdotool key super? i need to use two keyboard layout , help me |
|
Any news on this fix? |
|
No, not yet. I haven't had a time for working on fix issues these days😭 |
|
I made a change to prevent fusuma hanging when starting long running process. I also had issue with children dying if fusuma is killed (probably not an issue in normal use, but was annoying when testing). I think as a side effect this change would also eliminate delay issues for xdotool commands that take longer than normal. I'm not familiar with ruby, but hopefully I didn't miss anything fundamental. |
|
Thank you very much. |
|
@wonx @vinyoliver
|
|
Same problem - the 2nd, not default layout causes delay. |
|
😢 |
|
It may be better to handle libxdo from native extensions. |
Sorry, I didn't see your answer until now. I updated fusuma by running these commands, but the delay when using the non default keyboard layout is still present. |
sorry for the late response. The delay is still there. :( |
|
Thank you for confirmation. I wanted to confirm if this change worked. It seems that this problem has not been solved yet. By the way, is this problem in only GNOME Shell? |
|
@iberianpig |
|
I wrote simple window switcher based on #113 (comment) (It replicates alt-tab). Maybe someone struggling with #!/usr/bin/env bash
set -euxo pipefail
if [ $# -gt 1 ]; then
echo "expect 1 argument" 1>&2
exit 1
fi
switch_number=1
if [ $# -eq 1 ]; then
switch_number=$1
fi
current_workspace=$(wmctrl -d | grep '\*' | cut -d' ' -f1)
active_window=$(wmctrl -a :ACTIVE: -v 2>&1 | grep 'Using' | cut -d' ' -f3)
windows_in_workspace=$(wmctrl -lx | awk -v num="$current_workspace" '$2==num {print $1}')
cmd="wmctrl -i -a"
if [ $switch_number -eq "1" ];then
switch_to_window=$(echo $windows_in_workspace | sed s/.*$active_window// | awk '{print $1}')
if [ -z "$switch_to_window" ];then
switch_to_window=$(echo $windows_in_workspace | awk '{print $1}')
fi
$cmd $switch_to_window
exit 0
fi
if [ $switch_number -eq "-1" ];then
switch_to_window=$(echo $windows_in_workspace | sed s/$active_window.*// | awk '{print $NF}')
if [ -z "$switch_to_window" ];then
switch_to_window=$(echo $windows_in_workspace | awk '{print $NF}')
fi
$cmd $switch_to_window
exit 0
fi
exit 1Usage is the same as in original script. |
|
An example which works fine for me: |
|
I think this issue still hasn't been resolved? Been using |
|
I released fusuma-plugin-wmctrl. |
Thanks @iberianpig ! Works really well. |
|
How does it work? I installed it according to the instructions, restarted fusuma, but the delay is still there. I checked if the plugin was loaded with fusuma, and apparently it does. But I don't see a difference. |
|
Did you set workspace parameters?https://github.com/iberianpig/fusuma-plugin-wmctrl/blob/master/README.md#example This plugin use wmctl Instead of xdotool, and wmctl can switch current workspace. This is not perfect, but it can be useful for switching workspaces. |
|
Ahh, ok, it was that, it switches workspaces for now. Thanks |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I mean, the bug is still open, and I think it's quite relevant, but it's xdotool's problem, not fusuma's. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Not stale |
|
Please try this plugin https://github.com/iberianpig/fusuma-plugin-sendkey |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Here's a nice Python script that allows using |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
For that problem i suggest using xte from xautomation package. |
|
I suggest https://github.com/iberianpig/fusuma-plugin-sendkey instead of xdotool. |
Usually fusuma works as intended, reacting to gestures immediately, but sometimes it consistently takes a few seconds (2-3s) to execute the command. It doesn't matter if the command is ran at startup or manually in a console. Moreover, the whole OS (Ubuntu 18.04 in my case) freezes while the gesture waits to be executed (even the cursor stops blinking).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The gesture should be executed immediately, in a seamless manner.
Versions
Additional context
Any additional context, your
~/.config/fusuma/config.ymlor data that might be necessary to reproduce the issue.The text was updated successfully, but these errors were encountered: