Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] -window-command ignored #114

Open
2 tasks done
ckudera opened this issue Jan 10, 2024 · 4 comments
Open
2 tasks done

[BUG] -window-command ignored #114

ckudera opened this issue Jan 10, 2024 · 4 comments
Labels

Comments

@ckudera
Copy link

ckudera commented Jan 10, 2024

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

  • Yes, I use rofi with wayland support

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

  • Yes, I have checked the problem exists in the latest stable version
@ckudera ckudera added the bug label Jan 10, 2024
@alebastr
Copy link

-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
Copy link
Author

ckudera commented Jan 10, 2024

@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
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants