Yabai: Rules noob question

[ThiagoFacchini]

Hi, first of all I'd like to say thanks for such an awesome window manager.

I want to create a set of rules for Chrome windows, so I'll have to leverage the title property, although I'm struggling with the REGEX.

I tried a few regex expressions that would work in other scenarios but I'm always get errors from yabai.

I basically want to look for the application titles, like: "Mail - Joe", "Mail - Mary", "Mail - Chad", and I would like each title variation to have its own rule.

But I can't get it working... Can you guys provide some example on how to tackle this type of scenario?

Thanks

[dominiklohmann]

Try to get as close as possible with your match.

You used - (dash) in your example title, but maybe it's – (en-dash) or — (em-dash)? Getting the exact string is really important here.

You can query all open Google Chrome windows by running this command, which will include the exact title as read by yabai (requires jq).

# get everything about Google Chrome windows
yabai -m query --windows | jq 'map(select(.app == "Google Chrome"))'

# get just the title of all Google Chrome windows
yabai -m query --windows | jq 'map(select(.app == "Google Chrome").title)'

The regex syntax used is the POSIX syntax. It's good practice to try and match start and end of line with ^ and $ respectively to avoid surprise matches.

An example rule might look something like this:

# Enter native-fullscreen when Chromes window title is exatly "Mail - Joe"
yabai -m rule --add app="^Google Chrome$" title="^Mail - Joe$" native-fullscreen=on

# Make picture-in-picture video windows of Chrome visible on all spaces and float on top
yabai -m rule --add app="^Google Chrome$" title="^Picture in Picture$" sticky=on

If you want to run code when a window title changes, consider looking into the event=window_title_changed signal, which will trigger whenever a macOS reports that a window title changed. The signal carries the window id of the window whose title has changed, allowing you to do further queries.

Also... there really are no "noob" questions. Feel free to ask, we all like to help. :octocat:

Also a warning: Don't bother with this If you're using the Catalina beta. Yabai fails to read window titles on it currently.

[ThiagoFacchini]

@dominiklohmann thank you, really clarified everything.

I'm also glad you mentioned how to run queries... it makes everything way way easier.

Curiosity: What the properties role and subrole (from the query result) means?

Once again, thanks.

[dominiklohmann]

Curiosity: What the properties role and subrole (from the query result) means?

Run Accessibility Inspector.app on your Mac and you'll see.

The gist of it is that everything in macOS windows is comprised of "elements" that are in a specific hierarchy, similar to the view hierarchy for view controllers in iOS. There is an accessibility API that allows you to query these elements, and to identify what an element is they have roles (e.g. AXWindow for windows or AXButton for buttons), and they can optionally have a second role ("subrole") for subtypes of that role (e.g. AXStandardWindow for most windows, or AXFullscreenButton for the green fullscreen button on your windows).

When you see yabai prompt for permissions to control your computer, it is asking for access to this API specifically.

The reason that role and subrole are included in the queries is that some applications—most notably Emacs—report wrong roles for their elements. A recent change that is on current master, but not yet released, is that yabai no longer acts on windows whose role is AXPopover or whose subrole is AXUnknown. Especially with Chrome you'll likely see lots of these subrole=AXUnknown windows that you can't act on.

[pcr910303]

@dominiklohmann (While I knew the gist of what roles and subroles are, for inexperienced people) What about adding your wonderful explanation about roles in the wiki? I think that the roles and subroles should be explained to people who aren’t familiar with cocoa.

_{Sent with GitHawk}