[BUG] -window-command ignored

[ckudera]

Rofi version (rofi -v or git commit in case of build issue)

Version: 1.7.5+wayland2

Configuration

https://gist.github.com/ckudera/3296974509961570aa7d13ab58688ec7

Theme

https://gist.github.com/ckudera/e5e528840451a8e7d015ab1db4b66d3b

Timing report

No response

Launch command

rofi -show window -kb-accept-alt x -window-command "notify-send {window}"

Step to reproduce

Execute the Launch Command and press x on any window entry. No special config or theme file are necessary.

Expected behavior

On any window entry, x should lead to a notification (notify-send {window} should be executed).

Actual behavior

The -window-command is ignored and the selected window gets focused (default behaviour as it would be when the Return key is pressed).

Additional information

With rofi -show window -kb-accept-alt x -window-command "notify-send {window}" --help I get the following output:

        -window-command [string]                Command to executed when -kb-accept-alt binding is hit on selected window 
                notify-send {window} (Commandline)

        -kb-accept-alt [string]                 Use alternate accept command.
                x (Commandline)

Therefore, both commandline options are set as they should be.

Using wayland display server protocol

• [X] Yes, I use rofi with wayland support

I've checked if the issue exists in the latest stable release

• [X] Yes, I have checked the problem exists in the latest stable version

[alebastr]

-window-command was omitted from the initial implementation as {window} is an X11 window ID and there's no matching concept for Wayland. Running a command without any way to identify the selected window isn't very useful.

Two main blockers for the functionality:

• ext-foreign-toplevel-list protocol is already merged and introduces the concept of ext_foreign_toplevel_handle_v1.identifier, an unique and stable identifier for a toplevel, but there are no compositor implementations yet. Maybe wlroots 0.18 somewhere next year will add it.
• ext-foreign-toplevel-state and ext-foreign-toplevel-management protocols to allow actually getting the window info and manipulating it (focus, close, etc) are stuck in the usual wayland-protocols review process.

[ckudera]

@alebastr Thanks for the fast reply. Is there any way to execute a custom script for a window at the moment? Maybe the unique node id (swaymsg --raw -t get_tree) could be a replacement for the window ID?

[alebastr]

Unfortunately, that info is not available to the module. The implementation does not use Sway specific IPC.

Window title and app_id is all we have, although I'm hesitant to allow using these for scripting and introduce even more divergence with XCB window behavior. If it gets into the code as a temporary solution, it's going to stay here forever :(

[LRitzdorf]

Returning the PID might be a viable option (maybe along with a new "pattern", like {pid})?

I came across this for Hyprland, which supports acting on windows by PID; not sure if Sway and others do the same.