There is also Clight (https://github.com/FedeDP/Clight) if you want automatic backlight adjusting given ambient brightness. It supports external monitors through ddcutil C library and has many more features to offer.
Disclaimer: i am its creator ;)
I've tried setting up clight on various occasions and now gave it a shot again, whilst I appreciate all the documentation I'm still struggling to get it working on NixOS with swaywm on a laptop. I'm primarily interested in adjusting screen brightness based on my webcam. I'm already using redshift/gammastep.
Uh that's sad! There is actually an issue opened about NixOS; but, since I am not using it, it's pretty hard for me to debug.
If you want some help you can comment on that issue though!
It actually has lots of improvements in the 6.0.0 pull request that i am delaying because i am too lazy (and haven't got much time) to fully rewrite doc.
There are some developers who think that OOP is a bless; other developers think that OOP is a sh*t and try to stay away from it as much as possible.
I think that just like everything else in the world, it has some benefits and some downsides.
For me, the greatest benefit is that it enforces some sort of code modularity/standardization and helps people keep their code organized. Note that i am not asserting that any OO code is inherently better written.
While designing libmodule, i always focused on that, plus being simple that, imo, should always be the primary goal while writing any library.
Yes, that's it. Indeed i'm really open to support other platforms; i used linux-only epoll because of its beautiful API and only support linux because i can only test on it.
If anybody asks for support for some other OS, i can think about switching to poll(), even if i find epoll-like interfaces to be much more enjoyable to work with. As stated on project's readme, any patch is welcome.
About licensing, GPL is my usual choice there.
If you think any of these points is crucial, and you'd like some changes, please fill a bug report.
I cannot say much about AzPainter, sorry.
Libmodule is designed to be flexible enough in managing events, so if you are writing any event driven software and that event exposes a file descriptor, you should be able to use libmodule without any issue.
Indeed, i recently added bsd + osx support in libmodule (https://github.com/FedeDP/libmodule/tree/kqueue_support) even if it is not yet in master.
It builds, but I still need to properly test it; expect it to be merged sometime near this weekend.
You are probably right about recv; i'll change it to "receive" as soon as i get home (patch welcome though).
There can only be one instance, you're right.
String identifiers are human friendly; moreover i can't see how an enum could fit there, care to explain? Thanks!
Btw you can have same module name in different contexts.
I guess it would change the API. You could have a separate file where you define an enum with all module identifiers plus a max value that all modules should include. Then you could omit whole hashmap dance and just use a static array. Then even an IDE or your text editor could give completions easily.
That would be less dynamic, but it's all a game of tradeoffs.
It could be beneficial to also support poll, as it's more portable and should be faster for low fd number. Probably not worth the hassle for a side project though.
BTW: nice clean and simple library. I'm more inclined towards libdill and coroutines, but they are certainly more complicated under the hood.
Oh i see, that is what i firstly thought reading your comment.
Yes, that surely would work out pretty well and would be slightly lighter too. But it would lack flexibility and simplicity that are my key points for libmodule.
Thanks for your suggestion and feedback though, they are really appreciated. And thanks for the hint on recv(), how could i miss that!
I am glad to present you all my latest project: clight.
Clight will set your screen backlight level by capturing frames from webcam and computing ambient brightness; it can manage your screen gamma temperature too.
It uses geoclue2 to retrieve user location, and will compute sunrise/sunset times to set gamma.
It depends on a Bus interface i developed together with it, Clightd.
Clightd is responsible of setting/getting screen brightness, capture frames from webcam and returning their average brightness, and setting/getting gamma.
As it uses libudev to get/set backlight/get video device, it is much less prone to mistakes than "fopen/fscanf/fprintf", and safer.
Both softwares are distributed with a GPL license.
For more informations, please refer to both projects READMEs.
I hope someone will find them interesting and useful!
One thing - does clight support ICC color profiles? My screen is harshly blue without the correct profile applied. Redshift normally simply overrides your profile; it recently added support for a "preserve" option, which applies the desired color temperature as a function of the current profile, but unfortunately this makes the transform relative, and also not symmetrical. Turning the temp down by 1000K and then up by 1000K causes a loss in brightness.
It does not, i'm sorry.
Let me know if it feels better with clight compared to redshift though; may be different algorithms lead to different (hopefully better) results!
