Problems with 2ecfa9a (window masking and hiding) about warpd HOT 11 CLOSED

905a310

Do you mean 2ecfa9a? 905a310 was the commit before that.

First it broke conky when using own_window_type = 'override'

Both warpd and conky (when configured) set the override redirect mask of the window to prevent the window manager from interfering with them. It seems like conky is trying to draw itself over warpd, but I can't seem to get it to do that on my machine.

conky runs but doesn't show up unless when warp appears and you can see that warp is masking out conky.

I have been unable to replicate this behaviour on spectrwm. What is your window manager?

Another problem/thing Is that warpd is now animated! But why is that? Well is
just picom's transition.

It is likely that the compositor handles window movement differently from window creation which would explain the regression. However I can't reproduce this to confirm.

I think it would be time to let warpd's window have a wm_class property
at least so that we can set those compositor rules to it.

I've set the WM_CLASS property to "warpd_hints" in the latest commit.

from warpd.

from warpd.

Oh sorry yes it was 2ecfa9a. I will test if the last commit fixed the conky bug and report soon!

Oh the compositor issue is because my picom is seeing warpd as a window since 2ecfa9a for some reason and it wants to animate it which might be not desirable but this is not warpd's fault at all anyway.

It would fit as a new feature though, to have a wm_class, name, title and etc set by warpd so that it can be matched by picom or any compositor and use this to do further customization. For example transparency could be done like this instead, also blur, and whatever else those compositors do these days. I wasn't able to match it with "warpd", "Warpd", "warp" or "Warp" and doesn't seem the window class attribute is being set anywhere.

from warpd.

Oh thanks warpd_hints wm_class works now! You could set this to just warpd though, I think it would make mare more sense.

I still have the conky bug though even on 9e4484f. It wont happen if you lanch conky first and then warpd, only if you launch conky with warpd already running (run warpd and then conky).

from warpd.

Oh the compositor issue is because my picom is seeing warpd as a window since 2ecfa9a

Nothing about the window has changed, the only difference is that it never gets unmapped. My hypothesis is that the compositor doesn't like the move operation (which was previously not present), but again I can't seem to reproduce this issue on my machine.

You could set this to just warpd though, I think it make mare more sense.

My original intention was to have different classes for each kind of window warpd creates (like the grid/normal cursor) but I can't think of any reason that one would want to have separate rules for these so I have changed the class to "warpd" as suggested.

I still have the conky bug though even on 9e4484f. It wont happen if you lanch conky first and then warpd, only if you launch conky with warpd already running (run warpd and then conky).

Given that it is likely a bug with conky you will have to hope for a patch. I downloaded the source to see if I could find the bug but abandoned the attempt after realizing I would have to contaminate my system with an unreasonable number of packages. Have you considered using a less bloated alternative?

from warpd.

You could set this to just warpd though, I think it make mare more sense.

My original intention was to have different classes for each kind of window warpd creates (like the grid/normal cursor) but I can't think of any reason that one would want to have separate rules for these so I have changed the class to "warpd" as suggested.

Oh that's not a bad idea thinking it better now but, it is just way more intuitive leaving it as warpd for all windows! I guess that is fine.

Given that it is likely a bug with conky you will have to hope for a patch. I downloaded the source to see if I could find the bug but abandoned the attempt after realizing I would have to contaminate my system with an unreasonable number of packages. Have you considered using a less bloated alternative?

An alternative to conky? And is there any? :P Well no I didn't think on replacing it. Maybe open an issue there then, someone might know what is going on. This could also be an issue with X11 itself.

from warpd.

An alternative to conky? And is there any? :P Well no I didn't think on replacing it

Apparently not. I haven't used it for several years but tried googling around for a bit to find a dearth of options (which is surprising given the simplicity of the concept). There are plenty of bars though :P.

Maybe open an issue there then, someone might know what is going on. This could also be an issue with X11 itself.

It is unlikely an X related issue. It probably has something to do with the way conky stacks itself when using override redirect (it probably doesn't account for other programs which might draw on the root window).

from warpd.

Apparently not. I haven't used it for several years but tried googling around for a bit to find a dearth of options (which is surprising given the simplicity of the concept). There are plenty of bars though :P.

Yeah conky is pretty great and I've spent some time to get quite a few fancy things working on it. And only with that window_override option I can get it to lay bellow all windows on my twm (qtile).

It is unlikely an X related issue. It probably has something to do with the way conky stacks itself when using override redirect (it probably doesn't account for other programs which might draw on the root window).

I will open an issue there.

from warpd.

Another problem I realized with this new implementation is that warpd is not covering floating windows anymore. It covers tiled ones only. My tilling window manager is qtile. I didn't test on other ones.

from warpd.

from warpd.

Nice! With be6730c It is above all windows now it seems!
Conky still have the exact same problem for me. As a workaround I just have to make sure I launch conky first and then warpd. I think this can be closed since it is becoming clear is not warpd's fault.

from warpd.