New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
correct dark detection for gtk3 #26
Comments
in can be also ported to gtk4, but i dont have time |
if |
Hi, thanks for this contribution. The idea behind |
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 |
I do not think this is how a Python package should work. When you install
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? |
|
I am aware... Let me rephrase: do you think it would be possible to achieve the same results by looking at how |
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 |
the current implementation have the same issue btw - if |
using gi - and catching ImportError would be the cleanest possible solution |
Completely agree, the correct way would be to add
Is this a common scenario? Are there GNOME-based distros that do not include a functional
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 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 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 |
Yes, I am well aware, I have been mentioning extras in this issue a few times…
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 |
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 |
In #30 we added an extra to the package: |
The text was updated successfully, but these errors were encountered: