-
-
Notifications
You must be signed in to change notification settings - Fork 661
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
Tiling rules should be able to target roles/subroles #152
Comments
@alexxgent As a workaround, you can always use signals for now. The # /usr/bin/env sh
# save as some executable file (chmod +x /path/to/this/script)
# then plug into signal using:
# yabai -m signal --add event=window_created action="/path/to/this/script"
# the window_created signal carries process id and window id as arguments
pid=$1
wid=$2
# check if window is a non-AXUnknown FireFox window
if yabai -m query --windows --window $wid \
| jq -re '.app == "FireFox" and .subrole != "AXUnknown"'
then
# send window to display 1
yabai -m window $wid --display 1
fi Generally speaking... See #120 (comment) for a related discussion. It's even worse with Chrome which always has an invisible Obviously some applications will cause trouble here. Some Emacs distributions set So what about a config setting that makes yabai consider non-standard roles/subroles for a given application? Some sort of whitelist should do. 1 From the tips and tricks section of the wiki:
|
AFAIK, the main window of Emacs is role=AXTextField; subrole=AXStandardWindow while the popups are role=AXTextField; subrole=AXUnknown. |
@dominiklohmann thanks for the workaround, it works like a charm (other than the async tiling as you mentioned). I think a white/blacklist would be ok as well, but would still be a bit less flexible than directly targeting rules to roles & subroles. Is there a reason we wouldn't want to go down that path? If not, I'll take a stab at a PR when I get some time. |
Yes. It unnecessarily complicates what's presented to the user and an easy-to-use command line interface is one of the key features of yabai. Queries are already quite complicated when you need to filter for rules manually, because you cannot act on most of these windows anyways (and wouldn't want to). Almost all of the queries I write for multiple windows are passed through jq with the filter A good middle ground would maybe be to allow rules like you said, and if a role or subrole is given that yabai does not handle by default, it also shows the affected windows in query results and draws inactive borders on them (see #120). Then if a user wanted to restore the old behaviour, they could create a rule that matches all windows whose |
I don't agree that adding two more parameters to rules would make them unnecessarily complicated- The window role/subrole is clearly presented alongside the app name & title in the query interface, so it's intuitive that you'd be able to use these fields to target your rules as well.
On top of that, there will always be edge cases like emacs which every user may want to deal with differently, giving them access to role/subroles is a clean and straightforward way to do so. Either way, I've got it working locally and created a PR - #155 . |
That's not what I mean. I think your approach is flawed because it's basically a blacklist for something that affects so few applications that a whitelist would be preferable, because less users would need to use them. Rules should not act on windows whose Compare: # blacklist approach -- need to filter by subrole for almost all rules
yabai -m rule --add app="^FireFox$" subrole="^(?!AXUnknown)$" display=1
yabai -m rule --add app="^Google Chrome$" subrole="^(?!AXUnknown)$" space=2
# whitelist approach -- simpler syntax for almost all rules
yabai -m rule --add app="^FireFox$" display=1
yabai -m rule --add app="^Google Chrome$" space=2
# the below rule has no effect but tells yabai to operate on matching windows
yabai -m rule --add app="^Emacs$" role="^AXTextField$" subrole="^AXStandardWindow$" I'm not against role and subrole specifiers in rules—I just don't want them to be mandatory for writing correct rules. |
Ah, okay, we're on the same page then. The PR I added uses the whitelist approach- you don't need to specify role/subrole for each rule, but you can optionally use them to pinpoint your target if desired. |
It's not quite the same thing. Take a look at your original rule:
With your PR, this still does not work. That's why your PR requires blacklisting roles that you do not want to act on. Instead, all weird roles and subroles like |
There are two separate issues at play:
The PR I pushed tackles 1, which temporarily gives us an escape hatch for 2, but will also allow for further customization down the line. 2 will need to be dealt with separately, though I don't have enough understanding of how AXUnknown manifests to give an opinion on how. |
I think fixing 1 without fixing 2 is just a bandaid. It requires users to change their configuration to fix an issue that really should not exist at all. What do you do when 2 is fixed separately? Tell users to change their configuration back to how it was before 1 was fixed? |
All of the solutions we currently have to prevent this behavior are bandaids, like the signal workaround you posted earlier. Once we completely fix 2, that sort of thing will need to be reverted anyway. So we can either:
Personally I think 2 is a better option. |
I think ignoring all windows of subrole AXUnknown is the correct solution for now. I don't think the user should have to care about the AXRole, and I'd like to wait and see if there is a real need for this before actually implementing it. See #164 |
Hello guys. I'd still liked to have roles/subroles support. There's another popover-like window roles besides I think current solution with ignoring some specific roles/subroles ( upd: Possible workaround: #194 |
@ai212983 windows with a role of I just downloaded a trial version of Path Finder for testing and it misbehaves in so many different ways, it might just be the application that takes Emacs place as the worst citizen of macOS. Accessibility Inspector tells you that Path Finder mislabels windows roles and subroles and spawns quite a few invisible windows. The proper action here is to just not let yabai manage Path Finder and to write rules based on titles, because there is no way to consistently get this to work using roles and subroles. |
@dominiklohmann Yeah, it's quite messy :) |
Use case-
I have a dual-monitor setup, with a tiling rule for Firefox like
yabai -m rule --add app="^Firefox$" display=1
If I need to move a Firefox window to display 2, any child windows with app: "Firefox" (like the right click dialog which has subrole: "AXUnknown") still adhere to the above rule and remain locked to display 1. You can easily reproduce this by:
This would be solvable if I could exclude subroles of "AXUnknown", or include only subroles of "AXStandardWindow" in the tiling rule. Being able to target roles/subroles would have other benefits as well, and would make the rules system more flexible overall.
The text was updated successfully, but these errors were encountered: