Open mksafavi opened 11 months ago
Hi @MkSafavi, thanks a ton for the detailed issue! Appreciate all the details and the reproduction steps. I'll have a look this weekend.
Ok I've had a look and I'm unable to reproduce.
Just so we've eliminated one thing, could you try the develop
branch and see if the problem persists?
I'll try the develop branch on the weekend.
I tried the release version again. I can only reproduce it consistently with wm_property = "name"
.
With wm_property = "class"
It happens once after starting i3wsr. And after that It was kinda random I couldn't identify how exactly it happened.
Did you try it with two monitors? I tried it with a single monitor and I couldn't reproduce it with either. I feel like it's a niche dual monitor problem that would be really hard to find.
Thanks again 👍
Yes I did try with multiple monitors, and was unable to reproduce. Did you get a chance to try the dev branch?
Hi. I just built the develop branch. and it happens as well. It also happens when moving floating windows between monitors with mouse (holding meta key and dragging window between monitors) Could it be from my I3 setup? I'm running the arch repo build. Maybe I can try with a clean config to see if happens.
hmm, yeah give a clean config a try. EDIT: removed a question that has been answered already
Hi again, did you ever get a chance to try a clean config? I suspect the issue might be with the i3 option focus_follows_mouse
, but even with that on, I don't see the behavior you're reporting.
Just letting you know I was able to reproduce some odd behavior when moving windows between monitors, looking into it.
Hi
Hi again, did you ever get a chance to try a clean config? I suspect the issue might be with the i3 option
focus_follows_mouse
, but even with that on, I don't see the behavior you're reporting.
Turning focus_follows_mouse
off didn't change the behavior on my machine.
I did try with a clean i3 config file. the issue was the same. I didn't get a chance to try with a new install yet.
Just letting you know I was able to reproduce some odd behavior when moving windows between monitors, looking into it.
good to hear that. 👍
I have the same/similar issue with 2 monitors. Randomly when moving or closing any window the active workspace can change.
@roosta any updates on this? do you think this may be an issue with i3's API?
Hi @Ali-Flt, I've tried, I refactored the whole app to try to get to the bottom of it, but I simply couldn't find a solution that worked. I'm not sure if its an i3 API issue or not, but IIRC i was able to reproduce the issue using i3-ipc. That doesn't necessarily mean anything, could still be an issue with i3wsr.
I was able to narrow it down a bit though, maybe I'll have a look again later, see if I can get any further
@roosta thanks for the update. I created an issue in i3's repo about this as well: https://github.com/i3/i3/issues/5924
Has anyone been able to capture a log of this? I can give it a go next week as I see this almost daily.
i3wsr only logs errors, you'll have to modify the source to see the actual IPC commands. I might consider adding a verbose logging option, but for now you can print here: https://github.com/roosta/i3wsr/blob/f78810047c5edb53032974297700116de7150b25/src/lib.rs#L252-L255
Add this:
dbg!(&command)
Description:
when i3wsr is running, if you hover mouse over i3bar (any window with type of _NET_WM_WINDOW_TYPE_DOCK) under certain situations it changes the workspace to the first one. It happens when the currently focused workspace is renamed. personally I experienced it with dual monitor setup but I've heard it's also happens with a single monitor(needs verification) I also replicated this issue with python i3ipc and it had the same behavior as i3wsr. So I think the problem might not be from i3wsr itself but given that dynamically renaming workspaces is not an i3 feature, I thought I should discuss this issue here first.
steps to reproduce:
clip showing the same procedure:![issue.webm](https://github.com/roosta/i3wsr/assets/50653293/03bd99a3-2c15-4b3d-85c3-e4e3ad67bcac)
further information:
While investigating the source of the bug, I found some workarounds to reduce the occurrence of this issue. normally you would traverse the workspace tree and renamed all the workspaces. To make it happen less often, I changed it so that it only renamed the effected workspaces. for
title
new
events, it is possible to get the workspace name and only rename that workspace. formove
andclose
, I had to check if the names changed and only rename those workspaces. which again made the bug trigger way less.