correct dark detection for gtk3 about darkdetect HOT 19 OPEN

in can be also ported to gtk4, but i dont have time

from darkdetect.

if gi can't be imported (or can't require version 3) - fallback to the current detection method

from darkdetect.

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.

from darkdetect.

The idea behind darkdetect is to depend only on packages in the standard library.

#26 (comment)

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

from darkdetect.

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?

from darkdetect.

gi is PyGObject

from darkdetect.

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?

from darkdetect.

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

from darkdetect.

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

from darkdetect.

using gi - and catching ImportError would be the cleanest possible solution

from darkdetect.

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.

from darkdetect.

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

from darkdetect.

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.

from darkdetect.

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

from darkdetect.

i mentioned catching ImportError - because it will help to preserve the current behavior if the optional dependency is not installed

from darkdetect.

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

from darkdetect.

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?

from darkdetect.

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.

from darkdetect.

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

from darkdetect.