Blue-light-blocker@samuel12sam: Initial release

[samuel12sam]

Description of Blue Light Blocker

Give a warm tone to your screen in the same way 'Night Light' and 'Night Shift' do it on Windows and macOS. Simple sliders allow you to control the yellow-tint of your screen and it's brightness.

Batteries included

ships with the xsct executable and source code (https://github.com/faf0/sct) so that users don't have to go out of their way to download and install it globally themselves from the Software manager or via terminal (xsct is public domain)

Screenshots

[rcalixte]

ships with the xsct executable

Unfortunately, this makes it a non-starter. Take a look at the auto-dark-light@gihaume for how to have the binary compile with the shipped source. You can make the compilation dependent on the binary being found or not. Feel free to update this once completed and we can get it pushed through.

[samuel12sam]

Thanks for the quick response! I took a look at auto-dark-light@gihaume, but when it comes to the compilation, since the source code I use in my applet uses libraries such as :

#include <X11/Xatom.h>
#include <X11/Xlib.h>
#include <X11/Xproto.h>
#include <X11/extensions/Xrandr.h>

the user has to already have downloaded the libx11-dev and libxrandr-dev packages for the compilation to succeed on his computer. If he does not have these packages, he has to manually download them or else the compilation process with the make command will fail and throw this error:

It seems like the best solution would indeed be to just ship the applet with the executable directly so that the users don't have to go out of their way to download anything themselves, but if it is against certain rules, I get it. I'm just wondering what would be the best course of action in this case to have Blue Light Blocker be an applet with 'Batteries-included'...?

Thanks in advance

[rcalixte]

I'm just wondering what would be the best course of action in this case to have Blue Light Blocker be an applet with 'Batteries-included'...?

You could check for the header files too or provide documentation (accounting for at least the major distro package managers). The Redshift applet encountered a similar issue. You could also consider re-implementing your code as well, using an interpreted language instead of a compiled one.

[guillaume-mueller]

I think Radio3.0@claudiux asks for missing packages to install automatically, which opens the password manager at some point.

[rcalixte]

I think Radio3.0@claudiux asks for missing packages to install automatically, which opens the password manager at some point.

You can try that. Hopefully it's not too complicated to maintain long-term. I would encourage a solution that is more maintainable even if it's not your idea of perfect but ultimately, it's your call.

[samuel12sam]

Recently got the time to redo my code to ship the applet without the pre-compiled executable.

I am now instead prompting the user to install 'xsct' by using 'apturl apt://xsct'

Hope everything is ok now, thanks for taking the time

[rcalixte]

I am now instead prompting the user to install 'xsct' by using 'apturl apt://xsct'

Not to discourage your effort but this will only work for Debian-based distributions. There are many Cinnamon users on Arch-based and Fedora-based distributions as well.

[samuel12sam]

I am now instead prompting the user to install 'xsct' by using 'apturl apt://xsct'

Not to discourage your effort but this will only work for Debian-based distributions. There are many Cinnamon users on Arch-based and Fedora-based distributions as well.

Uh-oh, I didn't know I had to make it compatible with non-debian based distros...well alright, i guess we can close this pull request ahah I don't think I'll be spending any more time on this for now... Sorry for bothering and thank your for all of the comments 👍