Perhaps, wmv broken about core HOT 17 CLOSED

Could you explain how the issie happened in the first place? What did you do, what happened and how?

Also, are you using a fixed version or a specific commit?

from core.

I experimented with wmiutils, using your post.
These commands cause the window to jump while moving across the screen.

super + !button{1,3}
    {wmv,wrs} -a %i %i $(pfw)

I also try this

super + !button{1,3}
    {wmv,wrs} -a $(wmp) $(pfw)

but nothing changed.

My wmutils from 6c37 crux-ports-git repo

from core.

I don't see any wmutils port in their repo, so your version might be outdated.

When called with the -a switch, wmv will move the window so that it is centered on the pointer (latest version put the pointer in the bottom right corner) so upon each call, the window will be "teleported" to the pointer's location. That might explain why the window "jumps" to a different location.

from core.

Here

Maybe it helps - the largest "jumping" window makes at the right bottom corner and smallest at the top left. But jumping is not always the same size, it depends on the previous movements.

from core.

I'm confused. What do you mean it depends on the previous movements?

Let's say $w is ypur window's width, amd $h its heigt.
wmv -a 500 300 $wid will move the window at position (500 - $w), (300 - $h).

If you run wmv -a $(wmp) $(pfw), does it work correctly?

from core.

Have you tried launching sxhkd with this launch option? I was getting a similar issue with both bspwm and wmutils and this fixed it for me.

sxhkd -f 100 &

from core.

@dylanaraps I already use this option

from core.

If you run wmv -a $(wmp) $(pfw), does it work correctly?

No

I think better to make a video to show how it looks.

from core.

Could please be more explicit than just a simple "no". We won't get your issue fixed if you don't provide any informations.

What's the original geometry? Where does it move? What's the original geometry?

from core.

Currently trying to record demonstration of this as I've been able to reproduce this issue.

wmv -a seems to depend on the current window position, which it clearly shouldn't.

Only problem now is that ffmpeg doesn't cooperate (window content that it records updates ridiculously slowly (framerate of around 1/sec), while mouse movement is displayed immediately). This somehow doesn't happen in i3. EDIT: somehow happens only in X sessions started with startx. Stuff started by my display manager works correctly. EDIT2: Now I'm totally confused: wmutils session started by my DM has the problem, but i3 started by startx doesn't. i3 started from inside wmutils does have the problem...

from core.

Here's a webm: Link

Firefox doesn't seem to like the webm (may have to do with yuv444p), but it displays fine in vlc.

Because of the aforementioned issue in my setup, recording of window content lags behind and is updated only once a second, so the terminal input seems jagged and sometimes the wmv ... command line only appears at the same time as the window movement is done.

from core.

Ok, I get the issue. Thanks for the webm. I used to have this problem before, but it should have been fixed in libwm with this commit: be6ff33. Are you using the latest wmutils version (that now relies on libwm) ?

from core.

I just noticed that the AUR doesn't have libwm and therefore doesn't build the new wmutils properly. Created a fixed package and submitted libwm-git to the aur. This bug is now fixed.

However, when repeatedly calling wmv with sxhkd, I notice jagged movement of the windows. I haven't tried -f 100 yet, will do tomorrow

from core.

If you find anything interresting, please report. This is not an issue I have on my setup, so I'm curious about it.

Thanks for your help and time!

from core.

I installed libwm, wmutils and wmutils-opt out of your crux ports, and now everything works. I'm sorry to trouble you.

from core.

Yup, everything fine here. sxhkd -f 100 fixed it.

My guess is that this happens because of the overhead of starting a shell for the command and that sometimes a wmv call is executed before the one preceding it, creating strange jagged movements.

I'd say we can close this as it is an unrelated threading race condition issue.

from core.

Ok, Thanks for investigating.

from core.