Jellyfin-web: [Meta] List to track user customizable theme support

Created on 2 Jan 2019  路  14Comments  路  Source: jellyfin/jellyfin-web

Just a "master" list to track known issues working towards user supplied themes.

  • [ ] Make it so themes are not hard coded #68
  • [ ] Move all theme related color codes to theme .css files #69
  • [ ] Add way to upload user themes #70
  • [x] Remove seasonal themes #71
feature

Most helpful comment

What about this structure to support existing CSS themes, as well as provide variables that other non-HTML clients can also to use:

{
    "themeVariables": {
        "Could be limited to just colors, or also include other things like border-widths, etc.": "",
        "primary": "#00a4dc",
        "secondary": "#303030"

    },
    "customCss: {
       // To support existing CSS-only themes. This css could reference the variables above
    }  
}

All 14 comments

Want me to make a project for this? I don't think I can give you permission to change it, but I'll add cards and the relevant automation as needed.

If you want. So far I've just been making these meta issues to track similar tasks. No sense having 200 issues with no organization, right?

Can also project up the other one I opened.

@sparky8251 Move this over to -web? I can transfer it.

_Moved._

After a lot of work trying to separate the web source from the server I dont' think themes should be handled by the server at all, thus closing most of these issues. My eventual goal is to include a settings.json file in the web directory that will include options like pagination values (default of 100 up to infinite) and a multiserver toggle at first. If we continue with the theme (heh) of web being separate from server, then the proper thing to do for user themes would just be to copy them over to the themes directory and include an option in settings.json to add custom theme locations.

Issues go stale after 90d of inactivity. Mark the issue as fresh by adding a comment or commit. Stale issues close after an additional 14d of inactivity. If this issue is safe to close now please do so. If you have any questions you can reach us on Matrix or Social Media.

shoo bot

Issues go stale after 90d of inactivity. Mark the issue as fresh by adding a comment or commit. Stale issues close after an additional 14d of inactivity. If this issue is safe to close now please do so. If you have any questions you can reach us on Matrix or Social Media.

Issues go stale after 90d of inactivity. Mark the issue as fresh by adding a comment or commit. Stale issues close after an additional 14d of inactivity. If this issue is safe to close now please do so. If you have any questions you can reach us on Matrix or Social Media.

Some proposal for this:

  • Add an API endpoint to GET, ADD and DELETE themes
  • Themes are JSON objects with key/value pairs kind of like this:
{
    "primary": "#00a4dc",
    "secondary": "#303030"
}
  • On the web client, there is only one "theme" CSS file (they're mostly duplicate anyway).
  • During bootstrap, the theme API is queried to get the current theme for the server or user
  • The colors are stored as CSS variables in the :root element
  • A polyfill for CSS variables is added (See here: https://www.npmjs.com/package/css-vars-ponyfill)
  • When changing the user or server theme, the API is queried and the CSS variables are replaced, thereby updating the colors for the user

We can add a theme editing page to the admin dashboard to add, remove or edit themes, which would make calls to the API as well.

This idea would also result in letting non-CSS supporting clients support themes which would be huge.

I'm in favor of it.

We probably need some input from @jellyfin/backend for the API part.

So this would break the extensive customization available for themes right now. @grafixeyehero has dome some extremely nice things with purple haze that wouldn't be available with this system.

I also question how many clients would utilize these global themes considering most third party clients will probably want their own style and most of our native clients are either already using web or will probably keep their existing design. Android TV might look good with different primary and secondary colors, but that's about as far as you could go without extensive work to handle custom borders or graphics, which would be a nightmare to support across platforms. Should we really cripple the existing customizability for themes just so we can say it's a new endpoint on the server?

What about this structure to support existing CSS themes, as well as provide variables that other non-HTML clients can also to use:

{
    "themeVariables": {
        "Could be limited to just colors, or also include other things like border-widths, etc.": "",
        "primary": "#00a4dc",
        "secondary": "#303030"

    },
    "customCss: {
       // To support existing CSS-only themes. This css could reference the variables above
    }  
}
Was this page helpful?
0 / 5 - 0 ratings

Related issues

AndreCarvalho picture AndreCarvalho  路  6Comments

hamburglar2160 picture hamburglar2160  路  4Comments

hamburglar2160 picture hamburglar2160  路  5Comments

arhamqureshi picture arhamqureshi  路  5Comments

Steve0w3n picture Steve0w3n  路  6Comments