Closed xrun1 closed 10 months ago
Hello. I will push an update soon that applies the Awesome patches to herbstluftwm.
Basically making the Awesome patches also apply when passing in wm-support = "herb"
I'll get onto this in 14 hours and release it as 1.2.9.
In a future update I will attempt to make wm detection automatic.
Thank you for your patience!
In terms of the issue with animatons, i'll look at that just after i push 1.2.9
@xrun1 1.2.9
is now out. Can you please test it with this line and let me know if it fixes any of the issues.
wm-support = "herb";
Thanks for the fast response! 1.2.9 is definitely better, though some issues remain:
default dampening dampening 20
I also tested corner rounding and found some problems (should I open a separate Issue for that?):
herbstclient set frame_bg_transparent false
herbstclient set frame_bg_normal_color '#00000000'
herbstclient set frame_bg_active_color '#00000000'
* The docs say the default window unmap animation is zoom, but it looks like a slide down or fly out for windows here, I suppose that's part of the position problem I first mentioned.
I am genuinely confused because it is impossible unless you changed the animation for it to be anything except these values. (Ignore that unmap window animation uses a variable called OPEN, its just how it works) I would recommend specifying the animations you want just in case.
.animation_for_open_window = OPEN_WINDOW_ANIMATION_ZOOM,
.animation_for_unmap_window = OPEN_WINDOW_ANIMATION_SLIDE_DOWN,
Closing the last terminal in a frame, though, shows no animation for the term while the frame's borders zoom in, which looks awkward, it'd be better if that border didn't move until the frame itself is closed.
From my knowledge there is not a huge amount i can do about this unfortunatley. I would have to install your WM and test it myself to confirm if this is an actual issue with picom, with the WM or with your configuration.
I will have a go at installing herbstlufwm
in a couple of hours. In the mean time please test out the sample configuration and see if it resolves any issues.
Something I noticed in your configuration is you use large floating point values. This is not required or advised, please just use 1.0
or 0.3
inactive-opacity = 1.000000; shadow-opacity = 0.300000;
@xrun1
I set the unmap option explicitly and the correct animation plays now. With zoom
, closing the last terminal in a frame plays the animation properly, and the frame border re-zooming looks a lot less jarring. Maybe the wiki's mention of default value is incorrect? I noticed that the picom.sample.conf
has unmap set to slide-down
by default.
For the floats, no worries, I pasted the config file generated by Home Manager but it's not what I actually specify when I write my settings on NixOS.
Glad to hear things are working better now.
Would you be able to quickly recap for me what the rest of the issues are?
Sure, here you go:
For empty frames when the frame_bg_transparent
hlwm setting is on (herbstclient set frame_bg_transparent true
), currently mitigable by setting it off and using #00000000
for frame_bg_normal_color
/frame_bg_active_color
instead :
@xrun1
Sorry for taking so long, I installed herbstluftwm
on NixOS and didn't observe any of the issues you described.
Would you be able to provide some detailed instructions on how to reproduce the issues?
I will double check to see if it is a WM issue or an issue with your setup somehow.
Did you make sure to use the config file provided in the first message? You can run the script manually after the WM has already started, in case your Nix config generates its own autostart
.
Did you make sure to use the config file provided in the first message? You can run the script manually after the WM has already started, in case your Nix config generates its own
autostart
.
Sorry I missed it. I'll work on testing the issue now.
@xrun1
After doing some testing it seems the issue you have presented are not an issue with herbstluftwm
itself. I'll now go over the issues you mentioned to me that I tested.
When multiple windows are in a frame that uses the max layout and tab bar is displayed, opening/closing/switching between these windows results in a wrong animation where they appear to fly in and out from the top-left corner of the top-left-most monitor.
After testing this with multiple windows and following the instructions you gave I was not able to reproduce this. From what I can see in the video, from what you showed could it be a issue with tmux
or the terminal tabs program you are using?
Problem with the bottom/right borders blinking (visible when spawning frames or even switching workspaces), the effect differs and affects different windows depending on the animation dampening and clamp settings.
I also could not reproduce this issue. The only thing I noticed was that empty frames borders are cut of at the corners when using corner-radius
.
When round corners are on, in a tabbed frame: the outer border seen on inactive tabs takes the color of the border that wraps that window + active tab, so it shows green instead of black.
I couldn't replicate this but from the video you showed it seems to be another issue with tmux
or whatever you are using to create terminal tabs. I would look into its configuration to see if it is dimming the color on inactive tabs.
Overall I couldn't reproduce quite a few of those issues and I am running 1.3.2
with wm-support = "herb";
set.
Just to check are you using the NixOS unstable package or the custom package in the releases page?
from what you showed could it be a issue with tmux or the terminal tabs program you are using?
The tab bar is rendered by the WM itself, it should appear when configured to do so (and the provided script does).
Just to check are you using the NixOS unstable package or the custom package in the releases page?
I'm using this repo as a flake input.
Anyway, I've dived into the code myself to at least deal with the tabbing animation problem. After two hours, here's what I found:
w->pending_g.x/y
change originates from here:
https://github.com/allusive-dev/picom-allusive/blob/e4d7d9822f7e1823b72d019ddec954e1940aa0eb/src/event.c#L221-L227xdotool
, I've confirmed that indeed, hlwm moves hidden tabs to a negative position of about -100 - window.width, -100 - window.height
(not 100% exact due to decorations/borders), this is why the windows appear to fly in and out from the most top left cornerhide_covered_windows
setting is enabled, to prevent tabs from rendering behind each others others in the case of windows with transparent backgroundsIf wm-support=herb
is on, then maybe we can skip doing position animations if w->pending_g.x < -(w->g.width) && w->pending_g.y < -(w->g.height)
(i.e. window is completely hidden off-screen)?
@xrun1 Thank you very much for looking into that. I am working on the check for whether a window is off screen or not right now and I will get back to you soon.
@xrun1 I cannot replicate opening terminals as tabs so I am not sure how to test whether the fix I have made has worked or not. I will commit the changes to the repo but I won't publish a release. If your flake setup can build straight from the repo that would be great, if not please let me know.
I made made a PR for an improved fix, maybe later I'll try to actually animate the tabs properly if you're OK with adding an animate config option that only works for one WM (for now at least)
I made made a PR for an improved fix, maybe later I'll try to actually animate the tabs properly if you're OK with adding an animate config option that only works for one WM (for now at least)
Thank you very much for the help with fixing that. I wouldn't mind adding some specific WM support as long as it is not too complicated.
I'm going to close this Issue now but if you want to continue looking into adding custom features for Herbstluftwm we can resume that in another issue.
What is the issue When multiple windows are in a frame that uses the max layout (one window visible at a time, showing a tab bar if configured to do so), opening/closing/switching between windows results in a wrong animation where they appear to fly in and out from the top-left corner of the top-left-most monitor. Empty frames also display visual garbage unless I run picom with
--wm-support=awesome
.Here is a basic HLWM config script to reproduce the setup (Copy to a
~/.config/herbstluftwm
folder and name the fileautostart
, thenherbstluftwm --locked
to launch the WM from a TTY). With the specified keybinds:Mod4-Return
to open a terminal in the default frame (kitty
by default)Mod4-Ctrl-l
to split that frame to the right and focus it, with standard picom it should just be transparent with a black borderMod4-Alt-h/l
to resize the frameMod4-Return
to open a second terminalMod4-Return
to open a third terminal as a tab, this time the animation is wrongMod4-space
andMod4-Shift-space
Mod4-x
What did you expect Transparent frames and correct animations
Relevant Images or Videos:
https://github.com/allusive-dev/picom-allusive/assets/126838916/61e83972-fb48-4875-ac0e-f2c97f4d11e6
https://github.com/allusive-dev/picom-allusive/assets/126838916/dc8a6495-c918-462c-9908-aac5903c4c31
Your configuration
Package Version: v1.2.6 Build Method: NixOS flake with Home Manager WM: Herbstluftwm