-
-
Notifications
You must be signed in to change notification settings - Fork 648
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
Feature Request: Position-based display selectors #550
Comments
I've been poking around the code in my spare time, and I think I've got enough info so I'd be able to hack on this if it seems like a useful direction. Thanks for yabai! |
The argument against relegating this to a scripting layer is that querying and parsing out JSON replies from yabai is slow enough to be noticeable when in a critical action like "focus a display", even on the newest most souped-up models. |
I agree that having to query and re-parse JSON every time you want to focus a display is not optimal for something like this. However, I do think that an alternative solution could be to support labeling displays the way you can label spaces. By doing this you could simply query the list of active displays upon startup and filter/sort by whatever. If displays are added/removed during an active session you could hook up the same script to the display added/removed signals, and have it reconfigure the labels. The reason that I prefer these kinds of solutions is simply that a lot of people have different preferences in their workflow, and so I want the core implementation to be as simple as possible while providing the ability to let users customize on their end, without having to necessarily go and edit the source directly. There are some related/similar issues on the board, although not directly related; I'm linking them here for reference: #225, #372, #365 |
Okay! I do think sorting by horizontal/vertical position is a relatively common use case, though, however people decide to script around it - this patch would definitely allow something like #225 to be much easier to script, for example. |
To put it another way, labelling is certainly powerful, but the overhead of making the user maintain a script that computes position parameters and syncs its state with yabai's internals feels out of proportion to the actual functionality. |
Alternatively, this could be replaced with a config option like |
I'll give this issue some thought before I decide which way to proceed, but I do agree that we can definitely do better than the current situation. |
I like this proposal! I already use a left first based indexing for my yabai scripts... this functionality would certainly simplify some of my scripts and potentially make things a little faster :) |
This is an alternate proposal, just to keep things properly linked together: #554 |
Just so I'm not missing anything. In practice, this specific implementation would be pretty much the same as if cardinal directions where available for targetting displays, as described in #225, yeah? Edit: So I guess this is different in the way that you can actually re-orient what is considered the first, second, third (etc.) display, where as cardinal directions only allow you to move around more intuitively. |
That's correct. Some navigate based on where they are, some on absolute numbers, and in both cases it's useful to use a position-based ordering. #554 accomplishes the cardinal directions use case by simply making the behaviour of "next" and "prev" position-based. |
After thinking about this for some time I have to say that I''m not a huge fan of the kind of selector provided in the first alternative. The second alternative which allows for setting a display order seems more reasonable, but I'm not sold yet. |
Implemented on master based on #554.
|
Fixed in v7.0.0. |
When scripting keybindings with yabai, it's often the case that Mission Control's choice of display order is unrelated to the physical and logical positioning of the displays. If it were possible to select displays sorted by position, it would be straightforward to map, say, alt-{w,e,r} to always indicate leftmost, middle, and rightmost.
My proposal for the selectors would be something like:
The text was updated successfully, but these errors were encountered: