[ECKO] Let's talk about themes

[MakaryGo]

@weex as per our discussion on matrix, I figured that instead of posting a wall of text on chat channel, I'll try out this fancy Discussions feature 😉 It concerns Ecko theming

Current solution:

For now, we use a rudimentary theming system, directly inherited from upstream Mastodon.
It's essentially just a set of .scss files dumped into /app/javascript/styles, with associated name in /config/themes.yml, so that they would be selectable in Admin Panel.

Pros:

• ✅ It's dead simple. There is lterally almost no possible way to make it even simpler.
  SCSS is well documented, a de facto standard in frontend development; it has a powerful syntax, quasi-programming featrues (variables, functions, etc.); it is compiled to stanard CSS and is even recognized by most modern web browsers.
  Also, it is really simple for any instance administrator to just create their own style and add oneliner to the config.

Cons

• ⛔ It requires additional tools. At this time there is no way to manually edit or upload custom style, it has to be put on the server using other means (SFTP, FTP, SSH, etc.). This not only may seem complicated for users without technical background, but also is a potential breaking risk, as it requires access to Ecko's files.
• ⛔ It is a potential update risk. As styles are included in main app codebase, if we sometime later add a new, public style using a name/filename same as the one defined locally, it will break.
• ⛔ It may break app update process. In the git-based host environments, if not properly configured, creating new files which are not properly commited/merged/ignored, may result in user being unable to properly upgrade the app.

Possible solutions:

This section is WIP, I'll try adding pros and cons to each option. Feel free to help 🙂

Decoupling themes from main app, just like plugins?

Creating some UI for creating local theme customisations? (May require implementing ###)

Porting flavours/themes from glitch-soc ?

How does it work?
Glitch-soc, an advanced, experimental fork of Mastodon, for UI customisation uses kind of a "double" system.
First there are skins, which are almost identical to vanilla Mastodon skins; they are SCSS styles, either as single files, or as whole style folders, in Glitch called packs.

From the documentation:

If you want to provide different stylesheets for various pages, you can do this by providing a folder instead of a single stylesheet as your skin. This folder should contain a number of files, each of which provides the styling for a different pack, which is served depending on page type. The available packs are as follows:

about: Rendered on the about/ page (but not about/more, etc) and on hashtag pages; this pack provides the timeline component.
(...)
share: Rendered on the “share” page; this pack provides a standalone composer.
The names of the files inside the skin folder should match the pack that they are meant to replace. For example, if I have styling that I want to show on the web app but not on static pages, I should specify it in app/javascript/skins/FLAVOUR-NAME/SKIN-NAME/home.scss.

Other, almost entirely separate customisation engine, is called Flavours.
According to the documentation, and the code, flavours can be as simple as single YAML file with definitions (vanilla), or as complex as recursive directory sets, containing configuration, multiple styles, images, React components, and even custom utilities (glitch), which can, if desired, override virtually any part of Mastodon's frontend.

Creating a whole new system?

... other?

[weex]

Extremely thoughtful kick-off for the discussion!

My favorite part is the list of Cons. I was trying to assemble the Venn diagram and one process I find helpful is to ask why until things converge or diverge. I can't show my work but I think these all boil down to some changes can only be done in code. magicstone-dev/ecko#359 might cover this or need to be improved/replaced.

If we want to support these kinds of customization then that's something we have to agree on. I don't think it's controversial at all. Needing to change code is a problem for all but developers and avid forkers... so almost everyone.

To help inform any solutions which I hope will be minimal in code, Ecko update processes that I've tried (source-based, docker-compose, and YunoHost) guarantee that the database and public/system folder don't get clobbered which makes them good candidates to store customization.

[MakaryGo]

Great! And I in turn want to get some more hands-on experience with Glitchsoc "flavours", so I forked it and created my own (absolutely basic for now).
P. S. It's called "Tastes like Ecko" 😉