-
-
Notifications
You must be signed in to change notification settings - Fork 647
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
Removal of window borders #1889
Comments
Just to let you know @koekeishiya , I don't even know why I had expose as a shortcut in skhdrc as I have no use for it. When I did enter expose, I saw that borders was still there. Mentioning just in case you missed it!
|
Expose has its own borders )) |
Are there any alternatives to use? It's more difficult to distinguish the highlighted window without any window border color. |
Window borders was an amazing feature that is really worth keeping. Very sad to see it go. Hope you'll change your mind. |
You could try FelixKratz fork: https://github.com/FelixKratz/yabai |
Sad to see it go. For me this is a regression in the feature set for a tiling window manger. inb4 "make your own fork" |
Hammerspoon is far from perfect for that case. Better to use Felix's fork, as described by robrecord #1889 (comment) |
Is it possible to leave the option for users to use window borders, allowing us to choose whether we want the performance loss or not? |
It is not a matter of "performance loss". The functionality has literally been broken since the launch of macOS Ventura. See the 19 related issues for more details. |
I have been using borders on Ventura without issues. I don't use any animation nor expose or any macOS WM stuff (mainstage) though so it might not work with those I wouldn't know. I sincerely appreciate the hours put in to this project and I'm well aware of https://mikemcquaid.com/open-source-maintainers-owe-you-nothing/. That said removing a quite essential feature without much warning or switch to re enable "unsupported" feature seems like an odd choice. I respect that this is your project and ultimately you are in charge - I think this seems so out of the blue. |
I'm very grateful for your work @koekeishiya on Having said that, I really really have a hard time now that I don't know which of my windows has focus. Frankly, I do understand though the rationale for removing it, and I also don't think it makes sense to keep a broken feature, as it only creates more hassle the more time passes. But we're still left with the core problem: how can I easily identify the active window now? Does anyone have a suggestion on what can be done, within the confines of the current version, on how to do this? |
I completely agree with @aragalie. Yabai has helped me immensely over the years. Borders is the feature that made me use Yabai and not Amethyst. The only possible solution not mentioned here is window opacity. You can increase the transparency of inactive windows with this feature. I do not find this solution usable though. |
I fully agree. Unfortunately using transparency is not an option for silicon macs when one's using ios apps hence disabling sip is not possible. |
I mean I get it, I liked borders too when they worked, but I am the one dealing with all the support requests. As I said, all you have to do is look through the 19 issues connected to this one to get an idea of how exhausting that is. I am done with this topic now. |
i get being burned out on a billion perfectionist requests, but you could just ignore them instead of torching a perfectly good tool. i bet if you polled everyone you'd get 90%+ of people who never have a noticeable issue. don't be a slave to an ungrateful, vocal, minority. |
I think you are severely underestimating the number of people who go "nah fuck this" when something does not work, rather than reporting the issue. I know because I am usually one of them. I don't have issues with ungrateful people or whatever; I make decisions that I personally think are the correct way to go, and this happens to be one of them. If someone disagrees with decisions that I make they are free to make a fork or build their own software. |
@koekeishiya I completely understand you, as you offer your precious free time to develop and maintain this amazing tool. It's become irreplaceable in many people's daily workflow, including my own. Meaning: Thanks for your hard work! In that sense, I do think this still leaves the core problem: How to identify an active window? I can not, and probably would not if i had a choice, deactivate SIP, so any transparency configurations do not work, besides other things. As the borders are now gone, it has become impossible for me to identify an active window. Yabai is still valuable as a window manager, however if it is impossible to identify the current window, it becomes useless to fulfill this function. This a hard problem, that needs to be addressed, regardless of borders or not. Side Note Without deactivating SIP, certain things like switching, moving and refocusing apps to different desktop besides others are not possible, therefor i've been scripting my way around this with hammerspoon and lua. I've been able to do all things that i've been missing, including borders. However this is not ideal, only showcases that it is possible. Reason I am saying this is: It is possible, even with SIP, to do everything. (excluding transparency, i've tried with overlays but it's not ideal and i quickly deprecated that thought) Maybe there is a way for yabai as well, without adding too much effort in maintaining or using hacks. |
Just spitballing here, but would it be possible/feasible to pull the border highlighting functionality into its own standalone tool? My understanding is that this used to be the case (limelight?) so presumably there was a technical reason it needed to be pulled into yabai proper, but it does seem to me that conceptually at least, this is a completely orthogonal feature to the core of what yabai does, so if there is any way this could be done then maybe that would be the way forward that addresses the stability concerns while also giving folks the option of having the highlights if they really want it? Would love the author's insights into what sorts of technical roadblocks might be encountered with this approach. |
@DetachedHeadState I think this is more that possible to extract the features. Limelight is probably not feasible to pick up development on again however. |
I had some free time yesterday and hacked together a new standalone border system: https://github.com/FelixKratz/JankyBorders It does not use the accessibility API at all and should thus be faster. Feel free to contribute. |
Thanks! Will try soon. |
Outstanding. Lightning fast borders, like it should be. Thank You. |
Thanks, @FelixKratz, really appreciate your efforts, you are a lifesaver :) |
@FelixKratz you are the goat bruh. |
I am on macos 12 so I should not be affected by the border issues but I upgraded yabai to v6.0.1 (my mistake, I didn't know the borders would be removed) |
Removed by the maintainer here: koekeishiya/yabai#1889 Citing border functionality not working correctly since MacOS Ventura.
@FelixKratz Thanks for the additional tool, works great! 🙌🙌🙌 |
I forked the Homebrew formula and rolled it back to the v5.0.9 commit. You can install that version like: brew install SichangHe/yabai5/yabai |
Upgrade to yabai v6.0.10 and use https://github.com/FelixKratz/JankyBorders instead. |
coool will try
…On Fri, 26 Jan 2024 at 5:17 PM, Åsmund Vikane ***@***.***> wrote:
Upgrade to yabai v6.0.7 and use https://github.com/FelixKratz/JankyBorders
instead.
—
Reply to this email directly, view it on GitHub
<#1889 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIHB3TY2FSTS7K2N65AWST3YQNYDDAVCNFSM6AAAAAA5ZQB3V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJRG4ZDENRXGM>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
The window border functionality has had issues ever since macOS Ventura launched, and these issues persist in macOS Sonoma.
Some of these issues include, but are not limited to: incorrect z-ordering, incompatibility with window animations, incompatibility with topmost windows, weird lag upon window focus, inability to properly match corner radius of attached window, mission-control jankiness.
I will be removing this feature in an upcoming version of yabai.
Most of these issues are fairly trivial to solve iff the Apple WindowManager process is prevented from loading, as mentioned in various issues by @FelixKratz, but I am not interested in going that route.
It should not be particularly hard for a fork to reintroduce window borders in a patch if they wish to do so.
The text was updated successfully, but these errors were encountered: