Just the window transparency

[24unix]

Would it be possible to take the code from yabai, remove all that window managing stuff and have just custom transparency per active/inactive App?

If yes, how much would you guess that would cost?

A big plus would be to keep spaces intact.
(No desktops have separate space any more).

[Liquidmantis]

Seems like there might be better solutions than Yabai, but you could just change the default to be floating instead of BSP.

[24unix]

I didn't find them so far. Before Big Sur I used Deskovery III

I just want the transparency, and if possible functional spaces.

[24unix]

Now I gave it a try in a VM and now on my live stem.

I recompiled yabai without the check for separate spaces, and it works like a charm.

I've got my desktops back (I can again attach an app to a desktop, not a display anymore).

I'll now build a menubar app for changing the opacity on the fly and try to get familiar with the code from yabai to remove all which is unrelated to my needs.

So, I'm still very grateful for yabai, although it was not exactly what I was missing from Linux on macOS, but a great step towards the right direction.

Is it possible to change the opacity on an app or windows base?

[24unix]

@koekeishiya Could you make the check for checking for separate spaces optional/overwrite-able?

As ist seems, there are no changes needed within yabai besides that.

[24unix]

I've got a first working prototype.

It doesn't parse yabairc, but makes a backup before overwriting.

Edit: There is currently no color picker in SwiftUI, it is marked as beta for 11.0, I'll check later for that in a Big Sur VM.

[24unix]

Oh, I got one like, thanks. Was not sure if someone is interested, but even if it is only for me, I'm happier than ever with my desktop.
Currently sandboxing has to be disabled, so when someone wants a copy, I can open up my Git Repo, it should be easy to clone, open in Xcode and build/run. Will test it soon.

That is the result from today:

[24unix]

So upgraded to Big Sur.

Recompiled yabai 3.3.1.

Transparency doesn't work anymore :-(

[koekeishiya]

You also need to reinstall the scripting-addition bundled in yabai v3.3.1 (or newer). sudo yabai --install-sa
Also note this comment: #589 (comment)

[24unix]

I did:

╰─➤ sudo yabai --uninstall-sa
sudo yabai --install-sa
sudo yabai --load-sa

[koekeishiya]

Hmm I don't know then; everything works just fine for me:

[24unix]

OK, that gives hope that theres some wrong with just my setup.

When I issue: yabai -m config active_window_opacity 0.90

the command hangs forever. I'll try again with debugging enabled.
Debug output shows nothing related to opacity.

[24unix]

Ah, I had to codesign the binary again.

Thanks for your help, I was afraid Apple broke this really (for me) cool feature.

[24unix]

So, with Big Sur in SwiftUi arrived a ColorPicker, but it broke the layout …

[24unix]

@koekeishiya As you are reading here, can you give me feedback to my question 8 days ago?

A switch or config option to ignore the check for separate spaces? So I could use the upstream release and don't have to change yabai.c for every version.

When my tool is finished (for me) I'l release it under MIT as yabai is. Optionally maybe a paid precompiled version in the App Store, but I guess who is able to build yabai from source or with Homebrew won't need that kind of comfort.

[koekeishiya]

I'm not convinced that is a good idea. I know for sure that High Sierra and Mojave does not work correctly when displays have separate spaces is disabled. As long as yabai supports multiple macOS versions; my aim will be to keep the codebase as unified as possible to prevent compexity and/or obscurity caused by minor differences between OS versions.

[24unix]

But it would be just optional for users like me who just use Float layout.
So, an option that is parsed if existing else won't do any harm.

I don't want to fork Yabai, it currently works great. Only I have to comment the check for separate spaces before each build.

I tried to implement it myself and send you a PR, but it seems like the check is performed before parsing the config file.

A bit long kind of an explanation, you don't have to all read is, my main wish is described above.

My setup is an iMac with two additional Displays. I have separate displays for each space, so separate Desktops. So, I have desktops like main, Xcode, webdev, local, hosting etc.
Switching between them with mission control (shortcuts) is fast and smooth. Shortcuts are limited to 16 spaces, too less for me, 3 displays x 8 spaces => 24. Not good.
I tried with skhd, but switching is way slower.

And: If I have shared spaces, I can attach an App to a desktop, not just a display.

So, that option would be a great benefit for me. No need to change the source for every version. You just have to implement it once, and it won't harm anybody who is using Yabai in a different way than me.

Of course I'm willing to pay the time you need to implement that change, as it is important for me. I spend 8-12 hours a day, 7 seven days a week at my iMac. And really, really enjoy that transparency, as I can watch shells behind my Xcode, PHPStorm or even Browser.

I could image many more options for my tool, preferences per app, per space, if there is feedback and demand.
But I'd like it to work with the upstream version of Yabai.

[24unix]

P.S. My tool will only work with Big Sur and above, due to limits in SwiftUI.

[24unix]

Ok, I finally found a way to use yabai in the upstream version, still using more spaces than directly supported by Mission Control without losing my Desktops.
I used TotalSpaces2, it can maintain spaces per display and plays nicely with yabai.

Will post a blog for it the other day.

[koekeishiya]

You could talk directly to the scripting addition without having to proxy through yabai -m commands, but then you would need to figure out some way to automate your dependency on the scripting addition that is bundled inside the yabai binary (updates, installation, loading upon system login etc.).

The available options can be found by looking at the handle_message function here:
https://github.com/koekeishiya/yabai/blob/master/src/osax/payload.m#L739

Look at functions starting here and below to figure out how to call the above functions:
https://github.com/koekeishiya/yabai/blob/master/src/osax/sa.m#L523

You probably need to look at how these are used within yabai to figure out the type of the parameters (e.g internal ids, etc.).

[24unix]

Thanks for the reply, but currently the way with using yabai -m seems to work good enough.