-
Notifications
You must be signed in to change notification settings - Fork 243
feat: add window transparency effect #864
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
feat: add window transparency effect #864
Conversation
e14e363
to
9009457
Compare
Git is confusing... Sorry! |
Absolutely huge! Thanks a bunch with the help on this ❤️ Sorry about the long wait with getting this merged - will get out a new release with this included next week. |
@jackssrt Just wanted to give a heads up about some follow-up changes that affect this feature (#939). Since the config value for the opacity could potentially be a delta value, I ended up separating that out into another command and then only allowed non-delta values for the config So the end result looks something like this for the cli commands:
|
Thanks for merging! And nice catch with the delta value being in the config, I didn't think of that... |
🎉 This PR is included in version 3.8.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 3.8.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Wait, does this also mean I could reduce the opacity of a certain window using a key binding? |
This PR adds a window transparency effect. The effect can be enabled in the window_effects config, or it can be manually invoked with an app command.
Some UX concerns
Not enabling the effect in both the focused_windows and other_windows effect config will cause GlazeWM to just leave the transparency applied by the enabled one be.If the user uses the app command to change the transparency, the window effect will override the manual transparency change the next time it updates.
Some users might not expect this behavior.
Code architecture problem
I wrote a TODO comment about using saturating_sub_signed when it's stable. Since we use nightly, we can simply enable it, but I don't know if that's okay with everyone. Also, that would entail using a bigger int type, since i8 is between -128 and 128. Maybe it's best just to keep using a boolean for the sign? Perhaps we could use an enum somehow?It would also be nice if we could write this once and then have every command use the same system for handling delta values.