Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Info about devel state #21

Open
raven2cz opened this issue Mar 3, 2023 · 6 comments
Open

Info about devel state #21

raven2cz opened this issue Mar 3, 2023 · 6 comments

Comments

@raven2cz
Copy link

raven2cz commented Mar 3, 2023

Any progress with your work? Is it possible to use it with AwesomeWM now? Or is it still dwm specific?

@FT-Labs
Copy link
Owner

FT-Labs commented Mar 15, 2023

Aside from workspace, it will work in anything with X11. I will handle generic support soon I hope

@FT-Labs
Copy link
Owner

FT-Labs commented Apr 22, 2023

Could you try generalanimation branch please?

@raven2cz
Copy link
Author

Thx. I will test it.

@raven2cz
Copy link
Author

I tested it. The record FT-Labs-picom-1.mkv is provided by my cloud. Link is here

https://1drv.ms/f/s!Aq_X66v0FnfLloNc4xivJnh22GtRuA?e=goQG6g

Overall, the tested animations are running well. However, there is one fundamental issue that will need to be addressed. It's present in all the picom branches we tested, and unfortunately, this is no exception.

It is possible to completely disable animations for windows that are being moved by the mouse, i.e., completely turn off animations for normal window movement. This is not just for client windows, but also for drag-and-drop file copying where the movement of the icon is extremely slow. Anything that is operated by the mouse should not be slowed down by any additional animations. Animations have no place there.

This is not just applicable to the floating layout; it's a general window movement issue. The natural way of working cannot be affected, especially by slow sliding animations. If it's just regular tile windows and their rearrangement, then that's fine because it helps to see where the window is being moved and actually helps a lot.

Window maximization is also beautiful, as well as the animation of swapping component images, as seen in the video. Everything is great, but animations should not slow down normal window movement and icon dragging.

@unai-ndz
Copy link

This could work for floating windows in awesomewm but animation-exclude is broken and works 1 out of 10 times, the other 9 times X11 just stops redrawing/moving the window or it is invisible in the first place.
It also needs extra code in your awesome config to write the property into the windows, ping me if you are interested as it's pretty off-topic.

animation-exclude = [
  "_AWESOME_FLOATING@:c = 1",
];

But tbh I got used to the "slow" floating windows in a week and the icon can be ignored when drag and dropping, just follow the mouse.

@raven2cz
Copy link
Author

But I don't want to get used to it. This is not about compromise, I see this as a serious problem with the whole Picom approach to these animations. By default, animations should be disabled for basic tasks and only enabled for desired actions, such as maximizing, moving in tiling layout, or fadeInOut effects for pop-up windows. However, basic window and icon operations must be unaffected, otherwise we cannot discuss the general use of the library.

willothy pushed a commit to willothy/picom that referenced this issue Feb 6, 2024
flake: Use nixpkgs-unstable and stop using url literals
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants