Variable Support in Themes in EmulationStation

ruckage

@mattrixk said in Variable Support in Themes in EmulationStation:

This is how I thought (hoped) it would work:

create a folder called "details", create an xml for each system (gb.xml, nes.xml, snes.xml) then link to those files in the main theme.xml like <include>./details/${system.theme}.xml</include>.

This isn't working, but is there a way to do something similar with the current build?

Sadly it's not not possible at the moment, I had a similar issue with my latest snes-mini update and also tried using variables in the include tags as I wanted system specific colours for text etc.
In the end I had to use pre-generated images for all the text and other elements that I needed but it's far from an ideal solution. It make changes more difficult, limits what elements can be modified (I couldn't have system specific colours for metadata for example), and greatly increases the number of images needed for a theme.

Variable support in the include tags would be a really useful addition if it's possible.

mattrixk

@ruckage I thought that would be the case. When I made MetaPixel I just used a theme.xml within a folder for each of the systems, and those folders also held the logo and console images for each system. This was just the way things were done at the time.

Now variables allow you to name the images so that each system no longer needs it's own folder, but if you want custom content for each system, then you still need to use the individual folders, and if you are doing that anyway, then what's the point of using the variables.

I basically just don't like having lots of folders at the root level. I even tried having a folder called 'details' and having the 'gb', 'nes', 'snes' etc folders in there, each with their own theme.xml file, but that didn't work.

Oh well, for now I've just scrapped the idea of the custom content for each system. Less work for me that way I guess, but the System View doesn't look quite as interesting.

ruckage

@mattrixk

The variables are still useful and I really like using them, you can now do an entire theme with a single theme.xml which is amazing (I've made couple of themes like that now) and the variable system is perfect for any system specific images. It just falls down a bit when trying anything more complex as you can't access system specific xml files with text or colour information etc.

I know the argument would be that you can still fall back on the old folder per system approach but there are occasions when that just doesn't work well. For example on my snes-mini theme the system folders wouldn't have helped as the colour information in them would override any other colour options from my various config files due to the customisation system I have in place (the order files are included becomes very important with lots of options).

Hopefully there will be some more additions to the way variables are handled in the future for more experienced theme makers.

lilbud

@ruckage Using variables is so much easier than having 45 xml files for every system you want to have.

The only thing I wish we would do is be able to specify lines to read. Like you could have one xml with all the colors and have the main theme.xml read from the lines for each system.

Like the proposed colors.xml would be something like this:

line 43
<nes_color>
<color>FF0000</color>
</nes_color>

and the main theme.xml would have something like this:
<include>./settings/colors.xml</include>

<image name="background" extra="true">
<include>./settings/colors.xml</include>
<pos>0 0</pos>
<tile>true</tile>
<origin>0 0</origin>
<size>1 1</size>
<path>./assets/box.png</path>
<color>
</image>

ruckage

@lilbud
Variables are very useful, I made the Megatech and Neogeo mini themes using only a single xml file. The negeo-mini one is also completely future proof as it uses text instead of system logos so it supports all systems from the get go so there are not even any worries about missing systems.

Regarding your suggestion @jdrassa had already considered something similar but decided against it which is a shame as I thought it was a really good idea (see this post: https://retropie.org.uk/forum/topic/7156/variable-support-in-themes-in-emulationstation/50)

In my case to port over the nes theme to the snes-mini theme the only option I had was to generate images for all the text, selection bars, rating icons, etc. That totalled 649 images which If I could use variables in the include tag could have been reduced to just 59 simple xml files defining each systems colours. I have a feeling though that there is maybe a technical reason why variable can't be used when calling xml files with the include tags.

mattrixk

@ruckage The work you put into your themes is seriously impressive. I've actually been using both your and @lilbud's themes to figure out how the variables work and how to make them work for me.

My new theme will most likely only have a single xml file and 4 folders (fonts, background images, console images and logo images). I will have support for most of the major systems, but it shouldn't break any systems it doesn't support.

Hopefully I'm able to see the whole thing through and not lose interest before I finish, like what happened with Core.

EctoOne

@mattrixk Don't forget that you can set up your theme to support unknown systems by naming your main xml theme.xml. Then all settings will apply to unknown systems as well and you can have a basic setup instead of the default black theme.
Also we have some more options to theme <text name="logoText">. Well it has line spacing and support to change the default text now. You can look at my Flatline theme if you need to know more about it, it just uses text as logos. It actually shows a easy way to change certain data for specific systems as well (still using the system subfolders though), I just has the content in the extra xml files, the style is defined in the main theme.xml. It's the same method I used for the chicuelo theme. But yeah, I would also prefer to be able to use variables in include tags to get rid of the sub folders.

Oh, and the helpsystem element now supports origin as well.

mattrixk

@ectoone: I have been using theme.xml for the main xml, but I didn't realise that was why my unknown systems no longer went black. I just thought it was something the newer versions of RetroPie/ES did by default, so thank you for that info.

I've gotten the <text name="logoText"> to style quite well for the unknown systems, and the origin for the helpsystem is really helpful for center-aligning it.

I wouldn't mind using individual system folders if I could move them out of the root level, into another folder called "details" or something, then using:
<include>./../../theme.xml</include>
instead of:
<include>./../theme.xml</include>
to point back to the root level theme.xml.

I just hate the clutter of dozens of folders on the root level.

EctoOne

@mattrixk To avoid confusion with the sub folders, I personally use one main _assets folder with it's own subfolder structure. Because of the _ it will always be the first folder and then I basically don't care what's in the root folder anymore. Also while developing different systems, I just do like two or three (because of the different boxart layouts) to keep my root clean and add the others when I'm done.

jdrassa

@mattrixk said in Variable Support in Themes in EmulationStation:

This is how I thought (hoped) it would work:

create a folder called "details", create an xml for each system (gb.xml, nes.xml, snes.xml) then link to those files in the main theme.xml like <include>./details/${system.theme}.xml</include>.

@ruckage said in Variable Support in Themes in EmulationStation:

In my case to port over the nes theme to the snes-mini theme the only option I had was to generate images for all the text, selection bars, rating icons, etc. That totalled 649 images which If I could use variables in the include tag could have been reduced to just 59 simple xml files defining each systems colours. I have a feeling though that there is maybe a technical reason why variable can't be used when calling xml files with the include tags.

Sorry for not chiming in sooner. With all this renewed discussion about using variables in imports, I decided to take a second look at it. Originally, I didn't really see the need, but you guys had some interesting use cases I hadn't thought about. It turns out it was rather simple to add.

Windows Test Build:
https://ci.appveyor.com/project/jrassa/emulationstation/builds/19772435/job/m9catyopoonjfi8a/artifacts

ruckage

@jdrassa Good to hear from you. That's great news, it definately will be useful in certain cases. I'll give it test later.

darknior

@jdrassa Good news, thanks a lot for it :)

EctoOne

I just tried this version and using my own variables for includes worked:

 <variables>
  <var1>shortcut1</var1>
 </variables>
 <include>./${shortcut1}.xml</include>

But I wasn't able to get system variables to work:

<include>./path/${system.theme}.xml</include>

I tried that to remove all system folders, but the settings from the renamed/moved system/theme.xml didn't show up in the theme.

jdrassa

@EctoOne I think it is loading, I am pretty sure that the theme will fail to load if it can't find and include. Do you have settings in your base theme.xml that could be overriding the settings in /path/${system.theme}.xml? The way theme files are parsed is that first all includes are processed, before moving on to the main content of the the file.

Previously, ./system/theme.xml included ./theme.xmlso theme.xml would be parsed first and then ./system/theme.xmlwould be parsed and override any settings previously parsed.

Now you have ./theme.xml including ./path/${system.theme}.xml so ./path/${system.theme}.xmlwould be parsed first and then ./theme.xml would be parsed and override any settings previously parsed.

I haven't actually tested to confirm, but I am pretty sure that is what is happening.

Depending on how your theme is setup, what you may need to do is move most (all?) of the main content from theme.xml to something like common.xml or base.xml and then have theme.xml just have includes. That way you can control the order they are parsed.

EctoOne

@jdrassa Ah that would make sense. Because yes, I tried that with my Flatline theme which only uses ./system/theme.xml to format some of the system names and with your explanation they would be overwritten by the default ${system.name} I'm using in the main xml.

Using a theme.xml with includes only worked. Thanks!

BTW: Are you going to update the windows build any time soon? It appears that this version has not the new datetime component and from what I've seen on github both changes have been merged into the dev version already.

jdrassa

@EctoOne windows build is updated now. It should be automated, but I have been testing out a new method for keeping my repo synced with the RetroPie one and for some reason it didn't work this time.

EctoOne

@jdrassa Oh, I noticed an updated version on your github like over 24 hours ago and assumed that was the build you pushed after my question. I used it for quite some time and noticed no errors (I even tried the new <datetime> component with <lastplayed> this time) for the new stuff.

There is one thing I noticed though. <video name="md_video"> supports <rotation> but that doesn't apply to the thumb that's shown before the video or when no video is available. It would be great if that can be added and maybe rotation support for <textlist name="gamelist">and <text name="md_description">.
Those are basically my last requests when it comes to theming. Besides the options to theme the ES GUI (including the <helpsystem> buttons) and the method to select <includes> from the GUI that the recalbox version has and I already mentioned here.

Anyway, I appreciate the work you guys are doing.

jdrassa

@EctoOne said in Variable Support in Themes in EmulationStation:

There is one thing I noticed though. <video name="md_video"> supports <rotation> but that doesn't apply to the thumb that's shown before the video or when no video is available.

This sounds like a bug/oversight when rotation support was added. I'll check it out.

It would be great if that can be added and maybe rotation support for <textlist name="gamelist">and <text name="md_description">.

Unfortunately, for these, it is not a simple task to implement rotation due to how the scrolling is implemented.

EctoOne

@jdrassa said in Variable Support in Themes in EmulationStation:

@EctoOne said in Variable Support in Themes in EmulationStation:

It would be great if that can be added and maybe rotation support for <textlist name="gamelist">and <text name="md_description">.

Unfortunately, for these, it is not a simple task to implement rotation due to how the scrolling is implemented.

Yeah I thought so. There still is that one comic wallpaper I would love to turn into a theme but with straight lines it just looks wrong.
Although, was it you who was trying to implement the carousel as gamelist replacement? And if, is that still a thing? Because that would actually look nice with some rotation magic. Assuming it would support all the options from the system carousel.

EctoOne

@jdrassa I just encountered a big flaw while using ${system.theme} in an <include> tag.
If it can't find the specific file, e.g. if someone uses an custom collection, it breaks the whole theme for that selection. All theme settings are suddenly ignored.

I had the idea to create some sort of external metadata library for systems that could be simply used by theme makers just by including a single file which further imports the metadata from ${system.theme}.xml files and also provides labels. It also imports a file which is used to theme those text elements.

I integrated that into my Flatline Theme here for testing purposes and noticed that behaviour.

To make the process clear again:

theme.xml includes _assets/mds_include.xml
mds_include.xml includes mds_data/${system.theme}.xml and mds_style.xml

It would be great if you could take a look at it and tell me if I made something wrong or if that is unavoidable for now. I mean I know that ES will fall back to the default theme if it can't find an include file. Maybe there's an way to ignore that error.

Edit: I just had another idea, would it be possible that ${system.theme} returns default if an unknown system is selected? Then we could use files like default.jpg or default.xml.