scenefx
scenefx copied to clipboard
Wlroots 0.18.1
TinyWL runs. Can't really test Sway yet though.
- [x] Update to 0.18.1
Requires: #54
Working implementation: https://github.com/ErikReider/fx-comp/pull/9
@WillPower3309 Should we also bump the scenefx version as well? (To make it easier for packagers and comp that use older versions of wlroots)
@WillPower3309 Should we also bump the scenefx version as well? (To make it easier for packagers and comp that use older versions of wlroots)
Yup! Need to bump for the last wlroots bump then will merge this
Tested it in https://github.com/ErikReider/fx-comp/pull/9 and everything seems to be working as expected! :D
i know this is well ahead of the curve, but trying on the latest wlroots 0.19 seems like removal of XDG clipping makes all the shadows and rounded corners wonky on gtk like the comment on it mentioned... did a bad job backporting on https://github.com/0xNULLderef/scenefx/tree/wlroots-0.19 for the sake of my own config but are there any plans to tackle this? i see the opaque region being defined but i have no idea how it relates to the actual rendered window contents
tested apps are meld and waterfox (should be the same as firefox) that show a padding around the window and no rounded corners (tinywl from src tree) eglgears_wayland and kitty did not have such issues as i think they use the raw wl egl surface
i know this is well ahead of the curve, but trying on the latest wlroots 0.19 seems like removal of XDG clipping makes all the shadows and rounded corners wonky on gtk like the comment on it mentioned... did a bad job backporting on https://github.com/0xNULLderef/scenefx/tree/wlroots-0.19 for the sake of my own config but are there any plans to tackle this? i see the opaque region being defined but i have no idea how it relates to the actual rendered window contents
So we don't only officially support their main branch due to them not actually having a release of 0.19 yet, so we haven't checked for compatibility as of yet. So you'll kinda be on your own on this front until we port it to 0.19 in the coming months
I read that they didn't remove the geometry, but moved it instead. Have you tried using that property?
eglgears_wayland and kitty did not have such issues as i think they use the raw wl egl surface
This is due to client side decoration. The GTK toplevels have decorations like shadows and grabbing edges that affect the size of the toplevel if not compensated for, using it's geometry field :)
needs rebase / merge from main