Usability of window borders - potential removal

[koekeishiya]

Edit2:

Improved border system has been implemented on master. See #565

Edit:

Borders have been moved into a standalone application: https://github.com/koekeishiya/limelight

---

Original post:

So after using yabai for a while now, I find that window borders are pretty much just annoying. In an ideal world they would be a great addition, but it is just not possible to do that without injecting code into every single application.

My issue is mainly the fact that we have to use an external window, and cannot actually just override the border attribute of the actual NSWindow.

By using an external window we hit a couple of unfixable issues that really degrade the experience of this feature. These include, but are not limited to:

1. The border is always slightly delayed when moving or resizing a window.
2. The border is treated as a separate entity in the window sorting/layering of the operating system, making it pretty much impossible to avoid issues where the border is incorrectly drawn below/above some other window.
3. The fact that we always have to try and keep the border in sync with the active space of the window it belongs to at any time, and the lack of APIs to receive events for such actions, there is also a noticeable performance impact when the number of windows grow large enough (lower threshold for lower-end machines).

The main thing I care about that would need a replacement in case borders are removed, is the visual feedback for the region selected through the --insert command.

Thoughts?

[dominiklohmann]

The window borders as is are of much lower quality than the rest of yabai. I'm all for this change, especially with the maintainability and performance aspects in mind.

[koekeishiya]

I'm very much leaning towards just pruning borders. I mainly created this issue just to get some thoughts. I'll leave it up for a while so people can post their opinion, but yeah, I think it's for the better to let it go.

[RowanFeely]

Im running macos mojave (10.14.6) and i use the borders feature religiously simply to remove the absolutely horrible looking white line border edge that the OS renders on all windows.

as such im well versed in the shortcomings of the borders feature and understand why its going on the firing line, but does anyone have any alternative solutions to getting rid of the window edge? I'm hoping theres some method i haven't come across yet. Anyway, despite it being an always used feature by me, i still understand why it needs to be dropped.

[rockyzhang24]

Yeah, the border performance annoys me a lot. When I turn it off, I find I cannot live without it, but if I leave it on for a while, its bad performance pushes me to turn it off.

1). What I was thinking at the beginning is that using the border to differentiate the active window and non-active windows. Especially when I opened many terminal windows on a single workspace and all of them looked the same (black background and no decorators like title bar), without using the border, I had to use the cursor shape to distinguish which one was active and sometimes I had to spend a while to look for the solid cursor among many terminal windows.

2). What's more, I used the border to show the region selection (--insert) as you mentioned.

Due to its bad performance and issues as you listed, I turn it off half a month ago. Based on my user experience without using the border, I find I get used to it. For 1). I find that the situation where I cannot find the active window only happens when I leave my desk and come back after a while because I cannot remember where my cursor is. However, if I sit in front of my desk and continue working, each cursor movement (i.e., focus changing) is initiative and we know where the cursor is subconsciously even when I switch between workspaces frequently. For 2). The same. Region selection is always followed by a window creation. So we don't need the visual mark. We just need to select a position and then create a new window. That's it.

My opinion is that no border is better than having a terrible one. However, if we could come up with a way to show the visual feedback, that would be perfect.

Thank you for your hard-working!

[1g0rb0hm]

I am using the window border feature as a visual cue to indicate I am operating in a different skhd mode. It is a bit like the visual cues in nvim and other modal editors and is important to not get lost.

I also realise that there are some glitches with borders and understand why you are considering to remove them. If that happens, do you have a suggestion how to achieve a good visual feedback when changing modes in skhd?

Here is what things look like in action starting with the definition of modes in .skhdrc:

# add an on_enter command to the default mode
:: default   : yabai -m config window_border_width         3;\
               yabai -m config active_window_border_color  0xFFF0DFA7;\
               yabai -m config active_window_opacity       1.0;\
               yabai -m config normal_window_opacity       0.9

:: window  @ : yabai -m config window_border_width         3 ;\
               yabai -m config active_window_border_color  0xff6795FF ;\
               yabai -m config active_window_opacity       0.8 ;\
               yabai -m config normal_window_opacity       0.6

# from 'default' mode, activate mode 'window' (`0x39` -> CAPS LOCK)
cmd - x       ; window
# from 'window' mode, activate mode 'default'
window < cmd - x    ; default
window < escape     ; default
window < i          ; default

And here a little screencast showing what happens when I switch modes (NOTE how window opacity and border colours change and it is the change of border colours that is responsible for the key visual feedback during a mode change in skhd):

NOTE that I also changed the colour of the bar for the case when there were no windows on a screen and I changed modes. Unfortunately the bar is gone now in 034ee3a1fd1a263ee21c6654ff6317493abbca5e and I haven't found a good way to achieve the same with the default macOS menu bar.

[koekeishiya]

I think I've pretty much made up my mind and reached the conclusion that window borders will be removed. The required changes have already been added to the master branch.

To answer some of your questions.. I realize that it is hard to replace the visual customizations that borders have provided, and I don't actually have any good alternative approaches to achieve said effects.

@RowanFeely

Im running macos mojave (10.14.6) and i use the borders feature religiously simply to remove the absolutely horrible looking white line border edge that the OS renders on all windows.

I don't actually think I have seen this issue and I don't really have any good solution that you could switch to.

@yanzhang0219

However, if we could come up with a way to show the visual feedback, that would be perfect.

The visual feedback for the insert command remain mostly unchanged from a users perspective. It is a bit less customizable than before, but I think this is a fine compromise.

@1g0rb0hm

I am using the window border feature as a visual cue to indicate I am operating in a different skhd mode. It is a bit like the visual cues in nvim and other modal editors and is important to not get lost.

This one is hard to replace, and the only solution I can think of (although not really visual) would be to use a bitbar script or adding an entry in your bar (if you use a custom one) that will read the current mode from a text-file or something. Then write to that text file in your skhd binds that change mode. This is far from as effective as your current solution though.

NOTE that I also changed the colour of the bar for the case when there were no windows on a screen and I changed modes. Unfortunately the bar is gone now in 034ee3a and I haven't found a good way to achieve the same with the default macOS menu bar.

The yabai bar was extracted into a standalone application if you wish to continue using it, see #463; that should allow you to keep that part of your config.

[distek]

I know it's a bit late since you've made up your mind, but could we have just a focused window border?

Main benefits being: Visual cue as to which window is active Insert indicator still usable

Though it's not much, these can be an integral part of someone's usage.

[koekeishiya]

There are other software out there that will provide a border for the focused window. The visual feedback for the insert command is still present.

[cmacrae]

Hope people don't mind me commenting on this so soon after it was closed, but I'm hoping it may serve as a good place for a few of us to discuss alternatives to window borders.

I'm personally coming up short - how do others intend to indicate the currently selected window?

[koekeishiya]

I'm simply using window opacity (works fine if you set duration to 0.0) and cursor placement to indicate the focused window. You could use Honer.app or make something similar if you want a border for the focused window. I suppose it would also be fairly trivial to make a small application that would temporarily highlight the focused window for a couple of seconds, then terminate, that you could activate with a bind from skhd.

[koekeishiya]

I put together a simple sample program that will give you a focused window border. This is not exstensively tested and probably lacks in some ways. It is not customizable without editing the source and is purely meant to give people a starting point.

I don't mind if people want to submit pull requests, and maybe I will make changes if people report bugs or whatever, but this is a no strings attached thing.

Repo: https://github.com/koekeishiya/limelight

[cmacrae]

Thanks so much for putting together this example @koekeishiya 🙏
Really appreciate it! I'm going to have a play around with it. Nothing like a global lockdown to help encourage learning new languages ✨

[cmacrae]

Extra points for the name & default colour 🥝

[koekeishiya]

Updated the sample with mission-control detection as that is non-trivial for those unfamiliar with the private APIs.

[BlueDrink9]

I personally loved the window borders, and was happy to put up with the issues. Would you consider making it an optional legacy module? I used it for skhd mode change, for focused window, for general ricing pleasure, and for insert feedback (no longer needed).

If it really is a hassle to work around the other parts of yabai, I totally accept your choice to remove it to save yourself hassle. I can find alternative workarounds. But just wanted to put my thoughts on borders

[koekeishiya]

@BlueDrink9 Is it the focused border you care about in particular, or did you find inactive borders to be just as "important"?

[BlueDrink9]

I liked inactive borders but focussed was more important. From an aesthetic perspective, having focussed borders with no balancing unfocussed borders is weird. Also, when I'm in 'manage window' mode in skhd, having all borders is more useful.

I'm looking at honer etc, but honer's successor isn't OSS.

I also use trasnparency for the focussed window but that's very subtle

Having the dock change colour would be a great way to indicate manage mode, so I might look into that

[minjaegi]

Unactivated windows are transparent. Even if the opacity is set high (0.95), it is very annoying if the background that reflects back is not clean.

There are situations in which people refer to inactive windows, not just looking at active windows." (When you're working, you can refer to other windows, or you can watch YouTube, movies, or other monitoring.) I hope the border problem improves even if it's slow.

[BlueDrink9]

Tbh I'm happy for yabai to not be the thing that provides window borders, but it just doesn't seem like there's a good alternative. Could the code be stripped out into a separate repo? Or is that what you've done with limelight?

[Dolcio]

Is the visual feedback command supposed to show a color when you switch or add windows? I added yabai -m config insert_feedback_color 0xaad75f5f to my .yabairc as per the example config, but I don't see the color reflected anywhere.

I was also a fan of the window borders and would be happy to see either a legacy module or separate program, as suggested above. Thanks much for your work... yabai is a fantastic utility.

[distek]

So due to the work I do, I need to have SIP enabled. Due to this, transparency on inactive windows is not really an option for me.

The two things that are most important to me are active window border and insert direction.

It appears limelight can provide both of these, so that should work for my use case.

I think limelight is a reasonable solution to the removal of borders from the main code base.

[koekeishiya]

@Dolcio The visual feedback is there to show the region that the next window to be tiled on a given space is going to use, when activated manually using the yabai -m window --insert <..> command.

[minjaegi]

I think it's a good idea to display the border only for the active window like chunkwm, rather than dropping the border option. I think that displaying the border line to the inactive window is a factor of performance degradation. The important thing is the border of the active window.

[ghost]

Hi, sorry for asking, but how can I install Yabai 2.4.3 with Brew? I want to keep the borders in my windows for now, the performance is not that good but works well in my machine and I really like the aesthetics.

[lcjnil]

@johnkirstenlai try with brew install https://raw.githubusercontent.com/koekeishiya/homebrew-formulae/026eefaade6cc3e73fc98beb6122fced164d5e10/yabai.rb

[dominiklohmann]

This can also be used, although I don't recommend doing so.

git -C $(brew --repository koekeishiya/formulae) 026eefaade6cc3e73fc98beb6122fced164d5e10 -- yabai.rb
brew reinstall yabai
git -C $(brew --repository koekeishiya/formulae) master -- yabai.rb
brew pin yabai

[cmacrae]

With the new availability of the Nix package (#510), this is also achievable in a declarative manner using an overlay with overrideAttrs:

self: super: {
  yabai = super.yabai.overrideAttrs (o: {
    version = "2.4.3";
    src = super.fetchFromGitHub {
      owner = "koekeishiya";
      repo = "yabai";
      rev = "v2.4.3";
      sha256 = "1a6pqms5kwdsvr9vcshfa000xf2f5a2qbp5qapx0b3wzclnchjbn";
    };
  });
}

[dominiklohmann]

@cmacrae To be fair, the user asking for help downgrading a Homebrew package to an older version (which is well documented) is unlikely to use Nix.

Admittedly in an ideal world we'd all use Nix, but that's just not very practical.

[cmacrae]

Sure, figured I'd share for the sake of others who may take an interest also :)

[ghost]

@dominiklohmann I researched before on google how to install a specific version of a package in Brew, I didn't find a quick way to do it so this is why I asked here, I just wanted to go back to how things were so I can get back to work, no need to be rude, i'm just a novice in this macos world, as I said, I apologize for the question.

Yes, I didn't know anything about Nix, thanks @cmacrae for introducing me, now I have a chance to try it here, thanks to all for your help.

[emanuelhouse]

Despite the slight performance issues and issues with them getting hidden behind windows, I love the borders: both for getting rid of the rounded corners as well as removing the unsightly white border at the top of windows. I use the borders both for focused and unfocused windows. Is it possible to move the border functionality to a separate app?

Have any others found a suitable replacement for drawing borders on all windows?

[narze]

I just updated to Yabai v3 and thought that it was broken due to missing borders.

I understand and ok with you removing features but it would be great to list all of the options removed so every will update their yabairc file instead of changing them with no effect and get confused like I do.

So I'd suggest listing them in changelog rather than just Status Bar removed & Borders removed

[koekeishiya]

I figured it was pretty self-explanatory that all border/status bar related commands that where not explicitly mentioned in the changed section was removed. I suppose I can list the removed commands explicitly in the future.

With regards to updating in general, see my comment https://github.com/koekeishiya/yabai/issues/500#issuecomment-622937019

[glepnir]

After removing the border, yabai seems to lose a lot of beauty. I am a loyal border user. Is it possible to regain the border in version 3.0? Instead of installing the lower version.

[rockyzhang24]

@glepnir check this please https://github.com/koekeishiya/limelight

[pardom]

This change was a surprise to me after updating recently, and is a serious UX degradation for my workflow. I'm trying out this as an alternative: https://hazeover.com

[koekeishiya]

Please see this comment regarding updating: https://github.com/koekeishiya/yabai/issues/500#issuecomment-622937019

Also for people who want a focused window border, see https://github.com/koekeishiya/limelight It does not allow setting the color during runtime, but that should be fairly trivial for anyone to add.

[glepnir]

I don't think it's a good decision to strip out the border feature, whether i3 or awesome it is built-in and available.

[koekeishiya]

The reason for the decision is described pretty fairly in my first post. I understand that not everyone is happy with this, but as mentioned there is an actual OS limitation to the quality that can be provided, and it does not fit the bar I have for this project.

[BlueDrink9]

Would you consider duplicating more of the functionality that yabai/chunkwm had in Limelight? Or are you set on leaving that for others?

[koekeishiya]

I don't plan on implementing more of the functionality at this point in time.

[daphen]

Just writing here to tell you that I'm one of the (few??) people who really value the aesthetics of having borders both for inactive and active windows higher than a slight bump in perf. Reverted to 2.4.3 and I guess I'll never get to upgrade again, unfortunate. 😅

[koekeishiya]

Did a basic port of the yabai v2.4.3 border system to limelight branch: https://github.com/koekeishiya/limelight/tree/yabai_borders https://github.com/koekeishiya/limelight

[koekeishiya]

Pushed it over the limelight master branch. It has feature parity with the border system from yabai. Syntax of the commands have changed a little, see the sample configuration file in the repo.

Notes for building and automatically running is in the readme. Config location uses same structure as yabai.

[BlueDrink9]

Thank you so much!

[daphen]

Wow, kudos on the quick work. Thanks a lot.

[BlueDrink9]

Working brilliantly, although there's a large delay between the border appearing the default colour, and the config initialising the desired colours.

I'd like to figure out a way to close it when yabai closes, to use it as a way of knowing whether yabai has started.

[koekeishiya]

Working brilliantly, although there's a large delay between the border appearing the default colour, and the config initialising the desired colours.

In theory this should not be a longer delay than it was originally in yabai. It uses the same bootstrapping code for tracking applications/windows, and the same config system.

[koekeishiya]

An improved window border system has been implemented on master. See #565 for details.