Themes
#40
Replies: 2 comments 1 reply
-
thank u so much for the effort of doing the write-up. im busy implementing this now, I know my design skills suck and we really need theming. implementation is similar to what you have described |
Beta Was this translation helpful? Give feedback.
0 replies
-
implemented so far : in admin panel: in user prefs: right now it only loads 1 extra CSS and there are probably other ones overriding this one. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Continuing on from issue #38:
With the exception of the discovery page the only files I changed are html and css files. The branch can be viewed here. A themes option makes sense and I think that it might be a good idea to prioritize it so that we are not each making changes to the same file at the same time. I have a proposal on how this could work and how we could standardize our code contributions to keep it uniform:
User Perspective
A theme should be tied to each individual user. I do believe that the admin should be able to select the default theme for when a new user is added or for when a theme is removed.
Admin
Add a "Default Theme" option to the Server Settings (/admin/settings) page. Have it be a selection of the available themes with the theme names on the left and the description, screenshots, etc on the right when the theme is selected.
User
On the user Preferences (/settings_panel) page add an option for "Theme" which has the same selection style as the admin.
Backend
On the backend we would need to implement some changes to the code. We can standardize how we modify the html files and css files for theming. Essentially making the css files control all of the possible theme modification elements. This would allow for people to fairly easily make custom themes. It also would help keep our html files uniform across all themes.
HTML Files
Instead of using generalized classes for html elements, we could use a standardized naming convention to give each element its own class. That would allow for the stylesheets to completely control the elements that should be customizable by a theme.
Class Naming Convention:
stylesheet-elementdescription
For example if we applied this to the gamecard element on games_details.html (uses the game_details.css stylesheet) we would change:
Original:
New:
This would take some reorganization of the stylesheets to compartmentalize to each individual html page, but in the long run I believe it would make theming a lot easier. We would also need to make sure we do not define any styles in the element tags, and instead move them all to the css stylesheets.
Folder Structure
We would need a themes folder. Let's just say it is in the root direct and is /themes. Any themes would be in their own subfolder. So for example we might have this:
In each theme folder we would place all the of the css stylesheets. Screenshots of the theme would go in a Screenshots subfolder for that theme. We would also include a file containing the theme information so that there is versioning, author information, etc for the theme. The themes folder probably should also be added as a Docker path in the Docker compose so that people can easily add community created themes on their own.
Theme Information (Manifest) File
I'm taking some inspiration from the awesome job the developers of Playnite are doing. Theme authors can include screenshots, details, version, their github link, etc. Here is an example screenshot on the client side:
Here is the Github for that particular theme. Ours could be simpler than this. I don't know what kind of file format would be easiest to import but it looks like they use yaml (example). Here is some information that we may want it to include:
Database
On the database side we could add a column called "theme" to the "user_preferences" table. Also add a column called "default_theme" to the "global_settings" table perhaps? Not really sure on that one, that table is structured differently. As there is already a "themes" table it would make sense to use that.
Importing Themes
Certainly, a lot of options here on how this could be performed. I think however it is done it needs to be easy for the host to add custom themes by simply dropping the theme folder in /themes. From there it could either be them logging in as admin and clicking a button to refresh themes, which would trigger an event to scan the themes folder for the new theme(s) and to remove any that were deleted. Alternatively, it could be triggered by an event like a user accessing the site or something of that nature. We would need to make sure that when a theme folder is deleted and the theme is removed from the database, it sets any user using that theme back to the default them. When a theme is imported, it would make sense to name it in the database by either the folder name, or the name provided in the manifest. I don't know if it would be better to import all the information from the manifest file into the database or to just present that information on the user end directly from the manifest file. If we import it into the database, we will need to make sure there is a way for the database to be updated if that manifest file is updated.
Referencing Themes
I did not look at the code much here, but we would need to make changes to point to the stylesheets for the theme that is selected. Let's say the folder name is stored in the column "folder" in the "themes" table and is references by theme.folder. It might look something like this:
I might not be formatting that correctly, but you get the idea.
Summary
So basically, there are two sub-projects to this as I imagine it:
On my side, I could do part 1. I already made a lot of modifications to both the stylesheets and html templates, and I could go through the original (Classic) stylesheets and update them and then update my new ones as a Modern theme. It would take some time to go through this and I would prefer to put in one PR when it is all complete because it might break other pages if I do a little at a time. That being said, while working on this part it would be a lot easier for me if no changes were being to the html or css files during that time (or as little as possible at least). That way I don't have to go back and forth and try to update to match. Certainly, open to thoughts on this. Thanks for reading my wall of text!
Beta Was this translation helpful? Give feedback.
All reactions