base16-manager/base16-manager

A command line tool to install base16 templates and set themes globally.

base16-manager's Issues

line 79: is_mac: command not found

Just FYI, there is no "is_mac" function included in this script.

File path changed for nicodebo/base16-fzf

Currently set_fzf() is using ${CONFIG_PATH}/${package}/build_scheme/base16-${theme}.config.

The nicodebo/base16-fzf package now has its config files inside ./bash and ./fish.

Feature request: Template aliases

I'd like to be able to install chriskempson/base16-shell with a much shorter command:

$ base16-manager install shell

We could keep track of a file which keeps the supported templates, with a key-value pair type of structure to have aliases setup for the "full names", so something like this:

SUPPORTED[shell]="chriskempson/base16-shell"
SUPPORTED[vim]="chriskempson/base16-vim"

Then we can check against the array whether or not the key or value exists. From there it's just installing the template as usual.

support i3

Hi, would it be possible to support i3 themes?
I will gladly help and submit a pull request if you tell me how to get started.

For me, setting the i3 theme is pretty essential

Store selected theme in config

Currently, selected theme is not stored anywhere in base16-manager which was OK so far.

Here are some use cases where it can be needed in future:

• changing directory locations like #46
• we need to re-set theme on template update (format change etc)
• user want to see current selected theme
• we may decide in future to set themes per template #49

Another approach might be not to store selected theme but implement logic in template support code to detect current theme. Upside would be awarenes of manual changes. Downside may be that user may depend on us to set theme he choose so we should be source of truth for themes :)

If #49 is against project directions, we can store selected theme in single file in config home. If #49 can happen sometime, it would be better to decide how to store default selected, overwrites etc (text file, multiple files, yaml config...)

Roadmap: Version 2.0.0

I would like to discuss, what changes should be implemented in version 2.0.0, what is necessary and what we would like to work on.

I suggest the following changes for vesion 2.0.0:

• Change to XDG defaults (#46)
• Allow a config file
  • Store current theme (#50)
  • Allow different themes per application (#49)
• Add aliases for template names (#36)
• Add backups for configs (#41)

Furthermore I'm thinking of writing a function similiar to set_generic which allows to search and replace blocks, but I don't have a good idea to cope with that yet.

What do you think?

generic set function

Hello!

As base16-manager provides a quite good infrastructure to set themes, I think it would be a good idea to support more (or all) templates of base16.

Therefore I would like to work on a generic set function. The main goal is to simplify the support of new templates and minimize the code, so that we don't have to write a new set() function for each template.

A first idea is the following pseudo-code:

set_generic() {
  local package=$1
  local theme=$2
  local cmnt_string=$3
  local assign_string=$4
  local config=$5
  local file="${CONFIG_PATH}/${package}/themes/base16-${theme}"

  for line in $file
    delete_lines_containing_left_side_of_assignment($config)
  end
  delte_obsolete_comments($config)

  cat $file >> $config # append new colors.
}

What do you think?

feature request: i3 template

Hello,
It would be very nice having khamer/base16-i3 support since it's the most popular WM nowadays and would make a great combo with the already supported templates.

LICENSE is always installed globally regardless of the value of PREFIX

To fix this, in the Makefile LICENSEDIR=/usr/share/licenses should be LICENSEDIR=${PREFIX}/share/licenses.

Support new Rofi theme format (rasi)

Hello,

rofi has a new theme format (rasi) which has a lot more options and will soon replace the old format and Xresources. I think it wouldn't be hard to support, since colors can be defined in a separate file and then referenced in the theme file.

Other files are imported in the rasi theme with:

@import "mytheme.rasi"
@import "mycolors1.rasi"

(see here for reference: davatorium/rofi#756)

The rasi format is explained here: https://github.com/DaveDavenport/rofi/blob/next/doc/rofi-theme.5.markdown

Is there a way to use this with base16-manager yet? If not will it be supported?

Looking for new maintainer(s)

I rarely use base16-manager myself anymore and frankly I don't want to put up with maintaining something I no longer really use. This is why I'd like to find someone else to take over the project. Otherwise I'll simply archive this repository and tag it as no longer maintained.

Support different theme per template

I would like to use one theme for most of apps but different one for one/couple of them.

One use case is i.e. having base16-solarized-dark for every theme but base16-solarized-light for rofi and fzf because of better contrast.

If this is not against project directions, it would be great to keep it in mind when doing changes so we don't close the door for this.

It totally need more discussion as there are multiple UX problems with this. We have to at least:

• be able to set default theme
• overwrite one specific theme
• change only default theme or only specific theme
• turn off overwrites and set everything to default

set_dunst: Creates duplicate frame_color and separator_color value pairs and breaks the theme

The base16 template defines the to global value pairs at the top of the file. However, the sed edit which modifies the configuration file doesn't account for this, and only removes the [base16_*] sections, leaving the two globals. After it then inserts the template, a new set of globals are included.

Here's my very lightly modified dunstrc for reference.

Initially:

$ grep -nE '^\s*(frame|separator)_color' dunstrc
67:    frame_color = "#dcdccc"
75:    separator_color = frame
264:    frame_color = "#ff0000"

Lines #67 and #75 are from the [global] sections. Line #264 is from my [urgency_critical] section.

$ ./base16-manager set gruvbox-dark-pale
Set theme to gruvbox-dark-pale. You may need to restart DE and terminals.
$ grep -nE '^\s*(frame|separator)_color' dunstrc
67:    frame_color = "#dcdccc"
75:    separator_color = frame
264:    frame_color = "#ff0000"
327:frame_color = "#dab997"
328:separator_color = "#dab997"

Lines #327 and #328 are the globals defined in the theme, which have now been appended.

$ ./base16-manager set gruvbox-dark-pale
Set theme to gruvbox-dark-pale. You may need to restart DE and terminals.
$ grep -nE '^\s*(frame|separator)_color' dunstrc
67:    frame_color = "#dcdccc"
75:    separator_color = frame
264:    frame_color = "#ff0000"
327:frame_color = "#dab997"
328:separator_color = "#dab997"
330:frame_color = "#dab997"
331:separator_color = "#dab997"

Lines #330 and #331 are the new globals which have been appended. The old globals at #327 and #328 are still present.

While I don't think the repeated values make any difference (as I'm guessing they're just overriden), it's still a bug.

While the above is rather minor, however, the result of simply appending the two globals could be another matter as they very likely will now be defined in a section other than [global] (in my case that would be [urgency_critical]).

$ tac dunstrc | sed -e '1,/^\[urgency_critical\]/ !d' -e '/^[[:space:]]*#/d' | tac
[urgency_critical]
background = "#3f3f3f"
foreground = "#dcdccc"
frame_color = "#ff0000"
timeout = 0






frame_color = "#dab997"
separator_color = "#dab997"

frame_color = "#dab997"
separator_color = "#dab997"

[base16_low]
msg_urgency = low
background = "#3a3a3a"
foreground = "#8a8a8a"

[base16_normal]
msg_urgency = normal
background = "#4e4e4e"
foreground = "#dab997"

[base16_critical]
msg_urgency = critical
background = "#d75f5f"
foreground = "#d5c4a1"

The above would mean that frame_color and separator_color are now defined under [urgency_critical], which breaks the theme.

Error when trying set theme using a custom theme repo

With base16-manager, I’ve pulled in my own repo base16-manager install jonleopard/base16-shell, and then tried to set a theme, but the following error gets returned:

$ base16-manager set nord

ERROR: Package jonleopard/base16-shell is not (yet) supported.
ERROR: Package jonleopard/base16-vim is not (yet) supported.

It seems that the script is only looking for chriskempson/base16-vim, or chriskempson/base16-shell. Could there be a more dynamic way of handling this?
https://github.com/base16-manager/base16-manager/blob/master/base16-manager#L267

Feature request: Install new theme

Hi! Thank you for this tool. I found it very helpful.

I'd like it if base16-manager could use a template's YAML and mustache files to generate any missing themes. This would make new theme installation very easy.

Prefer includes over modifications

I'm of the general opinion, that having separate configuration files for theming - which are then included in the main configuration file - whenever possible, keeps things a lot cleaner.

This approach to configuration isn't always available, such as with termite, but I believe following this convention would help prevent issues such as #55 in other packages.

A number of the packages already follow this convention:

1. base16-fzf
   • set_fzf creates ~/.fzf_colors and modifies shell configs to source it
2. base16-shell
   • set_shell calls profile_helper.sh which symlinks the appropriate script to ~/.base16_theme, which you must source manually
3. base16-vim
   • set_vim creates $vim_dir/colorscheme.vim which you must source manually
4. base16-xresources
   • set_xresources copies the theme to $HOME/.Xresources.d/colors and modifies $HOME/.Xresources to include it
5. base16-sway
   • set_by_copy copies the theme configuration, which you must source manually

Currently the following packages have their modifications directly modified when including is available:

1. base16-qutebrowser
   • set_generic modifies $QUTEBROWSERCONF
   • supports importing through config.source(file)

• base16-zathura
  • set_generic modifies $HOME/.config/zathura/zathurarc
  • supports including other files

Suggestion

Always copy a package's set theme to a fixed location, which must be included/imported/sourced by the package main configuration. Basically prefer set_by_copy over set_generic much like with base16-sway.

This does mean, that the user has to then manually edit the package's main configuration file once, in order to source the fixed location of the packages theme file. This could be automated much like how set_xresources does it.

Are there any strong opinions about this?

Side note

Having the behaviour of set_fzf and set_xresources - which both create a separate theme file and modify the main configuration file to include it - differ from the rest is a bit confusing. It would be nice if this was more consistent.

ShellCheck - correctness ?

Hello,

I would suggest to check the syntax of base16-manager with ShellCheck and try to fix all warnings and errors.

About ShellCheck (see github page):

The goals of ShellCheck are

• To point out and clarify typical beginner's syntax issues that cause a shell to give cryptic error messages.

• To point out and clarify typical intermediate level semantic problems that cause a shell to behave strangely and counter-intuitively.

• To point out subtle caveats, corner cases and pitfalls that may cause an advanced user's otherwise working script to fail under future circumstances.

What do you think about?

vim integration

Hey, can you verify that the vim integration is working?

Looking at the code i see that the manager sets the appropriate colorscheme but i do not understand how vim can find the themes as they are not stored in the .vim/colors directory?

Add test suite

In order to simplify our checks for new functions, I think we should create a test suite.

I've found Bats: Bash Automated Testing System. I didn't use it yet, but it seems quite easy.

If you are ok with this tool, we can start creating tests 😃 .

List installed themes

base16-manager list lists installed templates.

Is listing installed themes on the roadmap?

I am not familiar enough with the base16 tool chain to understand where we should source the list of themes from.

But if someone could allude to an implementation I can take a stab at a first PR.

Feature request: Add function backup

Idea:
When setting a theme, the user's old configuration should be backuped somewhere. As this attracts each template, a function backup is needed.

PRE:

• name of application
• path to the user's configuration

POST:

• For each run of base16-manager, the directory $XDG_DATA_HOME/base16-manager/backup/$date-$time/ is created.
• The old configuration's are stored $XDG_DATA_HOME/base16-manager/backup/$date-$time/$name_of_application.$ending

If you need more support, just ask! We will be glad to help!

Add other programs

Hey, are you interested to extend your tool with other programs?
I would be interested in fish (there already exists a solution you could add, in the base16-shell repository) and dunst.

Thank you for writing this script, i was pretty suprised that there isn't one already and i'm happy that i found this. :)

Feature request: Add function get_tmp

Idea:
When setting a theme (and for testing reasons), it's easier to work on a temporary copy of the user's
configuration. As this attracts each template, a function get_tmp is needed.

PRE:

• path to the user's configuration
• $package, e.g. base16-shell

POST

• copy the old configuration to $XDG_DATA_HOME/base16-manager/tmp/$package.$ending
• return the path to this temporary copy.
• before exit base16-manager, remove $XDG_DATA_HOME/base16-manager/tmp

If you need more support, just ask! We will be glad to help!

list() ist not backwards compatible

In commit e73ae11 the function list() changed to read from the file $CONFIG_PATH/installed:
https://github.com/AuditeMarlow/base16-manager/blob/caa01cb917595c6f62a4adcba66f0aeaca1f4375/base16-manager#L85

If templates were installed before this commit, they aren't included in this file or the file doesn't even exist.

A possible workaround could be

if ! file_exits "$CONFIG_PATH/installed"; then
	ls "$CONFIG_PATH" > "$CONFIG_PATH/installed"
fi

but then I don't see the difference to directly return the output of

ls "$CONFIG_PATH" > "$CONFIG_PATH/installed"

So, what's the gain of storing installed templates in a seperate file?
How can we make this function backwards compatible again?

set_generic with qutebrowser: "xargs: unmatched single quote"

This is a seemingly minor bug in set_generic, which simply causes xargs to display a warning.

The actual config.py is updated just fine.

My (very basic) config.py for reference.

$ ./base16-manager set gruvbox-dark-pale
xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option
xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option
Set theme to gruvbox-dark-pale. You may need to restart DE and terminals.

Since there's only once instance of xargs in the entire script, I'm guessing that's the source.

On a side-note, I'm really not a fan of using xargs for whitespace removal. Wouldn't a simple sed expression be much more obvious? The current implementation seems to me like an abuse of a side-effect of xargs, which isn't nearly as obvious as sed.

destructive editing of termite config

When applying a theme, some of my termite config lines are being removed that are unrelated to the colorscheme.

$ diff config config.bac | head -n24
7c7,9
< 
---
> #fullscreen = true
> #icon_name = terminal
> cursor_blink = off
35,36c37,38
< # Base16 Outrun Dark
< # Author: Hugo Delahousse (http://github.com/hugodelahousse/)
---
> # Base16 Snazzy
> # Author: Chawye Hsu (https://github.com/h404bi) based on Hyper Snazzy Theme (https://github.com/sindresorhus/hyper-snazzy)
38,42c40,44
< foreground          = #D0D0FA
< foreground_bold     = #E0E0FF
< cursor              = #E0E0FF
< cursor_foreground   = #00002A
< background          = rgba(0, 0, 42)
---
> foreground          = #eff0eb
> foreground_bold     = #f1f1f0
> cursor              = #f1f1f0
> cursor_foreground   = #1e1f29
> background          = rgba(30, 31, 41, 0.9)

The 3 lines being removed are at the top of that diff. So it looks like cursor_blink is being mistaken for either cursor or cursor_foreground and removed along with the previous 2 commented lines.

base16-shell does not correctly set .vimrc_background

running base16-manager set onedark with base16-shell template does not correctly set the .vimrc_background

here

As base16-shell 's _base16 function requires 2 arguments here

_base16 "$file"

needs to be

_base16 "$file" "$theme"

or we could just run base16_${$theme} function as aliases are created by profile_helper script of base16-shell.

Suggestion: Support for termite

Hello,

I enjoy your base16-manager very much! It's super easy to test other colorschemes with it!
Thank you very much!

For my personal needs, I had to extend the manger for termite.
Here is, what I'm doing:

Add function to set_theme():

# ... 
 "khamer/base16-termite")

	set_termite "${package}" "${theme}"
	;;
# ...

And the new function itself:

set_termite() {
  local package=$1
  local theme=$2
  local file="${CONFIG_PATH}/${package}/themes/base16-${theme}.config"
  local termite_dir="${HOME}/.config/termite"
  local config="${termite_dir}/config"

  if ! file_exists ${file}; then
    err "Termite theme not found."
  else
    check_dir $termite_dir
    [[ -f "${config}.bac" ]] && rm "${config}.bac"
    [[ -f "${config}" ]] && cp ${config} "${config}.bac" || touch ${config}
    sed '/^\[colors\]$/,/^\[\w*\]$/{/^\[\w*\]$/!d}' ${config} | grep --invert-match '\[colors\]' > /tmp/termiterc
    cp /tmp/termiterc ${config}
    cat ${file} >> ${config}
  fi
}

The sed command may not be the most elegant, but I hadn't achieved the desired otherwise.

It would be cool, to see this code included in base16-manager :-)

unlinked config file on theme setting

Hello,
I've noticed some templates such as qutebrowser and dunst when updated by a 'base16-manager set' command will overwrite the config file killing any soft linking it might have, which is a common way to manage dotfiles.

Other templates such as termite and rofi will not damage the links on update, which is the desired behavior.

Overview: Supported templates

Overview

Currently supported:

• dunst
• fzf
• qutebrowser
• rofi
• shell
• sway
• termite
• xresources
• vim
• zathura

Supported through other methods:

• i3

Work in progress:

--

Unsupported/not discussed yet:

• alacritty
• bbedit
• blink
• c_header
• concfg
• conemu
• config.yaml
• crosh
• default.mustache
• emacs
• gnome-terminal
• gtk2
• highlight
• html-preview
• i3status-rust
• iterm2
• jetbrains
• joe
• kakoune
• kitty
• konsole
• mintty
• monodevelop
• prism
• prompt-toolkit
• putty
• pygments
• pywal
• qtcreator
• radare2
• scide
• st
• stumpwm
• styles
• textmate
• tilix
• vis
• vscode
• windows-command-prompt
• xcode
• xfce4-terminal
• xshell

Add support

If you plan to support a new template, please follow these steps:

• Read the contributing guidelines.
• Comment this issue, that you're working on template XY.
• If you run into troubles, we're glad to help you. Please open a new issue.
• Open a pull request :-)

base16-manager set --silent

I was curious what the recommended way is to run
base16-manager set [theme-name]

Currently I have it in my .zshrc file but it's echo-ing "Set theme to ..." on every shell generation. Is there a better way to set the theme on shell startup? Or should I make a PR for a --silent execution option?

Installation via package managers

As asked in #2 I'm not sure whether platform portability is of interest here but I assume it is since this is a very useful tool. As mentioned in #1 I used to maintain chrokh/shell-colors 😅 which essentially solves the same problem as this tool does but for macOS users. However I will gladly deprecate that repo in favor of this as this solution is more elegant.

Now to the question 😃 As a Mac user it is super convenient to install shell tools via Homebrew. This script I would argue is an excellent candidate. That would mean that we don't have to handle updates but can simply keep pushing and Homebrew can be used to pull the latest version.

I am not familiar with other package managers like apt-get but I assume that publishing a package there is equally trivial?

Is there a rationale behind not making this script installable via package managers or do you mind if I supply a PR that allows users to install this via Homebrew? Apologies if I'm overlooking something fundamental.