Incorrect handling of Herbstluftwm tabbed frames

xrun1 commented 10 months ago

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 file autostart, then herbstluftwm --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 border
Mod4-Alt-h/l to resize the frame
Mod4-Return to open a second terminal
Mod4-Return to open a third terminal as a tab, this time the animation is wrong
Switch between the tabs with Mod4-space and Mod4-Shift-space
Close a tab or empty frame with 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

active-opacity = 1.000000;
animation-clamping = false;
backend = "glx";
fade-delta = 10;
fade-exclude = [  ];
fade-in-step = 0.028000;
fade-out-step = 0.030000;
fading = true;
glx-no-stencil = true;
inactive-opacity = 1.000000;
opacity-rule = [  ];
shadow = true;
shadow-exclude = [ "window_type *= 'tooltip'" , "! name~=''" , "_GTK_FRAME_EXTENTS@:c" , "class_g = 'slop'" ];
shadow-offset-x = 0;
shadow-offset-y = 0;
shadow-opacity = 0.300000;
shadow-radius = 5;
vsync = true;
wintypes: { dropdown_menu = { opacity = 1.000000; }; popup_menu = { opacity = 1.000000; }; };
xinerama-shadow-crop = true;

Package Version: v1.2.6 Build Method: NixOS flake with Home Manager WM: Herbstluftwm

allusive-dev commented 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!

allusive-dev commented 10 months ago

In terms of the issue with animatons, i'll look at that just after i push 1.2.9

allusive-dev commented 10 months ago

@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";

xrun1 commented 10 months ago

Thanks for the fast response! 1.2.9 is definitely better, though some issues remain:

default dampening dampening 20

There's a problem with the bottom/right borders blinking, the effect differs and affects different windows depending on the animation dampening and clamp settings
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. 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
While the empty frame is animated, its background doesn't update, you can see a portion of the wallpaper slide along. This doesn't happen when using the alternate way to get transparent frames I describe further below.

I also tested corner rounding and found some problems (should I open a separate Issue for that?): corners

The outer border of inactive tabs like "~" here is incorrect, it should be black like in the previous videos

The empty frame's clipping. Oddly, using this alternative way of getting transparent frames fixes it:

herbstclient set frame_bg_transparent false
herbstclient set frame_bg_normal_color '#00000000'
herbstclient set frame_bg_active_color '#00000000'

Typo here, the option is corner-radius

allusive-dev commented 10 months ago

* 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

xrun1 commented 10 months ago

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.

allusive-dev commented 10 months ago

Glad to hear things are working better now.

Would you be able to quickly recap for me what the rest of the issues are?

xrun1 commented 10 months ago

Sure, here you go:

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
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
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

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 :

While the frame is animated, its background doesn't update, you can see a portion of the wallpaper slide along
Rounded corners are invisible

allusive-dev commented 10 months ago

@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.

xrun1 commented 10 months ago

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.

allusive-dev commented 10 months ago

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.

allusive-dev commented 10 months ago

@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?

xrun1 commented 10 months ago

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:

The window open and unmap animations have nothing to do with this, they're not played in the case of tab switching
What instead plays is an animation of windows changing positions: https://github.com/allusive-dev/picom-allusive/blob/e4d7d9822f7e1823b72d019ddec954e1940aa0eb/src/win.c#L770-L777
The w->pending_g.x/y change originates from here: https://github.com/allusive-dev/picom-allusive/blob/e4d7d9822f7e1823b72d019ddec954e1940aa0eb/src/event.c#L221-L227
By watching the window's coordinates with xdotool, 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 corner
This movement happens here when the hlwm hide_covered_windows setting is enabled, to prevent tabs from rendering behind each others others in the case of windows with transparent backgrounds

If 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)?

allusive-dev commented 10 months ago

@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.

allusive-dev commented 10 months ago

@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.

xrun1 commented 10 months ago

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)

allusive-dev commented 10 months ago

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.

allusive-dev commented 10 months ago

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.

allusive-dev / compfy

Incorrect handling of Herbstluftwm tabbed frames #23