Variable Support in Themes in EmulationStation

jdrassa

@a12c4 That folder hierarchy is just an example. I am not suggesting that anyone has to follow that model. In the original post, I actually used the following as an alternate example, which preserves the way that most themes are created today.

<path>./${systemName}/art/controller.svg</path>

The main difference is that there is no standard to where art/resources should be stored. Even before this change, themes could have used either folder hierarchy.

I wouldn't say that having only one theme.xml was a main goal. It was more of a happy accident. I don't actually expect many themes to switch to using a single xml file, at least not anytime soon, since most/all will want to maintain backward compatibility for users who have not yet upgraded EmulationStation.

A12C4

@jdrassa Thanks for your fast reply, but I don't think you totally answered to my question.

What I mean is the standard old hierarchy was :
<path>./${systemName}/art/controller.svg</path>
<path>./${systemName}/art/system.svg</path>
<path>./${systemName}/theme.xml</path>

And a new standard could be :
<path>./art/controller/${systemName}.svg</path>
<path>./art/system/${systemName}.svg</path>
<path>./${systemName}/theme.xml</path>

Why is the hierarchy for system specific .xml still using old standard ? Why you don't create a new standard like :
<path>./theme/${systemName}.xml</path>
or
<path>./xml/${systemName}.xml</path>

Because right now if themes switch to this new standard, they would group all their art stuff in an "art" folder, but would still have one to maintain a folder for every system with only a system specific theme.xml inside of it.

I feel like you have a great idea but did only half of it, either not use this new hierarchy at all or push it to the limit.

meleu

I would like to know wich themes are currently using these variables to check if I need to change my tool to generate launching images based on ES themes.
Can somebody help me to get this info?

jdrassa

@a12c4 I am not necessarily against making this change. It is not a bad idea, it is just that I wouldn't anticipate many theme creators taking advantage of it anytime soon and I only have so much time to work on things.

That being said, I would be willing to pursue it if there was large support from the theme creators here on this forum.

jdrassa

@meleu I don't think very many are using it at this point. Most, will likely only use it for the default theme which use when a system specific theme does not exist.

ruckage

@jdrassa
Hi, sorry to be a pain again but is there an up-to date windows build with the new features such as Default themes, I want to test them out and and add them to my themes and its just easier to work in windows.

Thanks for all your hard work.

Syhles

@ruckage
Have you ever tried running Ubuntu? That's what I run and it makes themeing a tad bit easier as I don't need to wait/hope there's a windows build with what I need, also I think you can run and install Ubuntu on a flash drive so you wouldn't need to do a permanent install on your system.

ruckage

@syhles
That wouldn't help because all the software I use for creating the art is on Windows.

Syhles

@ruckage
Not to clutter the thread but what do you use?

ruckage

@syhles
I mainly use photoshop cc.

pjft

I suppose currently a system's theme is kind of contained within the logical grouping of a folder. There's nothing preventing this re-architecture from happening, but I struggle to see the obvious benefit at the expense of what would be a clear backwards-compatibility problem for theme makers.

Syhles

@pjft
I guess I would prefer a XML folder to hold xml's and I would rather have xml's named after the systems in that xml's folder instead of having to have x amount of folders so I can cover all the systems.

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.