Variable Support in Themes in EmulationStation

jdrassa

Hey everyone, I wanted to give a preview of something that I have been working on and see if this is something the community would be interested in seeing further explored.

This past weekend I carved out some time to try and add support for variables in themes. I decided to try this after being annoyed with all the files that needed to be changed while trying to add video support to some themes for testing. As well, as noticing how some themes have notes on how to tweak the theme colors by replacing all instances of a color in the theme.

The basic idea is that you would define variables as follows in the your XML.

<variables>
 <themeColor>8b0000</themeColor>
</variables>

Then you can reference theme elsewhere in the theme.

<image name="CenterFade" extra="true">
  <tile>false</tile>
  <size>1 0.5</size>
  <pos>0.5 0.5</pos>
  <origin>0.5 0.5</origin>
  <path>./art/centerfade.png</path>
  <color>${themeColor}50</color>
</image>

When the theme is loaded the placeholders will be replaced with the values defined in the variables elements.

I then decided to take things a step further and introduce the idea of pre-defined variables. The themes are loaded per system, so I was able to inject additional variables into this process that are supplied by ES based on the system for which it is loading the theme. Currently, I have implemented one such variable systemName which will be populated with the name of the system, but more could be added where if it makes sense. This can be used as follows.

<image name="ControllerOverlay" extra="true">
  <tile>false</tile>
  <pos>0.5 0.2</pos>
  <origin>0.5 0.5</origin>
  <size>0.3 0</size>
  <path>./${systemName}/art/controller.svg</path>
  <!--<color>8b0000</color>-->
</image>
		
<image name="logo">
  <path>./${systemName}/art/system.svg</path>
</video>

This would allow for more common elements to be moved into the base theme file that all of the system theme files typically import from. The system theme files would then only need to import the base file and could have little to no content of there own in them.

It then bothered me that theme makers would still need to maintain all these duplicate, nearly empty, theme xml files. So I then made a change to how ES loads the theme files. Currently, it first checks if there is a theme file in the rom directory, then it checks in the system directory of the currently selected theme. I added a third check to look for a theme.xml file in the root directory of the theme.

With this change, themes that are aren't making any system specific changes, could forgo creating a theme.xml file for each system. The end result is that it should be possible to create themes that consist of a single theme.xml and a single directory of images.

The code can be found on github for those who are interested. https://github.com/jrassa/EmulationStation/tree/theme-variables

lilbud

The game is changed, this will fix alot of issues with theming.

mattrixk

@jdrassa I love you.

Edit: is that too forward?

Nismo

@jdrassa Very nice commit. Thanks.

meleu

@jdrassa if this change reach the RetroPie's emulationstation I would need to adapt my script to generate launching images.

jdrassa

@meleu I have been following that thread and your script is very cool. Unfortunately, it would need to be adapted, hopefully it won't be too difficult.

meleu

@jdrassa anything done to make the theme makers' life easier is worthwhile, they deserve it. :-)

And dealing with this change wouldn't be too hard. ;-)

darknior

A really cool idea :)

jdrassa

There are now three variables that are automatically defined. The values come from es_system.cfg.

system.name
system.theme
system.fullName

I have also converted carbon to use variables to better illustrate how themes can be simplified. It now consists of a single theme.xml file and all the image files now live under art.

https://github.com/jrassa/es-theme-carbon-var

mattrixk

@jdrassa That is so very very cool.

Syhles

@jdrassa

Lazy Edit: Split into section so it no longer as much of a text wall, may rewrite later if anyone is interested.

Any progress? This feature seems amazing, haven't used it personally yet but from my experience working on themes this last month this seems incredible. I also thought of something that would possibly be able to be done with this, you could set up theme modules.

Example: folder structure, your theme folder (Modular).

Inside it (Assets, Main theme.xml blank except bare minimum such as version information and such, All the system folders* will get to the purpose of it later).

In the Assets folder would be these folders (System, Basic*, Detailed, Video*, Backgrounds, Logos, Fonts, Icons) in All the previous mentioned Assets folders would be for example

(Carbon=Default, Eudora, Simple folders) and depending on the main folder (System, Basic, Detailed, Video) content inside would vary for those inside would be an XML name after the folder

Eudora=Eudora.xml, Simple=Simple.xml with the exception of carbon being Default.xml more on that later.

Then in the (Backgrounds, Logos) would be the respective(Carbon/Default, Eudora, Simple) folders were we would abuse the system name variable to have identical naming conventions.

Then backing up to main of the folder, all the systems folders such as (nes, tg16, etc.) would have a theme.xml only pointing to the (Detailed or Video, Default.xml)

Doing things in this manner would theoretically make changing a Detailed layout or logo set as easy as having modules in the right folders with correct naming conventions.

Changing the layout file you want to use to Default.xml and logo folder you want use to be named Default. If anything is unclear I apologise as I'm just waking up, if you have questions or reasons it wouldn't work feel free to let me know. I also understand that certain elements wouldn't be super modular such as fonts. The purpose of this would be if this was added to RetroPie after the System Carousel.

Let's say you have (Carbon, Eudora, Simple folders) in (System "Carousel", Basic, Detailed) by switching those around you could make 27 different theme variations (if Carousels were different for all three).

Zigurana

@Syhles I think your [Enter]-key is broken.

But seriously, @jdrassa, any update on this?

Nismo

@Syhles OMG my eyes!!!! what a mess!!

Syhles

I'll try and fix later on the computer. Sorry for the badly formatted and written text wall.

jdrassa

@Zigurana its mostly done. I've been distracted working on other things. Currently focused on a z-index implementation. Once that is done, I will probably switch back.

Zigurana

@Syhles
I'm still not quite sure what you are trying to accomplish here. It looks like you want to merge together all themes and potentially select a different element for each system?
Not sure what the modularity is what you keep referring to, part of a theme maybe?

The main issue with this approach is that these themes are designed by different people, who each try to create a very specific look-and-feel with their theme. So I don't know how well they would like it if we were to put it in a blender like that. (Not to mention differences in licenses).

But maybe I missed your point altogether, and you are trying to solve a different issue?

Syhles

@Zigurana
EDIT: Fixed some sentences and added some things.

My thought process isn't really to use others themes it's more to make multiple themes that have multiple xmls.

Such as a System.xml (for the carousel)
A basic.xml
A detailed.xml
And possibly a video.xml

That could potentially be swapped to make varying themes.

Example:
(Theme A)
System A.xml
Basic A.xml
Detailed A.xml
Video A.xml

Example:
(Theme B)
System B.xml
Basic B.xml
Detailed B.xml
Video B.xml

Want I want is:
System B.xml
Basic A.xml
Detailed B.xml
Video A.xml

My idea is that if 3-4 theme makers made a modular theme like this that were compatible with each other.

I want people that normally would just pick the theme that they just disliked the least because they have neither the time nor the ability to be able to have a more personalized theme by swapping some modules in and out to get more what they would like.

This could possibly end with more people actually making themes, after swapping modules leads to "maybe I'll edit this one thing" ends up a being a brand new theme.

I understand that this would lead to limitations in themes but not all themes need to be modular.

Please tell let me know if your still lost on what I'm suggesting or if I need to better explain or clarify anything.
Also feel free to tell me your thoughts on this.

Nismo

@Syhles I still don't understand that very well, where is the main.xml? where to place the art?

For example how can a image that I designed in my theme.xml to be displayed at 235x187 fit in other xml that uses 340x80?

All modular themes should follow the same template, otherwise the images would be stretched or deformed, metadata in wrong place, etc. So in the end all themes would be very similar to each other except for minor modifications.

With the disadvantage that in addition to being all very similar so that they can fit the images and metada from one to each other themes, it has twice work for theme developers.

And what about themes like mine? Where most systems are like a different new theme for each system? (not all but lot of them).

I still don't understand the point of this.

Most of the advances that are being made to ES (carousel, video preview, metadata, etc) are to give more freedom to the theme developers, and have more theming possibilities, while this limit the creativity of theme developers.

I personally see it a step back. This is just my humble opinion.

Syhles

@Nismo
I previously stated that this isn't something that all or anything theme makers need to do.

The whole idea behind this is for non-theme makers to be able to use these to make a slightly more personalized themes.

For example let's say 3 people make completely different theme layouts, that were compatible with each other and let's say that they each only have the system.xml, basic.xml, and detailed.xml.

With that alone you could make 27 unique themes granted 27 is a little bloated because basic.xml it's more like 9 unique themes.

I also stated making modular themes that were compatible would be constricting.

To answer your question about the main.xml it would be a placeholder basically.

The image size question, yet again modular themes would have restrictions to what would be possible.

Again I would like to reiterate not all theme makers need to do this and better yet this should not be the standard, it would be a major step down in theme making. This idea is entirely for the end user not theme makers exactly.

**Edit:**Art would go in (Default) or (art) for compatibly reasons. Also how would this effect how metadata is displayed as in this case the metadata would be in Detailed.xml so it would be in charge of it's layout.

mattrixk

@Syhles I kinda see where you are going with this, but it's an awful lot of work. I actually did something similar with the Io Theme, which used <include> to choose between code aimed at large, medium and small sized screens.