Repository navigation
Introduce a BrightnessManager - #2916
leolost2605 wants to merge 8 commits into
Conversation
|
@garaevdi if you want to take a look :) I fixed the build issues for now by forcing vala to use a certain include order This follows the gnome shell implementation a bit (mostly regarding to using logical monitors and the global scale calculation which will be used by keybinds to change all monitor brightnesses at the same time while keeping the ratio between the monitors) |
Oh, that's smart, didn't know about this trick 😅️ At a glance your implementation looks much cleaner, I'll close my PR. Just a suggestion: how about implicitly placing primary monitor at array's start, so interface consumers could highlight it somehow? |
1e6d19f to
df2bd3a
Compare
Good idea, did that :) I also added support for the interface the gnome settings daemon expects for auto brightness and dimming on idle and added some docs for the dbus interface. Should be ready for an initial review now |
19f4187 to
650081b
Compare
650081b to
53d1dba
Compare
53d1dba to
ad6a844
Compare
ad6a844 to
f773c14
Compare
garaevdi
left a comment
There was a problem hiding this comment.
I don't have rights to actually approve this, but other than this one comment, LGTM
|
|
||
| set_relative_brightness (backlight, value); | ||
| backlights.add (backlight); | ||
| backlight.notify["brightness"].connect (on_brightness_changed); |
There was a problem hiding this comment.
Is this needed? It seems like there is a signal loop here because when rapidly changing brightness (e.g. when scrolling over the indicator) brightness eventually resets back to 1.0 even with the writing_backlights guard in place. Without this everything seems to work fine. Does mutter change Backlight.brightness on its own without our knowledge?
Make it build by making sure vala first includes meta/display which contains the necessary macros for the others. I will properly fix this by upstreaming the missing header includes.