Question about window borders about yabai

[koekeishiya]

Borders are now drawn with HiDPI.

[daphen]

Hm, I'm having an issue where if I click in a window after activating it, the MacOS border takes over the z-index of the Yabai border and makes it look weird, any ideas?

Active window:

Active window after clicking inside of it:

Edit: Latest Catalina by the way.

[koekeishiya]

@daphen

See my reply in #310

[koekeishiya]

Is the inner radius being zero because I'm High Sierra, or does it work the same as Mojave?̊̈

The inner radius appears to be zero because of how the radius is calculated, and should appear the same on High Sierra and Mojave. If you look closely at the screenshot in the readme.md it also appears like that.

Is it expected for the border to be drawn inside of the window or is it not working in High Sierra?̊̈

The border is drawn exactly on (and thus inside) the window, because it annoys me when borders of multiple windows overlap, because they are outside the window-frame.

I have made some changes on the master branch that add a small inset to the border frame, and tweaked the radius calculation a bit, such that the inner part of the corner also appear rounded.

By doing this, if you have a window_gap of 0, their borders will now partially overlap, as I mentioned above. Can you build from master and let me know if you find this new look to be acceptable?

I'm trying to not expose too much in the config, as while it is important to let people customize the behaviour; requiring too much tweaking to get a usable experience is also not good.

[goranmoomin]

Hmm... rebuilt yabai from HEAD, but is still seeing the same thing as before :-(
Inner radius is still zero, and borders are still drawn inside:

[koekeishiya]

Hmm weird, maybe there is a difference between systems then, or your build didn't update properly.

This is how it looks for me now:

[goranmoomin]

@koekeishiya Confirmed! I didn't restart the home-brew service :-(
Looks much better now..., but I get the feeling that the borders are pixelated...
It doesn't feel right in retina displays... IMHO

[koekeishiya]

but I get the feeling that the borders are pixelated...
It doesn't feel right in retina displays... IMHO

Currently it does not render borders using HiDPI as far as I can tell. I am using private APIs to create the border windows because I want to stay out of objective-c and Cocoa APIs as much as possible. There is likely some setting that is required to enable HiDPI support. I'll look into this more at some point.

[goranmoomin]

I'll look into this more at some point.
Great... Looking forward :-)
BTW, it looks like the updated code for borders cause borders appear everywhere!

[dominiklohmann]

Isn't it wrong to assume a 2x resolution? The default for a new MacBook Pro right now is 1680x1050 on a 2880x1800 display, which is not 2x. Also there might be multi-monitor setups using different scaling factors across multiple displays. Maybe there is a way to get the window resolution / scaling factor of the window you're drawing the border on and re-use that factor?

[koekeishiya]

Isn't it wrong to assume a 2x resolution? The default for a new MacBook Pro right now is 1680x1050 on a 2880x1800 display, which is not 2x. Also there might be multi-monitor setups using different scaling factors across multiple displays. Maybe there is a way to get the window resolution / scaling factor of the window you're drawing the border on and re-use that factor?

I suppose in the case of a multi-monitor setup, you are correct. For the built-in / Apple screens I would assume this piece of documentation remain accurate.

The value of this property is 2.0 for high-resolution scaled display modes, and 1.0 for all other cases.

From https://developer.apple.com/documentation/appkit/nswindow/1419459-backingscalefactor?language=objc

Edge-case: What happens if a window is 50% located on a retina display, and 50% on a non-retina display?

[koekeishiya]

I disabled retina resolution on my MBP and started borders still work properly, they are just drawn without HiDPI as expected, so I think that is probably a non-issue. There is likely support in the WindowServer that validates that the window can be drawn with HiDPI on the display it is drawn to, and if that display does not support HiDPI, it will fall back to LowDPI.

Edit:

Also tried to have one display with HiDPI, and one without. Moving a window back and forth properly shows the correct resolution, regardless of which display the border was originally created on.

[goranmoomin]

@koekeishiya The updated HIDPI borders look awesome! :-)
The only thing blocking me turning on borders is the (new?) bug about displaying borders everywhere :-(

[koekeishiya]

bug about displaying borders everywhere

This won't be fixable until a window rules system is in place. Currently, all elements on the screen that are reported as windows by macOS will get a border. The fix is to first check if the element is an actual window, but many non-windows report that they are, and many windows report that they aren't (e.g: Emacs among others).

[goranmoomin]

@koekeishiya Ah, will be looking forwards for the window rules :-)
About the window rules, I decided to go to emacs-mac which has a better macOS GUI support :-)

Currently almost migrated to yabai.... 👍

[koekeishiya]

By doing this, if you have a window_gap of 0, their borders will now partially overlap, as I mentioned above.

This started to annoy me again so on the latest master we adjust the window frame if it has a visible border to accommodate the inset value.

[goranmoomin]

@koekeishiya What about drawing borders outside if gap > 2 * border-width,
on the borders (like the master before b4f9d32) if 2 * border-width > gap > border-width
and inside if gap <= border-width?

_{Sent with GitHawk}

[koekeishiya]

I'll stick with the current border placement for now. Also made it such that borders are only created for actual windows. Applications that report an incorrect role for their windows will not get a border.

Closing this as resolved.

[daphen]

@daphen

See my reply in #310

Thank you!