Johan Malm

> Technically we could even go fancy and load other implementations dynamically from an external library path. Downside of that is that plugins (and thus labwc) will break on refactors...

It might be caused by transparent drop-shadows. Do you still get it if you run `labwc` like this: `WLR_SCENE_DISABLE_VISIBILITY=1 labwc` Ref: - https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/docs/env_vars.md?ref_type=heads

Agree with Consolatis. Last time we discussed this we concluded that the volume of "poorly worded" issues was low and that those probably wouldn't improve much by enforcing a template...

Thanks for researching and coming up with solutions. > As we're in cooldown period, maybe we should postpone this fix and revert #1751 for now. Let's forward fix. I'll test...

Thanks for working on this. I suggest we go for the time-based approach because (a) it has worked on Openbox; and (b) I wouldn't be surprised if touch events (emulating...

> The immediate-close is actually happening even without movement when the menu opens above or on the left of the cursor (e.g. when clicking on the bottom or right of...

> Yeah, repositioning the menu would work around the issue and it is at least deterministic (e.g. always under the cursor or never under the cursor). But the actual issue...

Had swaylock crashed or was it just not locking one output/screen? It might be related to this swaylock issue. Would you be able to run with the `swaylock-logged` script suggested...

We added support for ext-session-lock protocol a couple of weeks ago, but if the `0.17.0` branch has not been rebased since (so does not include this). Could you confirm that...

Can't get to an extra screen for a couple of days, but when I do I will try connecting/disconnecting to see if I can reproduce it.