Before opening a feature request
What is the user problem or growth opportunity you want to see solved?
Problem
When using rofi to trigger actions (e.g. typing text into another application), the command is executed while rofi still has keyboard focus.
As a result, input events may be lost or sent to the wrong target.
Proposal
Add a way to execute an action after the rofi window is closed and focus is released.
For example:
- a "post-close" event
- or a mode where the selected action runs only after rofi exits and the compositor restores focus
Current workaround
sh -c "sleep 0.1 && wtype 'hello'"
This relies on arbitrary delays and detached processes, which is not reliable or clean.
Expected behavior
- user selects an entry
- rofi closes immediately
- focus returns to the previous window
- action is executed after that
This would avoid the need for workarounds like delayed or detached processes and make action-based workflows more reliable, especially on Wayland.
How do you know that this problem exists today? Why is this important?
On writing a plugin that use the protocol virtual-keyboard-unstable-v1
Who will benefit from it?
All Wayland users
Rofi version (rofi -v)
Version: 2.0.0-23-gcaa69c39 (next)
Configuration & Information
https://gist.github.com/d3v2a/e03c7473f55f28941a019b8cc6b068c8
Additional information
No response
Before opening a feature request
What is the user problem or growth opportunity you want to see solved?
Problem
When using rofi to trigger actions (e.g. typing text into another application), the command is executed while rofi still has keyboard focus.
As a result, input events may be lost or sent to the wrong target.
Proposal
Add a way to execute an action after the rofi window is closed and focus is released.
For example:
Current workaround
sh -c "sleep 0.1 && wtype 'hello'"This relies on arbitrary delays and detached processes, which is not reliable or clean.
Expected behavior
This would avoid the need for workarounds like delayed or detached processes and make action-based workflows more reliable, especially on Wayland.
How do you know that this problem exists today? Why is this important?
On writing a plugin that use the protocol virtual-keyboard-unstable-v1
Who will benefit from it?
All Wayland users
Rofi version (rofi -v)
Version: 2.0.0-23-gcaa69c39 (next)
Configuration & Information
https://gist.github.com/d3v2a/e03c7473f55f28941a019b8cc6b068c8
Additional information
No response