Variable Support in Themes in EmulationStation

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.

EctoOne

@jdrassa said in Variable Support in Themes in EmulationStation:

@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.

I always refrained to create an dynamic theme because of the one system per folder setup. I rather use threaded variables than maintaining multiple files. That allows me to save variants of code blocks for several elements.
It also is just a problem that themers would have to deal with, not the users.
If you would add that, it wouldn't break the option to still use the system/theme.xml method, am I right? So why not have both ways.

And to be honest, I was more confused by the fact that some complex code works, and some simple stuff didn't. Plus, that I had times, where - for whatever reason - the same code worked in one moment and then suddenly stopped working.

EctoOne

Heya, would it be possible to get a game.name variable? I mean one like system.name that could be used within an text element to display the currently selected game.
I was thinking about that after I accidentally turned the carousel from a navigation element into a design element when I was working on my Metroid theme.
Since the available elements for detailed view are limited, I always have a hard time to create something I like. And I thought what I could do if I could hide the gamelist and have just one game name on screen (now that I think of it, I probably just could make the gamelist very small to display one game... Welp, back to the drawing board.).
But still, I can see more options where I could use that variable. I'm thinking of ways to display more images based on a game without having extra tags in the gamelist. Although I'm not sure how ES handles images and that might be to resource heavy.

jdrassa

@ectoone Unfortunately that is not possible due to how the themes are loaded and when the variables are resolved.

EctoOne

@jdrassa Yeah i thought so.
But if i remember correctly, I've seen something like md_gamename when i was looking at the github discussion for grid view. Maybe that will be available in other views. But i'm so tired that i could be totally wrong about that.

jdrassa

@ectoone You are correct. Something like that was proposed with grid view. It would make sense to support it in all views.

ruckage

@jdrassa

I'm using the single theme.xml principle for my snes mini theme but I've hit a bit a snag.

I'm using the ${system.name} variable extensively to load system specific backgrounds and logos etc. which works really well and is far better than having a folder for each system.
However there is a downside - for unsupported systems and custom collections you lose the ability to have a default system as for example ${system.name}.png will always look for a png with the current system name and if it doesn't exist will load nothing.

Would it be possible if no file exists for ES to then assume that ${system.name}=default and then look for that file instead?

Eg. Assume that nes has no assets.

In the theme we have: <path>./${system.name}.png</path>
This will look for nes.png

This doesn't exist so as a backup ES will then look for: default.png
(basically it would replace the system name with the word default or another word of your choice)

I hope that makes sense, I love not needing a folder for every system - it makes changes so much easier and this seems to be the only real downside.

EctoOne

@ruckage What I did for the default background was to use a default image as background and have the system backgrounds load on top of that using zindex. But I agree that some default value would be useful, it would allow us to have a default logo on the carousel instead of plain text as well.

ruckage

@ectoone
Hi @EctoOne, I did consider that as an option but unfortunately it's not viable on my current theme as it uses so many layers. I've had to optimise it carefully as it is so adding even 1 more full-screen layer would sadly result in too much slowdown.

jdrassa

@ruckage I will need to think some about the best way to approach this. The way variables are processed, they are are resolved well before the values are passed to the actual gui components (i.e. ImageComponent, TextComponent, ...). As such, the components are unaware of variables.

I am leaning towards adding something like the following:

<image>
  <path>./${system.name}.png</path>
  <defaultPath>./default.png</defaultPath>
</image>

This would make the behavior very specific and deliberate.

jdrassa

@ruckage Also just to note. I see you are using ${system.name}. I would recommend using ${system.theme} instead.