Inset borders
aspauldingcode opened this issue · 10 comments
Please allow us to apply an inset border style.
Yes, this please. I use the tiler Divvy, and the majority of the borders are invisible (either off-screen or under a closely-placed window).
Could you elaborate what exactly you mean by "inset border style"?
So, my understanding of this is: The 'inset border' would occupy / cover only the pixels occupied by the original window -- rather than being around the window, the highlighting would be within it. So, if I had two windows side-by-side each occupying 50% of the screen, the entire border of the active window would be visible. Presently, most of the pixels spill off onto my other monitors. The inset style would work vastly better for those of us who have coerced the Mac's ridiculous window manager to be tiling; I do this via Divvy, but I'm aware that there are other third-party solutions.
Yes.
The inset border style will instead overlay the window, rather than outline it.
The overlay helps because of the above reasons (Monitor window border overspill, it also allows us to see the borders over built-in window border decorations (removes need for disabling window decorations with something like MacForge SYMBLs, etc.)
In addition, it will be easier for us to create sharp corners (Also, instead of using a custom Aqua.car and DarkAqua.car theme for sharp corners, this requires a SYMBL called PaintCan, and MacForge SYMBL Loader). Sidestepping these is very important.
Default outline behavior: Each pixel is 1 more pixel outwards from the window edge. Outline may also be underneath the window.
Inset Overlay behavior: Each pixel is 1 more pixel inwards from the window edge. Inline must draw overtop the window.
See this issue for more technical detail regarding rendering on top of the window and especially the last comment if you want to have truly square borders (undocumented and unsupported options): #37
I still get minor 'spill' from one monitor to the next but that's pretty close to what I want ... However, now the borders flicker (e.g., as I'm typing this into Firefox, each keystroke (or, more likely, I'm assuming, each UI update that results from the keystrokes) causes the border to flash).
Yes thats why it is unsupported and undocumented, see #37 (comment)
Its a technical limitation in macOS. There is nothing we can do about it.
okay. Order above and order below works for me.
what I'd like to see now: ability to shift the amount of pixels inwards/outwards the border draws.
From the technical point of view this is just one line of code, however, it obviously only works if order=above, which is unsupported and undocumented because of severe technical limitations. So I am not sure it is the right path to include even more unsupported and undocumented arguments.
Hmm. Seems reasonable.
But, if there's anyone in the world who could try, I believe it's you.
You might find a way around those limitations(?) one day..