Variable Support in Themes in EmulationStation

jdrassa

@ruckage no pain. I have the build process mostly automated at this point. You can download an update windows build using the link below. The build available there should always be from the latest source.

https://github.com/jrassa/EmulationStation/releases/tag/continuous

ruckage

@jdrassa said in Variable Support in Themes in EmulationStation:

@ruckage no pain. I have the build process mostly automated at this point. You can download an update windows build using the link below. The build available there should always be from the latest source.

https://github.com/jrassa/EmulationStation/releases/tag/continuous

Thanks, that's great - I appreciate it. I'll make sure to bookmark that link and then I won't need to hassle you :D .

A12C4

@jdrassa Nice I bookmarked that too, thank you a lot !

mattrixk

@jdrassa said in Carousel Enhancements:

I added this when I implemented theme variables

Cool. That reminds me, but what happens to themes that use variables on an older version of ES that doesn't support them? Can you / do you have to wrap them in the <feature> tag, is there some kind of fallback, or does the theme just break?

I figured it would be best to ask this question in this thread rather than derail the other thread

jdrassa

@mattrixk older versions will break. I didn't implement any type of compatibility support because it didn't really make sense for the use cases that I had in mind. The one exception to that is how they mix well with the default theme support. Themes can implement a default theme using variables without any worry about it effecting older versions of ES since they won't try to load the default theme.

EctoOne

I'm having some pathing issues with the example you provided. As i have understand this, it should be possible to move the following code from any system/theme.xml into the base.xml.

<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>
</image>

And therefore it should be possible that the system/theme.xml only contains:

<theme>
<formatVersion>4</formatVersion>
 <include>./../base.xml</include>
</theme>

The problem I'm having is that the paths are not resolved correctly. They look like this:
"C://ESWin/.emulationstation/themes/vartest/gamegear/..//system.svg".
So there is an extra ../ in the path which I don't know to remove.

Edit: NVM. I changed ${systemName} to ${system.theme} and it works now.

jdrassa

@ectoone another part of the work I did with this is that there is now the concept of a default system theme. This theme is in the root of the theme directory and must be named theme.xml. The default theme will be used when a matching system theme is not found. If your system themes are only including your base.xml and nothing else. Then you should just use the default theme. Then you will not have to create all of the system specific directories and theme.xml files.

Here is an example where I recreated carbon this way.

EctoOne

@jdrassa Welp, thanks. Now i can start all over to make carbon modular. At least now i know what I'm doing.

EctoOne

I'm having a small issue again. I have moved the following code (from the Switch Theme by @lilbud) from anysystem/theme.xml to the main theme.xml and replaced the System Names with the variable. But the text doesn't appear on the systemview, it does work on detailed/basic/video.

<view name="system">
  <text name="system_name" extra="true">
   <text>${system.fullName}</text>
   <forceUppercase>0</forceUppercase>
   <size>0.743 0.015</size>
   <pos>0.06 0.25</pos>
   <color>178ad2</color>
   <fontPath>./Oxygen-Regular.ttf</fontPath>
   <fontSize>0.04</fontSize>
   <alignment>left</alignment>
  </text>
  </view>
 <view name="basic, detailed, video">
  <text name="system_name" extra="true">
   <text>${system.fullName}</text>
   <forceUppercase>0</forceUppercase>
   <size>0.743 0.031</size>
   <pos>0.034 0.065</pos>
   <color>fefefe</color>
   <fontPath>./Oxygen-Regular.ttf</fontPath>
   <fontSize>0.03</fontSize>
   <alignment>left</alignment>
  </text>
 </view>

EctoOne

Heya, is there a certain requirement for variables names? I almost flipped my table because i wasn't able to fix an error. I tried <carouselStyle>, <123>, <var1>, <systemTheme> and all of them made ES Crash because it could resolve it.
But when i used a swearword it worked! Is this some sort of inverted child protection filter?

And i wish that this was possible:

 <variables>
  <carouselTheme>switch-dark</carouselTheme>
 </variables>

 <include>./_assets/system-${carouselTheme}.xml</include>

But in that case the variable doesn't get replaced according to the debug text.

lilbud

@ectoone So this would allow for mixing and matching of themes?

jdrassa

@ectoone said in Variable Support in Themes in EmulationStation:

Heya, is there a certain requirement for variables names? I almost flipped my table because i wasn't able to fix an error. I tried <carouselStyle>, <123>, <var1>, <systemTheme> and all of them made ES Crash because it could resolve it.
But when i used a swearword it worked! Is this some sort of inverted child protection filter?

Variables may consist of a-z, A-Z, 0-9, _ and .
I would expect all of the examples above to have worked. I will have to test them out.

And i wish that this was possible:
 <variables>
  <carouselTheme>switch-dark</carouselTheme>
 </variables>

 <include>./_assets/system-${carouselTheme}.xml</include>
But in that case the variable doesn't get replaced according to the debug text.

I recall having a good reason why I didn't implement this at the time, but I can't really remember what it was. For this specific use case, would you have other places where you reference the variable or is the idea just to centralize all the things that users might need to edit?

EctoOne

@lilbud It would do it in a more cleaner way. i this case, you don't need a variable but it would be more organized.

@jdrassa As of now the only reason is to centralize things. I'm working on a system where you only have to change three variables (well, four if you count the image suffix one too) to be able to easily change carousel logos, carousel layout and basic/detailed/video layout.
As of now, i have not found the need to use this specific variable anywhere else. But I've only merged two of @lilbud 's themes. Starting on the third one now, exited to see if something like this works:

<variables>
<3doColor>000000</3doColor>
...
<nesColor>f1f1f1</nesColor>
</variables>

<justsomeelement>
 <color>${system.theme}Color</color>
</justsomeelement>

jdrassa

@ectoone I can tell you now that will not work.

I considered implementing something along the lines of the following, but decided against it.

<variables>
  <systemColor>
    <3do>000000</3do>
    ...
    <nes>f1f1f1</nes>
    <default>111111</default>
  </systemColor>
</variables>

You should be ables to achieve something similar using system specific theme xml files.

3do/theme.xml:

<include>../theme.xml</include>
<variables>
  <systemColor>000000</systemColor>
</variables>

theme.xml:

<justsomeelement>
 <color>${systemColor}</color>
</justsomeelement>

EctoOne

@jdrassa aww, thats sad. i thought i could get rid of files and folders. If i would use your method i had to make multiple system/theme.xml for every theme that has special colors.
Welp, guess i can stop working on my template then. There's nothing more i can think of to improve it because of the restrictions. No offense because it was a great experience.

ruckage

@jdrassa
Hi, do you mind me asking why you decided against that - sounds like it would be a really useful feature to streamline themes further (was just trying to figure out the best way to achieve system specific colours myself).

Would an alternative option be to have a way to load external variables in from a text file?

You could have a text file that contains the variable and nothing else - in this case a colour, and give the text file the same name as the system:

arcade.txt

ffffff

You could then load in the variable something like this:

<loadVariables>
    <systemColor>./${system.theme}.txt</systemColor>
</loadVariables>

Loving the variable support by the way, I'm planning to use it extensively in my next theme.

EctoOne

@ruckage your suggestion i kinda the same like the one @jdrassa suggested besides that you could dump all txt files into one location. In the end you still have to create, open and edit over 60 files if you want to do it for each system.
It's seems easier to me to create different colored tiles, save them acording to the system.name und then implement them with the system.name variable as background image. Of course this only works if you want to use it as background or something similar.

ruckage

@ectoone
Not really, it still negates the need to have a separate folder for each system and it would allow you to colour any element in the theme using the loaded variable.
What ever you do you're still going to have files for each system if you want system specific elements, your suggestions doesn't change that and limits it to backgrounds only.

EctoOne

@ruckage The negation of separate folders was what i meant by "dumping all txt files into one location". :)
And i never said my idea was a good one, just an alternative with flaws.
I would prefer to use the method i mentioned up top and be able to mix variables into other variables.

jdrassa

@ruckage said in Variable Support in Themes in EmulationStation:

Hi, do you mind me asking why you decided against that

I was worried it would overly complicate things. If a lot of variables were defined that way, then it would be more difficult to get an overall view of what is different about a specific system. Where as maintaining system specific theming in the system specific theme file centralizes it.

@ruckage said in Variable Support in Themes in EmulationStation:

Would an alternative option be to have a way to load external variables in from a text file?
You could have a text file that contains the variable and nothing else - in this case a colour, and give the text file the same name as the system:

I think the problem with this approach is that once you start introducing multiple variables, the number of files you are creating will grow quickly.