Just a "master" list to track known issues working towards user supplied themes.
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:
{
"primary": "#00a4dc",
"secondary": "#303030"
}
:root elementWe 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
}
}
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: