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!
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 ;)
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.
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.
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.
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!
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.
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!
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!