PR #4 motivated me to write something about an issue that surfaced in PR #2. The ls_colors theme originally used a ranger plugin for part of its implementation, this is what the team suggested to the author. Later we decided to create this repo for colorscheme contributions. Mainly to make it easier for us to collect colorschemes created by the community. All colorschemes before this one were limited to a single colorscheme file. This suggests the simple structure of this repo as a directory that contains <colorscheme>.pys might be too restrictive.
What I've been thinking about as a solution
Have simple themes at the top level of the repo like now. Have more complex themes in their own directory with subdirectories for plugins, etc. This'd require a change to ranger to properly handle these new kinds of themes. It's not pretty, that's why I still want discussion.
Another option is deciding anything that's not a colorscheme still has to be PRed to the ranger repo but imo having to have the right version of ranger for your colorschemes and managing linked PRs across repos is terrible. (This is basically the situation rn. The ls_colors theme kinda hacked around this at my request.)
Next steps
Let's discuss this for a while. There's not much hurry imo because it's not like there's tons of themes being added.
I think the first thing we need to agree on are some goals, my suggestion in order of priority:
This repo should ease the contribution of colorschemes by the community. The ranger repo used to be the place for this but we received very few PRs for themes and accepting meant the burden of maintenance was entirely up to the ranger team.
This repo should make it easier to get these custom themes. Currently themes are spread across blogs and sites like dotshare.it. If we consolidate them here it's easier to get them. And we can provide clear instructions on how to use them. And it's a clearer place to report issues with (usage of) themes.
This repo should make it easier to judge themes, let's at the very least decide upon a small directory structure with various types of files to provide theme screenshots. Look at #3 for more ideas on this.
We should make it clear that the ranger team does not cary the primary responsibility in maintaining the themes. This doesn't mean if we change how theming works we'll just ignore the difficulties of porting existing themes we would of course provide help with porting them. I just want to avoid making it hard/impossible to change how themes work in ranger, yes losing theme options (temporarily) is annoying but having to carry around bugs or misfeatures because some themes a couple of people use rely on them is worse imo.
TLDR: 1. Contribution of themes should be easy. 2. Using contributed themes should be easy. 3. Showcase the themes 4. Community.
The problem
PR #4 motivated me to write something about an issue that surfaced in PR #2. The ls_colors theme originally used a ranger plugin for part of its implementation, this is what the team suggested to the author. Later we decided to create this repo for colorscheme contributions. Mainly to make it easier for us to collect colorschemes created by the community. All colorschemes before this one were limited to a single colorscheme file. This suggests the simple structure of this repo as a directory that contains
<colorscheme>.pys might be too restrictive.What I've been thinking about as a solution
Have simple themes at the top level of the repo like now. Have more complex themes in their own directory with subdirectories for plugins, etc. This'd require a change to ranger to properly handle these new kinds of themes. It's not pretty, that's why I still want discussion.
Another option is deciding anything that's not a
colorschemestill has to be PRed to the ranger repo but imo having to have the right version of ranger for your colorschemes and managing linked PRs across repos is terrible. (This is basically the situation rn. The ls_colors theme kinda hacked around this at my request.)Next steps
Let's discuss this for a while. There's not much hurry imo because it's not like there's tons of themes being added.
I think the first thing we need to agree on are some goals, my suggestion in order of priority:
TLDR: 1. Contribution of themes should be easy. 2. Using contributed themes should be easy. 3. Showcase the themes 4. Community.