Extended capacity to fully tailor the SCSS by creating the /data/scss/main.scss file

[nigini]

Previously, one could only change the theme of the SCSS, which contains a small set of variables used by the main.css. To do so, one must create a _theme.scss under the data directory (the one with all personal material).

This PR changes how the main.css is produced by the task compile-scss to look not only for the previous _theme file but also a full main.scss file under the data/scss/ directory. It uses the _theme.scss as before, but if it finds the main file, it will ignore the app/static/scss one and work with the personal version one.

[nigini]

Does this make sense to you all? @3b0b @chri2 @JD557

[3b0b]

I like the idea as a general principle, although I don't personally care about using it. I'm not sure I'd go with this implementation, though. In fact, I'm not sure I understand how this implementation works.

According to the Boussole documentation, it appears these paths in boussole.json will be relative to the location of the config file. In that case, it seems like, in combination with your moving of (and changes to) boussole.json, the instruction to change the first line after copying the file would actually keep it from working correctly. I may be misunderstanding something.

It also appears that in the custom case you're putting the compiled CSS in data/static/css; is that intentional? Or should it be ../../app/static/css?

I think, since boussole.json has to be copied anyway, that this could be presented as a feature allowing using a custom boussole config, with an explanation for how that allows for complete customization of the SCSS. In that case, the instructions could be to copy the whole scss folder into data (either backing up any changes to _theme.scss first, or leaving _theme.scss at its original location after all) and then modify as desired. The effect is pretty much the same, I think, so it's mostly the presentation.

Either way, it would make more sense to me to check for data/scss/boussole.json and use it if it is found, rather than to check for data/scss/main.scss and assume that its presence means there's also a data/scss/boussole.json.

Am I making sense? I haven't messed with this stuff in ages. My site is still running with my long string of customizations on top of your edit_post branch; I've been meaning to rebase, organize my customizations better (so that I can contribute some of them if anyone else likes them, for one thing), and see if that perchance fixes my Lookup functionality so that I don't have to try to figure out the problem with it myself...but I digress.

[nigini]

Thanks for taking the time to go through this @3b0b!

In general, though, (1) I want to keep the separation between a default UI that you get out of the box and the possibility of tweaking small things around; and (2) creating a way for building and distributing "skins" to the software (not that this implementation gets to that goal, but starts to give full SCSS control, as part of the data personalization package.)

I'll give more thought to this based on your feedback, especially around the need to copy the boussole file.