Listener class PR acceptable? about darkdetect HOT 3 CLOSED

In principle, I am not against this feature. My only concern is that it has to be clearly documented, so I would consider the PR only if its provides adequate documentation. At the moment, because the API was super simple, our only documentation was the README. With this feature, we might want to add something like readthedocs, I am not sure.

One thing that should be retained is that Listener should only work when the OS supports darkdetect. In other words, the gates provided by __init__ should work also with these classes (e.g. returning BaseListener or something equivalent added in _dummy).

Regarding the code example, I think in _linux_detect.Listener, the class should inherit from BaseListener?

One small note about how we got here: originally, there were no listeners, then the Windows version was developed and I consider that as "the best" listener: based on ctypes, no continuous polling, no subprocess, perfectly interruptible. Then the Linux listener was proposed. I am not a Linux user so I could not advise on a better implementation for Linux, and so I had to "blindly" accept the listener implementation for Linux, but I was aware of its limitations. For macOS, I tried quite hard to achieve a similar implementation to the Windows one, but in the end I did not manage, and now we merged #30 and basically propagated the problems of Linux to macOS (with also the addition of the extra dependencies).

To recap, I did not extend/improve the listener API because I hoped implementing listeners similar to the Windows one would have been possible, some day. But now with #30 I basically accepted that is not possible, and so I believe an API extension along the lines you are proposing makes sense.

from darkdetect.

PR: #32

from darkdetect.

Since we are aligned on requirements, I would close this and keep the discussion in the PR.

from darkdetect.