Per-window border configuration

[shajra]

Hi, I'm not sure if this is possible, but I thought I'd start an issue to see.

A feature like this could be used in tandem with #45 to do something like style a stacked window differently from an unstacked one. I'd use a double border... (maybe just on the top? to suggest stacking, but I'd still want the coloring to be focus-based, like a dim color and a brighter highlight.

There are probably many programmatic ways to accomplish this, and probably with more versatility for my preferences of border-doubling and coloring.

For me, this would all be driven with my SketchyBar configuration.

But maybe this request is too difficult given the current APIs.

[FelixKratz]

Do you want to have different styles in the unfocused state, or just different states in the focused state? Because different styles in the focused state are easily scriptable, but different unfocused border styles are not possible currently. It would be easily possible to include something like this though with some extra book keeping, where a window identified by its id
could receive a different set of stlye settings.

[shajra]

I was really hoping for a different border style in the unfocused state. I don't try to open too many windows, but sometimes it happens. And tools like yours help me organize more windows than otherwise.

To date, I've avoided stacking. But I use tabs (a similar feature) in i3 on Linux very often and casually. The biggest difference is that tabs give me some indication of where windows have been stashed. I'll forget otherwise. If I forget which windows have been stacked, stacking feels like an overcomplicated version of hiding, which I already have with ⌘H.

But if I had borders to indicate stacking, I might use them as frequently as I use tabs in i3.

[FelixKratz]

The backbone for this feature is now available, now it only needs a syntax design. I would likely want to address the border for a specific window by its parent window id, as available in the yabai query system.

[FelixKratz]

I have now exposed this feature on master through the additional option apply-to=<window-id>. All options modified in this specific borders invocation are then applied only to the given window.

If you have some feedback or improvement ideas let me know.

[aspauldingcode]

I just compiled from master to try this.
Now I have a fully working multi-monitor windowed-fullscreen toggle!

multi-monitor_windowed_fullscreen_working.mp4

I have now exposed this feature on master through the additional option apply-to=<window-id>. All options modified in this specific borders invocation are then applied only to the given window.
If you have some feedback or improvement ideas let me know.

My feedback is to include it in the manpages if not already, and either include a custom function to find the window id or reference this: yabai -m query --windows --window | jq -r '."id"' to find the window id.

[FelixKratz]

After using the feature implemented from #57, I use a command to set the borders style=round or style=square for toggling gaps. However, after toggling fullscreen on then back off (with another custom script that uses apply-to= for hiding the border), the custom toggle-gaps command only applies to the windows which didn't invoke apply-to=.

Maybe there's a way to reset the border invocation of apply-to=<window-id> like reset=<window-id>, so that it continues to work with regular borders commands that don't use apply-to=<window-id>.

The question is how an "apply-to" window should behave once a global change of properties is issued.
Currently, all windows that have used "apply-to" have their own properties and thus are not affected anymore by global config calls.

The other way would be to reset all "apply-to" rules once a global config call is made. This could however also not lead to the desired behavior.

The third way is a combination of both. It is possible to only change the properties that are changed globally in the "apply-to" window. So all properties not changed globally would persist for those windows. This will probably be the way I want to do it personally.

[aspauldingcode]

The third way is a combination of both. It is possible to only change the properties that are changed globally in the "apply-to" window. So all properties not changed globally would persist for those windows. This will probably be the way I want to do it personally.

So… maybe you’re saying we could do something like

borders apply-to=”windowid” global-events=on/off

so when we run the apply-to borders command, we can choose to listen to global config calls or not to the window id?