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

Trigger color mode change following darkmode or alike in macos #806

Closed
mad01 opened this issue May 18, 2021 · 7 comments
Closed

Trigger color mode change following darkmode or alike in macos #806

mad01 opened this issue May 18, 2021 · 7 comments
Labels
docs Primarily or only affects documentation

Comments

@mad01
Copy link

mad01 commented May 18, 2021

Is your feature request related to a problem? Please describe.
In Today's operating systems like macos there is features that allows you to set darkmode at the evening and lightmode at the day, for me that means having a light and a dark theme. from what i have found i don't see a way to do this.

Describe the solution you'd like
Since the way different operating systems works i think one of the options i like is to allow for a background task or ticker. like you can have in vim with a ticker triggering every N sec. this you could then trigger colour theme change for example.

i have a smaller shell script for kitty to handle this looking like this but i use the same logic to conditional change for vim since it's the same macos defaults key

function darkModeSetKitty() {
    if $(defaults read -g AppleInterfaceStyle &>/dev/null) ; then
        # if ok it set dark since AppleInterfaceStyle is unset during the day
        kitty @ set-colors -a "~/.config/kitty/onehalf-dark.conf"
    else
        # set to light as default 
        kitty @ set-colors -a "~/.config/kitty/onehalf-light.conf"
    fi
}

function darkModeVim() {
    if $(defaults read -g AppleInterfaceStyle &>/dev/null) ; then
        # if ok it return string 
        echo "Dark"
    else
        # on err it will fail and we should return light
        echo "Light"
    fi
}

the optimal option would be to have OS specific implementations but that does not have to be the initial option to allow users to solve it

@mad01 mad01 added the enhancement New feature or request label May 18, 2021
@wez
Copy link
Owner

wez commented May 18, 2021

There are some details on how to do this in this thread:
https://twitter.com/fanzeyi/status/1372054462534062084
we should get this added to the docs as a config recipe/example

@wez wez added docs Primarily or only affects documentation and removed enhancement New feature or request labels May 18, 2021
wez added a commit that referenced this issue Jul 18, 2021
This is a baby step: it introduces the Appearance concept
and provides an accessor at the Connection level.

Only macos implements this at this time, and nothing else
makes use of it.

refs: #894
refs: #806
wez added a commit that referenced this issue Jul 18, 2021
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.

It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.

refs: #894
refs: #806
@rashil2000
Copy link
Contributor

Hey!

So I was trying something similar for Windows theme detection, the relevant code is relatively simple:

function compute_scheme()
  local success, stdout, stderr = wezterm.run_child_process({"reg", "query", "HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize", "/v", "AppsUseLightTheme"})
  local is_light = tonumber(wezterm.truncate_left(wezterm.split_by_newlines(stdout)[3],1))
  if is_light == 0 then
    return "BlulocoDark";
  end
  return "BlulocoLight";
end

This correctly returns the value, but for some reason the theme doesn't actually change unless wezterm is restarted. Here is my config:

local wezterm = require 'wezterm';

function compute_scheme()
  local success, stdout, stderr = wezterm.run_child_process({"reg", "query", "HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize", "/v", "AppsUseLightTheme"})
  local is_light = tonumber(wezterm.truncate_left(wezterm.split_by_newlines(stdout)[3],1))
  if is_light == 0 then
    return "BlulocoDark";
  end
  return "BlulocoLight";
end

wezterm.on("update-right-status", function(window, pane)
  local overrides = window:get_config_overrides() or {}
  local color_scheme = compute_scheme()
  if overrides.color_scheme ~= color_scheme then
    overrides.color_scheme = color_scheme
    window:set_config_overrides(overrides)
  end
end)

return {
  launch_menu = {
    { label = "PowerShell", args = {"pwsh"} },
    { label = "Cmd", args = {"cmd"} },
    { label = "Bash", args = {"bash"} },
    { label = "Neovim", args = {"nvim"} },
  },

  window_padding = {
    left = 25,
    right = 25,
    top = 25,
    bottom = 25,
  },
  initial_cols = 90,
  initial_rows = 30,
  hide_tab_bar_if_only_one_tab = true,
  add_wsl_distributions_to_launch_menu = false,
  font = wezterm.font("RecMonoSemicasual NF", {weight="Medium"}),
  color_scheme = compute_scheme(),
  default_prog = {"pwsh"},
  font_size = 11.0,

  colors = {
    tab_bar = {
      background = "#F9F9F9",
      active_tab = {
        bg_color = "#F9F9F9",
        fg_color = "#000000",
        intensity = "Bold",
        underline = "Single",
      },
      inactive_tab = {
        bg_color = "#F0F0F0",
        fg_color = "#808080",
      },
      inactive_tab_hover = {
        bg_color = "#E4E4E4",
        fg_color = "#808080",
        italic = true,
      }
    }
  }
}

What am I doing wrong here?

@wez
Copy link
Owner

wez commented Jul 18, 2021

This config switches the color scheme based on the appearance:

local wezterm = require 'wezterm'

function scheme_for_appearance(appearance)
  if appearance:find("Dark") then
    return "Builtin Solarized Dark"
  else
    return "Builtin Solarized Light"
  end
end

wezterm.on("window-config-reloaded", function(window, pane)
  local overrides = window:get_config_overrides() or {}
  local appearance = window:get_appearance()
  local scheme = scheme_for_appearance(appearance)
  if overrides.color_scheme ~= scheme then
    overrides.color_scheme = scheme
    window:set_config_overrides(overrides)
  end
end)

return {
}

The get_appearance method is currently only hooked up on macos and X11.
If you want to make it work on windows, then we need to add something like:

   fn get_appearance(&self) -> Appearance {
         if let Ok(1) = read_theme() {
            Appearance::Light
         } else {
            Appearance::Dark
         }
   }

in here: https://github.com/wez/wezterm/blob/main/window/src/os/windows/connection.rs#L25

I'll look at this a bit later today, but if you wanted to submit a PR for this before I get to it, go for it!

@rashil2000
Copy link
Contributor

rashil2000 commented Jul 18, 2021

Sorry, I won't be able to as I'm caught up with some work today.

But I have a question: is the window:set_config_overrides(overrides) function also hooked up only on macOS and X11 currently?
Because there might be conditions other than current appearance (which you demonstrated through get_appearance) where someone would want to change the colorscheme (for example based on some registry key like in my config - basically I was trying to follow what you replied in the tweet above, but adapted to Windows).

@wez
Copy link
Owner

wez commented Jul 18, 2021

The only thing that wasn't hooked up on windows was the window:get_appearance() method, but I just pushed a commit that does that.

window:set_config_overrides is implemented and behaves the same way on all systems.

You can use other criteria than the system appearance to influence the config overrides. There are some examples in the docs, and there's an example of using the update right status hook as a timer to do something that might depend on the current time.

@wez
Copy link
Owner

wez commented Jul 18, 2021

Docs are up at https://wezfurlong.org/wezterm/config/lua/window/get_appearance.html
Enjoy!

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
docs Primarily or only affects documentation
Projects
None yet
Development

No branches or pull requests

3 participants