Clearify how templates work (and use a better default name)

[Kaligule]

After instalation of themer I have the following structure in my .config/themer/templates

templates
└── i3
    ├── Xdefaults.tpl
    ├── config.yaml
    ├── i3.tpl
    ├── index.tpl
    └── plugins
        └── __init__.py

It is unclear to me (and not explained in the readme or elsewhere) why there is an Xdefaults template in the i3 directory. Shouldn't there only be i3-related files in there? I had expected something like:

templates
├── config.yaml
├── index.tpl
├── i3
|   └── i3.tpl
├── i3bar
|   └── i3bar.tpl
└── Xdefaults
    └── Xdefaults.tpl

Or perhaps:

templates
└── setupname
    ├── config.yaml
    ├── index.tpl
    ├── i3
    |   └── i3.tpl
    ├── i3bar
    |   └── i3bar.tpl
    └── Xdefaults
        └── Xdefaults.tpl

So it would be great if the readme could explain how the template directory should work and what goes into the config.

[Kaligule]

After looking into the code, I think this is a missunderstanding with the following root cause: i3 is a bad name for a default template.

It suggests that the directory holds configs for i3wm (when it is meant to hold all configs that are relevant to a i3wm setup). I have seen multiple questions from people (me included) who were irritated that configfiles for Xdefaults in a directory called i3 or even wondered when Themer would support other window managers than i3.

I suggest to rename it to tiling_setup. tiling is much more general than i3, so users of other window managers would be more interested to look into it. The word setup implies that there are multiple components.

[s-ol]

@Kaligule you are correct with the second comment, this is a relic from when I ported the original code here and lazily never changed this.

I think it makes more sense to just completely remove that hierarchy-layer maybe, it is problematic anyway because if you only use one setup you have to either use the default name or specify it every time.

Another angle at this is that actually this is all user configuration and only supposed to be an example configuration. Maybe it should even be removed from the package and put into a wiki or seperate repo, what do you think?

[Kaligule]

It might be usefull to ship some example configuration, but maybe it should go to /etc/themer (similar to the default config of i3wm, which we all have copied from at least once).

I think removing the layer sounds like a good idea. I tried very hard but couldn't really think of a problem it solves that couldn't be solved easier otherwise.

[Kaligule]

@s-ol I have thought about it a little more and want to suggest the following setup (for a working setup, we could think about files shiped by default later).

themer
├── templates
|   ├── config.yaml
|   ├── other_config.yaml
|   ├── config_1.tpl
|   ├── config_2.tpl
|   ├── config_3.tpl
|   └── plugins
└── themes
    ├── current
    ├── theme_A
    ├── theme_B
    └── theme_C

1. In templates we have config-templates like we have now. But instead of the filesystem providing different directories for different setups (with much overload since many things would be in both directories) we could just have multiple .yaml files. config.yaml could be the default, but if another one is specified with -t other_config we could use that one.
   We already have the files: part in every config.yaml at the moment, so if someone wants a version of config_1.tpl that is completly different from his normal setup he could just create config_1_alternative.tpl and change which one is used in his config.yaml.
   The nice thing is that most people would never have to notice that you can have multiple config.yaml files until they need the feature.

2. I would also like to have a seprate themes directory, just to have the themes separated from the templates. This doesn't have an immediate usecase, it just looks cleaner to me.

3. There is another thing. It might be a good idea to separate the source files of a theme from the files that are just generated for a theme. So a theme like theme_A would hold 2 directories (the names I use here are really bad, we would find better ones):

   • for_theme_configuration (would contain colors.yaml, wallpaper.png, there might be more in the future): Everything the user can configure for a certain theme.
   • for_linking (would contain i3.conf, Xdefaults, index.html, a softlink to wallpaper.png): Everything that should be linked from outside. These files can be removed without worries since they can be rerendered at every point from the files in for_theme_configuration.

   This would also make testing much easier.

I see that the changes would be massive, though. Any thoughts on that?

[s-ol]

1. great suggestion and makes immediate sense. a config could also have a key to include another config (also recursively).
2. I had thought about this and I don't see why not. I think current should stay outside though, this way there are also no longer any restricted theme names (well, except .. maybe).
3. this one I am not so sure about. The concept I agree on, but the implementation with folders (of any names) seems to be ovecomplicating it.

A more radical approach, but maybe the right one, would be to completely remove all the for_linking files and only store colors.yaml and wallpaper.png. current then is no longer a symlink but the only set of rendered templates. This also means you can no longer keep around themes rendered from outdated templates and not notice when switching to them, as any themer activate will automatically rerender.

These are quite some changes, but not 'too huge to do'. I was planning on eventually radically rewriting themer but never got around to, and this seems like a middle ground and a good way of changing it from within.
Of course because of the backwards-incompatibility all of these changes would constitute a themer 2.0 release.

[Kaligule]

Good ideas. Wow.

• Having current in themer (like you suggest) would improove backwards compatibility, nobody would have to relink their files.
• I like the idea of having the real files in current. This removes much cluster from the theme directories and makes my point 3 obsolete.
• recursive configs might be a great idea. This would save users from copying their configs and only change few lines and have a great zoo of configs after a short time.
• If I see it correctly, all the files that are in use now would be still valid, they would just have to be moved to their new positions (and many of them would be obsolete). So we might have a script which could help users switch from themer1 to themer2 by copying files around (after having a backup of course).

If you start working on this I will try to help when I find the time for it.
This is what it might look like in the end (note that the themes only hold 1 or 2 files (the wallpaper can be generated))

themer
├── templates
|   ├── config.yaml
|   ├── other_config.yaml
|   ├── config_1.tpl
|   ├── config_2.tpl
|   ├── config_3.tpl
|   └── plugins
└── themes
|   ├── theme_A
|   |   ├── variables.yaml
|   |   └── wallpaper.png
|   ├── theme_B
|   |   └── variables.yaml
|   └── theme_C
|       └── variables.yaml
└── current

[Kaligule]

Oh, and another point to having the real files in current would be that render and activate would be the same and could be merged into one command.

[s-ol]

@Kaligule yup, that's what I meant to say by

This also means you can no longer keep around themes rendered from outdated templates and not notice when switching to them, as any themer activate will automatically rerender.

[s-ol]

I'm going to close this and break it into smaller changes.