This adds a new option, colors.unfocused-alpha. When set to a value < 1.0, the entire window (everything - all bg/fg colors, images etc) are made transparent while the window does not have keyboard focus.
The way this is implemented (trying to keep the patch small), we need to do full-screen repaints while in this mode.
That is, all screen updates result in full-screen repaints when:
The window does not have keyboard focus
The window just gained keyboard focus (i.e. last frame was rendered with transparency)
As such, one can expect a fairly large performance impact when there’s large amount of output while the window is unfocused.
Focused windows are unaffected, as are unfocused windows when colors.unfocused-alpha == 1.0.
I haven't decided if I want to merge this or not, as it might be too "flashy" for foot; feedback is welcome ;)
edit: thinking about this some more, this is something better done server side. I'll keep this PR open for the time being, and will try to keep it up to date. But I don't think I'll merge it.
note: tested and works in KDE, Sway and River (and all other wlroots based compositors, I would guess), but does not work in GNOME or Weston. Go blame them.
I don't see how it's possible to both have working alpha, and get the error message. It's just not possible. When foot prints that error message it does not update the unfocused alpha value. You're seeing this error message from echo -e '\e[>q'the same foot instance where focus/unfocus alpha is working? Not from a footclient running against a foot server that hasn't been restarted?
There was definitely no server running (I generally don't use it), but at the same time I can't reproduce it now... Unfortunately, I haven't saved that config.
Inside a running foot, that did generate the error log, what does echo -e '\e[>q' say?
That's expected; the response isn't meant to be human-readable, and consists of a full escape sequence. It just happens to be readable enough, that it is the best way of checking the actual version of a running terminal.