9 Years of Brightness Controller - Experience, Gratitude and Lessons Learned
It has been (a little over) nine years since I first started working on Brightness Controller for Linux. My goals were simple when making this,
a) learn Python as a programming language and
b) solve a pain point for me.
Turns out that my pain point is also a pain point for other people!
Somehow, it gained attention from nice people across the Internet. It got featured in OMG Ubuntu, people suggested it on Reddit, and some suggested that it should be integrated into KDE by Default or at least they should make something similar. Collaborators joined in and helped make Brightness Controller way better than ever possible and helped make this available across Ubuntu PPA, Arch Linux AUR, and more. Just from PPA alone, Brightness Controller has been downloaded about 160K times! For all these, I am grateful.
Future of Brightness Controller
People still email me about ideas, suggestions, and new features - such as 1) keyboard shortcuts, 2) setting brightness based on a preset on start-up, 3) making it adjust brightness and color temperature automatically like f.lux or Redshift, 4) making it not be overwritten by f.lux or redshift and 5) finally - making it compatible with Wayland.
Of these, some of them are possible (1-3), and some of them are technically impossible or simply out of my hand (4 and 5). Many of them are good to have. Indeed, I receive new pull requests implementing new features sometimes. However, progress has slowed down due to the following:
- I use a Macbook for work purposes these days, so even if I can check and run code. Even though PyQt works cross-platform, I can not test the actual Brightness Controlling function enabled by
xrandr, the backend. It does not work anywhere except Linux, as far as I know. - More importantly, I have way more on my hands than before!
It seems like someone else will have to take up the mantle to do it! 😅
Indeed, I fixed several weird, silly bugs last weekend and completely changed the structure of the project to make it more future-proof when it comes to packaging and publishing. Before that, the last major change happened over a year ago. But that’s okay - Brightness Controller was built with several key design principles in mind. It does not do much, but whatever it is supposed to do, does it well, hopefully.
Lessons Learned
I am a believer in Less is more and Separation of Concern concepts when it comes to designing and programming.
Separation of Concern (SoC): I tried to make sure I follow them when making Brightness Controller. If you look at the code, you will probably notice that it is badly written, long, verbose, and does not follow OOP that well. But it still follows SoC, which has helped me maintain the code base for the last decade. Therefore, if you write code, make sure you follow this principle. 😉
Less is More: The reason why Brightness Controller works is that it is created to contain no nonsense. I could’ve tried to force in lots of fancy functionalities over time. Do you know what that would mean? More Bugs! No one wants that. Hence, making it simple is better in the long run!
Third Party APIS is a Pain: Things keep changing outside the scope of Brightness Controller. For example, Wayland will possibly replace xrandr-supported displays soon in Linux entirely, and I do not see anything at this point that can be used as the backend for Brightness Controller in Wayland.
If It ain’t Broken, Don’t Fix it: Self-explanatory, to be honest. 😉
Anyway, that’s all I wanted to talk about. Have fun people.
Brightness Controller will always be free. Free as in free beer, and free from any type of data tracking whatsoever. Heck, I have no way of knowing how many people are using it right now. It solved my problem, and I hope it solved yours too and gave your eyes some relief.
To comment as guest, click on the field "Name". The option to do so will become visible.
লগইন ছাড়াই কমেন্ট করতে নাম এ ক্লিক করুন, দেখবেন তার নিচেই আছে অতিথি হিসাবে কমেন্ট করার অপশন।