Variable Support in Themes in EmulationStation

jdrassa

@ruckage Latest build should have the fix.

ruckage

@jdrassa
Perfect, working again now. Thanks for fixing it so quickly :) .

Was this something just affecting your build or was it a problem in the main branch as well?

jdrassa

@ruckage It was a problem on the main branch as well (or would have been). RetroPie's repository now uses 2 branches, master and stable. RetroPie-Setup now has an ES dev module that pulls from master, while the main ES module pulls from stable. The change was present on master, but hadn't made it to stable yet.

A12C4

@jdrassa I created a theme from scratch to better see how it work, and one thing that annoy me is there is no way to perform basic math operations on variables. For example, right now I position the metadata labels and values like this :

	<variables>
		<!-- POSITIONS AND SIZES -->
		<PosHoriMetadataLabel>0.012</PosHoriMetadataLabel>
		<PosHoriMetadataValue>0.024</PosHoriMetadataValue>
	</variables>

	<view name="detailed, grid">
		<text name="md_lbl_players">
			<pos>${PosHoriMetadataLabel} 0.24</pos>
		</text>
		
		<text name="md_players">
			<pos>${PosHoriMetadataValue} 0.28</pos>
		</text>
		
		<text name="md_lbl_genre">
			<pos>${PosHoriMetadataLabel} 0.34</pos>
		</text>
		
		<text name="md_genre">
			<pos>${PosHoriMetadataValue} 0.38</pos>
		</text>
		
		...
	</view>

As you can see, I can easily change the horizontal position of metadata labels and values just by changing one of the 2 variables accordingly.

But why not pushing it farther ? Why can't we do the same with vertical positions like this :

	<variables>
		<!-- POSITIONS AND SIZES -->
		<PosHoriMetadataLabel>0.012</PosHoriMetadataLabel>
		<PosHoriMetadataValue>0.024</PosHoriMetadataValue>

		<!-- Position at which the metadata start -->
		<PosVertMetadataStart>0.024</PosVertMetadataStart>
		<!-- Spacing between 2 metadata labels -->
		<SpacingMetadata>0.010</SpacingMetadata>
		<!-- Spacing between a metadata label and its value -->
		<SpacingMetadataValue>0.004</SpacingMetadataValue>
	</variables>

	<view name="detailed, grid">
		<text name="md_lbl_players">
			<pos>${PosHoriMetadataLabel} (${PosVertMetadataStart} + 0 * ${SpacingMetadata})</pos>
		</text>
		
		<text name="md_players">
			<pos>${PosHoriMetadataValue} (${PosVertMetadataStart} + 0 * ${SpacingMetadata} + ${SpacingMetadataValue})</pos>
		</text>
		
		<text name="md_lbl_genre">
			<pos>${PosHoriMetadataLabel} (${PosVertMetadataStart} + 1 * ${SpacingMetadata})</pos>
		</text>
		
		<text name="md_genre">
			<pos>${PosHoriMetadataValue} (${PosVertMetadataStart} + 1 * ${SpacingMetadata} + ${SpacingMetadataValue})</pos>
		</text>
		
		...
	</view>

That way it is a bit harder to setup, but once it's done you can quickly change all the metadata order, it's spacing, it's position, etc ... just by changing one variable's value. Do you think more people would use that or I'm just overcomplicating things ? Would it require huge changes to EmulationStation's theme parsing code ?

darknior

Hi every one :)
I have try to use this VARIABLE feature to make my theme and nothing working for me :(

<theme>

	<formatVersion>4</formatVersion>

	<variables>
		<selectColor>1f9be7</selectColor>
		<textColor>4c5058</testColor>
	</variables>
	
	<view name="system, basic, detailed, grid, video">
...

And when i had these var to my skin ES don't want to load it.
I'm using the emulationstation-dev from retropie-setup

Using ${system.theme} not working but not break my skin.

Is it the correct version plase ?
Thansk

ruckage

@darknior
It may be related to the problem reported a while ago (see here: Post 78 )
@jdrassa said the bug was present in the dev version (which you're using) but not in the stable version.

darknior

Sorry for the VARIABLE bug it's my fault :(

I write <textColor>4c5058</testColor> and replace X by S ... stupid guy :p

@jdrassa said in Variable Support in Themes in EmulationStation:

@ruckage It was a problem on the main branch as well (or would have been). RetroPie's repository now uses 2 branches, master and stable. RetroPie-Setup now has an ES dev module that pulls from master, while the main ES module pulls from stable. The change was present on master, but hadn't made it to stable yet.

@ruckage Thanks ... but if i understand fine the bug was removed from the DEV branch (Master). I'm not using the Stable one.
If my english is so bad and i don't understand fine, i wish @jdrassa will fix it to in dev branch. Dev branch has many update not in Stable one, like now Thumbnail preview if no video that working fine :)
But with a SIZE bug for the moment :p

ruckage

@darknior said in Variable Support in Themes in EmulationStation:

@ruckage Thanks ... but if i understand fine the bug was removed from the DEV branch (Master). I'm not using the Stable one.
If my english is so bad and i don't understand fine, i wish @jdrassa will fix it to in dev branch. Dev branch has many update not in Stable one, like now Thumbnail preview if no video that working fine :)
But with a SIZE bug for the moment :p

No, it was the other way around, the bug was in the Dev branch (Master) but hadn't made it into stable I believe. Hopefully if the Dev branch hasn't been corrected yet it will be in the future (otherwise it will end up in the stable version as well).

The bug stopped built in variables such ${system.theme} from working so it sounds like the bug is still present in the dev version you're using - have you updated it recently?

darknior

@ruckage said in Variable Support in Themes in EmulationStation:

The bug stopped built in variables such ${system.theme} from working so it sounds like the bug is still present in the dev version you're using - have you updated it recently?

Ok, i will stand for it :)
Yes this morning to try this new feature : https://github.com/RetroPie/EmulationStation/pull/362#issuecomment-362193592

EctoOne

I can confirm that the system.theme bug is indeed fixed on the dev branch. I also updated a few hours ago to test the new thumbnail fix.

mattrixk

Hi @jdrassa, I've been away from theme making for over a year, but I'm getting back into it now, using variables for the first time. I have a question (it was sort of answered around post 57 of this thread, but not fully.

For system logos I can put them in a folder called "logos" and name them gb.png, nes.png and snes.png, then link to them with <path>./logo/${system.theme}.png</path>.
For console images I can put them in a folder called "console" and name them gb.png, nes.png and snes.png, then link to them with <path>./console/${system.theme}.png</path>.

I want each system to display additional information on the System view (stuff like console generation, year of release, units sold and a brief description). The old way would be just have a folder for each system with a theme.xml file inside, but I'm trying to cut down on the number of folders, and this seems like something variables would be able to help with.

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?

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.