Skip to content
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

Linux (GNOME) #7

Closed
cbrnr opened this issue Mar 18, 2021 · 7 comments · Fixed by #8
Closed

Linux (GNOME) #7

cbrnr opened this issue Mar 18, 2021 · 7 comments · Fixed by #8

Comments

@cbrnr
Copy link

cbrnr commented Mar 18, 2021

Nice project! Do you have any plans to support GNOME (or KDE) as well?

@larsoner
Copy link
Contributor

From what (little) I've found online there doesn't seem to be a consistent way to detect this on Linux, but it seems like calling:

gsettings get org.gnome.desktop.interface gtk-theme

and looking for -dark at the end would at least get it to work for some of the people some of the time (Debian flavors with dark-configured GTK -- works for me on Ubuntu 20.10 at least!).

Happy to open a PR to subprocess this call if this sort of incremental progress seems sufficiently useful...

@albertosottile
Copy link
Owner

albertosottile commented Mar 18, 2021

Seems to me the ecosystem is a little too vast to get this consistently right across all the Linux platforms. Also, I am not thrilled by a subprocess-based detection method, as that can fail in frozen applications.

Nevertheless, I am not against a PR on this topic, including one that uses subprocess, as users might still benefit from incremental implementations of this feature. So, please feel free to submit one and I will happily review it.

@larsoner
Copy link
Contributor

Seems to me the ecosystem is a little too vast to get this consistently right across all the Linux platforms. Also, I am not thrilled by a subprocess-based detection method, as that can fail in frozen applications.

Indeed I imagine it could fail in all sorts of ways. Hopefully a try/except might be good enough for a first version. I'll open a quick PR and we can see if it looks reasonable.

@cbrnr
Copy link
Author

cbrnr commented Mar 18, 2021

Could you use PyGObject instead?

@albertosottile
Copy link
Owner

albertosottile commented Mar 18, 2021

Could you use PyGObject instead?

I would rather not, as this would violate the "philosophy" of this package of avoiding extra dependencies

In addition, this package does not depend on other modules or packages that are not already included in standard Python distributions.

@cbrnr
Copy link
Author

cbrnr commented Mar 18, 2021

I would rather not, as this would violate the "philosophy" of this package of avoiding extra dependencies

You could nest the import though, so only people who really need it can install the package.

@albertosottile
Copy link
Owner

As I mentioned before, for the moment I would prefer to go with the way addressed in #8 as I think is leaner, though more brittle.

Medium term, it could be worthy to investigate how PyGObject is implemented and get the relevant parts needed for just this feature to include just them in Darkdetect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants