Automatic night mode and dark styles support

[nekohayo]

Since GTG 0.5 has a dark mode setting in the preferences, I guess I should point out that it ought to have an accompanying "Automatic" dark/night mode feature available, where the dark mode gets turned on automatically at sunset and off at sunrise. Because manually managing this is "not the user's job" (unless they want to have the same theme no matter what the hour), in my opinion.

The basic/primitive way to do this would be to use the app's internal clock (since it already knows the time, using that to update the dates at midnight etc.), but the "optimal" way would be, when available on the system, to use GNOME's night mode (connecting over DBus or something?) so that it happens with the rest of the desktop and benefits from its heuristics (as it takes into account timezone/DST/seasons/etc., I think) and/or plugging into the new Freedesktop dark mode standard (supported by GNOME 42+ and Elementary's Pantheon)

[diegogangl]

Wait, gnome has a night mode?

[nekohayo]

It doesn't control dark mode (I use my own silly script for that, which I've never taken the time to release publicly and announce, and it's a silly hack), but it does control what we used to call "red shift", so that's something I imagine you could plug into: in the Control Center, in the "Displays" panel, "Night Light" section.

[diegogangl]

Ah ok, there was some talk about auto-changing apps to dark mode but I didn't know if it was eventually added.

For anyone attempting this, look for toggle_darkmode() in application.py. You also need to refresh the treeviews for the background colors, so look at the darkmode toggle code in general_preferences.py

[azmeuk]

To add some context: there is (at least) one GNOME extension that switches GTK themes at sunset/sunrise. Most of the GTK apps works very well with that, and some apps have an "automatic theme detection" so non-GTK content matches the global theme (for instance, the dark reader firefox extension con only awake when the global gtk theme is dark).

The extension can also trigger user-written scripts at theme switch, this is how I automatically switch my vim and alacritty themes.

[nekohayo]

I guess the whole paradigm changes with GNOME 42 and GTK4, where there will be a global dark mode preference thingy that will eventually become automatable natively by the user in GNOME 43 (I presume), so this might get easier in the future, as we don't really have to bother with the whole timing thing; instead, I think we'll need GTG to "react" to the system and apply colors correctly, so that means dealing with:

• Dark mode on a large dataset is extremely slow #625
• Colored task backgrounds in the treeview are not updated when detagging, or when toggling off the feature #280
• [Urgency color] Prepare special color palette for dark mode #844
• Hardcoded grey / gray color of description preview text doesn't play well with selected rows or themes #576

[idoric]

I allow myself to add two references that could be useful to implement the support of the system-wide dark style preference in GTG:

• https://blogs.gnome.org/alexm/2021/10/04/dark-style-preference/
• https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/Dark-Style-Preference

[GeoffreyCoulaud]

Hey, any idea if this has anyone on it ?
This is pretty important since many users use dark mode and the color palette makes it unusablein GTG at the moment.

[idoric]

This is pretty important since many users use dark mode and the color palette makes it unusablein GTG at the moment.

I think we need to separate two problems:
— Problem 1: following the system-wide dark style preference (the issue we find ourselves on)
— Problem 2: having a good color palette for dark mode (issue 844)

GTG already offers a dark theme, fixing problem 1 is mainly a service to users whose system automatically switches between light theme and dark theme depending on whether it is day or night (for example thanks to the "Night Theme Switcher" GNOME extension). A user who does not use GTG urgency colors does not suffer too much from the color palette problem, and even so he may prefer not to have an application that remains bright in the middle of a dark environment at night.

As for problem 2, it concerns those who would like to use the dark theme, but cannot/do not want to in its current state, and fixing it would not help eliminate problem 1.

What I mean is that the two problems are quite distinct, and neither has priority over the other. At most we can notice that by solving problem 2, there will perhaps be even more users interested in solving problem 1.

[nekohayo]

Yes, we will get to all of this, once we complete the GTK4 port as part of #737.