Antonín Říha

> Plus it's how Awesome works. And personally if I'm opening a window while something is fullscreen it's probably because I want to use it immediately. This does make sense....

> I would very much prefer this handled from the config (through window rules & signals) than a hardcoded behavior. The reason I chose to go with WM like awesome...

I understood it as, everything apart from the surface tree, should not be visible and below the fullscreen surface. But honestly, not really sure which reading is correct. I would...

> What idle command are you running? You might be powering the output off which leads to a disconnect, in which case adding signals for enable/disable aren't what you want....

> Instead of enable/disable signals, I think we should instead fix OutputSignal::connect so that it fires correctly on all connections (though since you've already done some work here I guess...

Looking into it. I think what must be happening is this. When my monitor turns on again, it goes here: https://github.com/pinnacle-comp/pinnacle/blob/main/src/backend/udev.rs#L1068 Which maps everything and basically turns it on (starts...

But you are right that ```rust if let Some(_mode) = mode { self.set_output_enabled(output, true); ``` Shouldn't be there. I will debug things more to really find out what is going...

Ok, this now this starts to make sense. When this happens, I don't get connect signals because that one is emitted only when there is no saved state for the...

That is a very fair point. Supporting both focus models is definitely the ideal outcome. My experience with sloppy focus on other compositors has been that the focus always follows...

I've used sloppy focus in other compositors (qtile, river, dwl, river) and all of those do work as I suggest (as far as I can remember it has been while...