feat: add window transparency effect #864
Open
+245
−17
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lars-berger
requested changes
Nov 27, 2024
jackssrt
force-pushed
the
feat-add-window-transparency-effect
branch
from
e14e363 to
9009457
Compare
|
Git is confusing... Sorry! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.