It already does here: m_active ? m_active->title() : "". Just leave the label as %title% (or don't set it at all so it will be set as default to that) and no "Window: " will be shown.

Sorry, maybe I didn't express myself clearly. I want the "Window: " part to be shown, but it only makes sense to be shown when there actually is an active window. IMO, the desired behavior should be as follows:

Terminal window active -> output: "Window: Terminal"
No window active -> no output

while the current behavior is

No window active -> output: "Window: "

I doubt anyone wants that stray "Window: " part or a window icon without any text to replace %title%. Maybe that is the behavior you want, though. I don't know, just wanna be sure you understand what I mean, since the m_active ? m_active->title() : "" does something very different from what I implemented here.

Maybe it's easiest explained with pictures. So this is what I want, see how there's a window icon in front the window's name:

However, the current behavior when there isn't an active window is the following (the icon is still there and looks ugly), and there's currently no way to change this:

I changed this behavior to the following:

I understand now. I think it should be set as an option (like no-window-blank = true) or create another label just for this purpose, because otherwise this behaviour deviates from what is normally expected.

I would prefer, if another label or format was used to keep it consistent with what other modules do

Ok, I guess the most consistent way would be to use two labels label-active and label-unactive? I can start working on this.

Yeah, almost. Either create a second format format-empty and let it have a separate label like label-empty (similar to what the network module does), or just have a second label and use label, if there is a window title and label-empty when there is not (this is what the xworkspaces module does wher <label-state> is replaced depending on the module state). The main label needs to be called label though, because it would break polybar configs when changed.

Alright this should do :)

Here ya go. Hit me up if you want me to squash commits and/or follow some kind of commit naming scheme!

We're gonna squash and merge this one anyway, but in the future try to follow the de facto standard git commit message rules and also try to structure structure the first line as purpose(target): msg

Where purpose is what the commit does and is usually fix or feat (for feature) and target is the name of the component your commit is affecting. Just target: msg is also fine. See our commit history for some examples