Misterio77 / flavours

🎨💧 An easy to use base16 scheme manager that integrates with any workflow.
MIT License
501 stars 29 forks source link

Not sure where to put custom template #27

Closed MoburgLeGrand closed 3 years ago

MoburgLeGrand commented 3 years ago

I'm just testing for now but I'm loving it up until now. Got a small problem though : I'm not sure where I should put my custom templates. I need one for .Xresources since using # Start flavours didn't work in it, but I originally created it in ~/.local/share/flavours/base16/templates/xresources/templates by copying the default one. It worked (i could select it using subtemplate = myfilename in my config.toml, but after a flavours update all, it disappeared. Did I misplace the file ? Or is it unwanted behavior that it god deleted with an update ? If I did misplace it, where would you recomand putting it ? I'd try some things myself, but I'd rather have confirmation before doing all my configurations if there's a risk the files might get deleted later. Thanks for all the work

Misterio77 commented 3 years ago

Hey, thanks for the feedback.

At the current time, it is indeed intended behaviour.

update can redownload:

With the option all doing all of the above.

I designed it thinking about a program that requires little to none prompting when updating schemes/templates, with the "correct" way of adding custom schemes/templates being, after writing locally, pushing them to a git repo for safety and adding that repo to the respective list.yaml file (optionally also contributing that addition to the official base16 lists). As schemes are each their own thing (so, the more the merrier), and templates for a specific app should be universal and work for any and all use cases, in a very generalized way (even if they don't, then the user should probably add a subtemplate that makes it work and contribute that to the existing template upstream).

I do see that now (actually have been brainstorming about this recently) this might be unwated behaviour, as upstream seems to be reaaaally slow maintaining lists (so most users end up either making non-tracked tweaks/additions to their lists), and sometimes have custom edits that simply don't make a lot of sense pushing to a git repo.

I'll futurely (probably) make a more featureful update command. Including diffing the lists/schemes/templates when pulling from upstream, pulling instead of cloning, and support updating subtemplates while keeping custom ones intact. I just need to take a look on how existing tools (such as plugin managers) work with git to minimze user interaction and verbosity (although verbosity and interaction might be preferrable in the update command, as it isn't used very often).

All in all, i ended up designing with "quietness" in mind, and this works with my original intended workflow (good enough schemes should be contributed upstream right away, templates should be as general as possible and require no tweaking whatsoever, and even if they do, that tweaked version should be a subtemplate and be contributed to upstream too), but is not very good if you prefer to keep non-tracked local changes.

Sorry for the lengthy reply, so. as for your use case, i would either:

For all of the above that involve editing any list.yaml, remember to avoid running flavours update lists and flavours update all, as that will replace your lists with upstream lists (i personally have a lot of templates and schemes that i created, but base16 maintainers are reaaally slow merging PRs, so i never update my lists with flavours, i manually add entries as they are added upstream)

I also would've like to add that you can use rewrite=true on your ~/.config/flavours/config.toml, for the cases where the template should replace the entire files (which i believe is what you might need?).

Let me know if that works for you, and feel free to drop how your .Xresources should look like and i'll be glad to help you out :)

MoburgLeGrand commented 3 years ago

Thank you for this awesome answer. Indeed, everything you said make a lot of sense, and the intended behaviour seems pretty fine to me now. I think I was mainly confused because I must be a lot less experienced than your average user. Which I think is OK and could help making your awesome tool even more user-friendly if that's what you aim for (and I think it is, since it's already pretty darn usable for someone like me). What you could do to help people like me understand it a bit better and not make mistakes while still retaining all the intended behaviours :

As for my case, I realized I could do way simpler. My problem was that I have urxvt settings in my .Xresources that I wanted to keep, and since I couldn't use the # flavours tags I had to use rewrite=true, so I just decided to put my urxvt setting directly into the template. The obvious solution was to write all the color info in a subfile that I source in my real Xresources, and rewrite only the colors file with flavours. This works perfectly well and seems a simple and elegant enough solution. I just didn't think about it before because I still have a lot to learn in managing files and configs efficiently, as I'm pretty new to the linux world.

Anyways, thanks for the awesome development and answer. I noticed you wanted help for the doc, so when I feel more comfortable with your tool I'll be sure to tell you if I see anything I think should be added / said more clearly.

Misterio77 commented 3 years ago

Thanks a lot for all your feedback and kind words!

I like these suggestions, and will surely implement a warning and write better docs about update.

I'm glad you got urxvt working. You're 100% right, sourcing a separate file (when supported) is definitely the "way to go". Just as tip for future configurations with non-default comments and no support for sourcing separate files, you can actually change the start and end comments! Here's an example with css files (which has /* foo */ comments):

[[item]]
file = '~/.config/beautifuldiscord/style.css'
template = 'styles'
subtemplate = 'css-variables'
start= '/* Start flavours */'
end = '/* End flavours */'

I think this is mentioned somewhere on the README.md, but it's definitely a documentation problem this not being more accessible for people starting out, and i will for sure tackle this problem (i was thinking on documenting the configuration options on a flavours(5) manpage).

Thanks again for your suggestion and kind words, i'm really glad my little program could be useful for you :)

Misterio77 commented 3 years ago

Closing this for now. If you have any other questsions, feel free to reopen!