battery: make scroll change brightness

[carterprince]

battery_scroll_sensitivity is a new option that specifies the amount (in percentage points) that each scroll event will change the brightness. I found 1.8 to be a good default as a compromise between smooth (touchpad) scrolling and discrete (mouse-wheel) scrolling.

I wrote a method change_brightness() which reads and writes to /sys/class/backlight/ to change the brightness. This requires that the running user be in the video group. Personally I'm fine with this but I want to hear what everyone else thinks.

If I break some conventions here I apologize; I'm not very familiar with how you're supposed to do stuff in C++. Please let me know.

Also, I haven't tested this on any machine other than my laptop. So if it doesn't work for you also let me know.

Resolves #207

[soreau]

I wrote a method change_brightness() which reads and writes to /sys/class/backlight/ to change the brightness. This requires that the running user be in the video group. Personally I'm fine with this but I want to hear what everyone else thinks.

I think your original idea of using brightnessctl made more sense. I also think there should be an option to make the command configurable as @ammen99 suggested in #207. Maybe you can have two options, one defining the command for brighter and the other dimmer. Then you could possibly bind scroll 1-1 and eliminate the sensitivity option. Either way, you could call the options directly, as commands for the scroll events.

[ammen99]

I agree with @soreau, on some of my previous laptops brightness was rather hard to change and one had to use different files in sys. Also you get the problem of min/max brightness etc. It would be better to let the user provide a command themselves. If you care about smooth scrolling too much, you could make the command a format string. I.e option value is brightnessctl %.2f and then the widget replaces the %.2f with the scroll delta with sprintf. Though I suspect discrete steps should be fine enough.

[carterprince]

Thanks for the feedback. I reverted to the original approach with the latest commit, added battery_scrollup_command and battery_scrolldown_command options, and took @ammen99's original suggestion of running commands every 3 steps of discrete scroll.

Let me know if you have any other suggestions.

[soreau]

Why not do it on every discrete event at 3% by default? It seems like you're losing some granularity and possibly introducing buggy behavior by doing nothing on some scroll events.

[carterprince]

Sorry, I was just doing what I thought ammen99 originally suggested. It just made sense to me because running so many commands at once makes the brightness update laggy on my system.

[ammen99]

Sounds like another thing which ought to be an option (granularity)

[ammen99]

How does GDK behave when we have smooth scroll, do we get separate events for discrete and smooth scrolling, or are they bunched here together? Can delta_* be a floating point number?

In general I am kinda hesitant to have a hard threshold like this (i.e update every 3 events). Wouldn't it be better to update on every X units of scroll, or even better, every milliseconds, where N is a configurable period of time?

[soreau]

To complicate things further, there is also GdkEventScroll.GdkScrollDirection, which tells when the delta_x/y values are valid to use or which direction to scroll.