Variable Support in Themes in EmulationStation

Syhles

@mattrixk
Indeed it would be a lot of work and this point it is more of a novelty concept then a usable methodology to make a theme, theme makers absolutely shouldn't make themes like this as it's constraining. This is for non theme makers.

Sorry for derailing the thread, the actual thread topic is way better btw.

Nismo

@Syhles When I say metadata, I mean if one themer make a "box" in the background for the metadata, and other themer make another box in other place, and you change the xml files, maybe the metadata it's totally out of place.

This could happen:

¡-------------------------¡
¡       box for      ¡ ------------------¡
¡   metadata         ¡                   ¡ 
¡------------------ -¡  metadata         ¡
                     ¡-------------------¡

That's because all "modular" themes must be pretty similar, too much things to fit from one theme to another. Apart from images. I'm already seeing it, same themes with different colors or backgroud pattern...

Also, if all the images go inside art or default folder, how do you separate the art of some themes from the others?

@Syhles said in Variable Support in Themes in EmulationStation:

@mattrixk
Indeed it would be a lot of work and this point it is more of a novelty concept then a usable methodology to make a theme, theme makers absolutely shouldn't make themes like this as it's constraining. This is for non theme makers.

If this is a lot of work for theme makers, I do not even want to think how it will be for non theme makers.... XD

KazanTheMan

@jdrassa I just stumbled on this thread from the z-index thread, and this is awesome. You are seriously putting in some work on this stuff left and right, and I appreciate it. If I might make a request for a ${romName} variable? It would make non-metadata images for specific ROMs actually implementable. I suspect it would be at least marginally more difficult to implement than ${systemName}, but it is something I would like to be able do in my theme.

Anyway, even if you decide it's not possible, the idea of a global theme.xml and being able to define custom variables is amazing and a boon to my efforts. Seriously, thanks again for all the hard work.

A12C4

I know this post is quite old, but I think this awesome feature is missing something.

If all your controllers are grouped in the ./art/controller folder and system logos are grouped in the ./art/logo, why not allow theme makers to group all their specific system related theme.xml in one folder ? Like ./xml/[SYSTEM_NAME].xml for example

How do you want the theme makers to use the new folder hierarchy ./[DATA_TYPE]/[SYSTEM_NAME].[FILE_EXTENSION] if specific system related .xml still need to use the old hierarchy ./[SYSTEM_NAME]/theme.xml ... that make no sens to me.

I know one of the main goal is to have only one theme.xml but for me removing specific system related .xml isn't even an option, it's a really nice feature to allow theme makers to change colors/size/whatever else independently for each system.

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