Open actionless opened 1 year ago
in can be also ported to gtk4, but i dont have time
if gi
can't be imported (or can't require version 3) - fallback to the current detection method
Hi, thanks for this contribution. The idea behind darkdetect
is to depend only on packages in the standard library. Up to now this was possible, and so I would like to keep it that way. May I ask you what does not work with the current detection method in your experience? Perhaps we could try to improve that, instead of adding a dependency from gi
.
The idea behind darkdetect is to depend only on packages in the standard library.
https://github.com/albertosottile/darkdetect/issues/26#issuecomment-1189038270
May I ask you what does not work with the current detection method in your experience?
the current detection simply relies on theme having "Dark" string in its name - that not works for any themes which are not manifesting the level of their darkness via their name
if gi can't be imported (or can't require version 3) - fallback to the current detection method
I do not think this is how a Python package should work. When you install darkdetect
, you expect it to be fully functional, and not having a missing dependency. How is the regular used supposed to know that an extra feature is available if gi
is installed in their system? We could make an extra for this dependency, but I fear this will complicate the project structure and distribution too much.
the current detection simply relies on theme having "Dark" string in its name - that not works for any themes which are not manifesting the level of their darkness via their name
This is actually a noble goal, so I understand why you submitted this code. Do you think it would be possible to achieve the same results by e.g. looking at how PyGObject is implemented?
gi
is PyGObject
I am aware... Let me rephrase: do you think it would be possible to achieve the same results by looking at how gi
is implemented?
you can try copy-pasting code from there and related schemas - but that's not the way how libraries in python ecosystem meant to be used
you expect it to be fully functional, and not having a missing dependency
the current implementation have the same issue btw - if gsettings
executable dependency won't be installed - it also won't be functional
using gi - and catching ImportError would be the cleanest possible solution
you can try copy-pasting code from there and related schemas - but that's not the way how libraries in python ecosystem meant to be used
Completely agree, the correct way would be to add PyGObject
in the requirements of this project, which is precisely the thing that I do not want to do, for the reasons stated in the README.
the current implementation have the same issue btw - if gsettings executable dependency won't be installed - it also won't be functional
Is this a common scenario? Are there GNOME-based distros that do not include a functional gsettings
by default?
using gi - and catching ImportError would be the cleanest possible solution
I would still question how a typical user (that just installs Darkdetect from PyPI) should know that they should also install PyGObject to get an extra or improved feature.
python package doesn't have any mechanisms to control dependency on gsettings or GNOME, but have mechanism to define an optional dependency on gi
and the main point, detecting dark color should happen by color, not by name
so our discussion is a bit like what you trying to proof what having 5-wheel car is more logical than 4
I am sorry, what would your suggestion be for defining an optional dependency on gi
? Catching ImportError
does not define any dependency, as the user does not even know that Darkdetect has this dependency in the first place.
As I said before, we could define an extra for this dependency, assuming that there are people interested in this feature. If this is your suggestion, I would consider a PR.
https://stackoverflow.com/questions/6237946/optional-dependencies-in-distutils-pip
sure i'll create a PR as soon as we'll get any sort of agreement on the topic - to avoid doing the job which would be discarded
i mentioned catching ImportError - because it will help to preserve the current behavior if the optional dependency is not installed
https://stackoverflow.com/questions/6237946/optional-dependencies-in-distutils-pip
Yes, I am well aware, I have been mentioning extras in this issue a few times…
sure i'll create a PR as soon as we'll get any sort of agreement on the topic - to avoid doing the job which would be discarded
I still think this complicates the package significantly, but I would welcome a well-structured PR with the dependency managed as an extra (write a different module for a gi
based detection, fall back to https://github.com/albertosottile/darkdetect/blob/master/darkdetect/_linux_detect.py if the extra was not installed, handle module selection in __init__.py
).
Is this why Breeze comes back as a Light theme (even though it's very much a dark one) and Adwaita-dark works as it's suppose to?
Is this why Breeze comes back as a Light theme (even though it's very much a dark one) and Adwaita-dark works as it's suppose to?
I would say so, the current code identifies a theme named 'Breeze'
as light.
In #30 we added an extra to the package: macos-listener
, for installing the dependencies necessary for the macOS listener. I am still willing to accept a PR based on @actionless suggestion, providing that the extra dependency on gi
is separated in another extra (e.g. gtk-detection
).