Variable Support in Themes in EmulationStation

jdrassa

@meleu I have been following that thread and your script is very cool. Unfortunately, it would need to be adapted, hopefully it won't be too difficult.

meleu

@jdrassa anything done to make the theme makers' life easier is worthwhile, they deserve it. :-)

And dealing with this change wouldn't be too hard. ;-)

darknior

A really cool idea :)

jdrassa

There are now three variables that are automatically defined. The values come from es_system.cfg.

system.name
system.theme
system.fullName

I have also converted carbon to use variables to better illustrate how themes can be simplified. It now consists of a single theme.xml file and all the image files now live under art.

https://github.com/jrassa/es-theme-carbon-var

mattrixk

@jdrassa That is so very very cool.

Syhles

@jdrassa

Lazy Edit: Split into section so it no longer as much of a text wall, may rewrite later if anyone is interested.

Any progress? This feature seems amazing, haven't used it personally yet but from my experience working on themes this last month this seems incredible. I also thought of something that would possibly be able to be done with this, you could set up theme modules.

Example: folder structure, your theme folder (Modular).

Inside it (Assets, Main theme.xml blank except bare minimum such as version information and such, All the system folders* will get to the purpose of it later).

In the Assets folder would be these folders (System, Basic*, Detailed, Video*, Backgrounds, Logos, Fonts, Icons) in All the previous mentioned Assets folders would be for example

(Carbon=Default, Eudora, Simple folders) and depending on the main folder (System, Basic, Detailed, Video) content inside would vary for those inside would be an XML name after the folder

Eudora=Eudora.xml, Simple=Simple.xml with the exception of carbon being Default.xml more on that later.

Then in the (Backgrounds, Logos) would be the respective(Carbon/Default, Eudora, Simple) folders were we would abuse the system name variable to have identical naming conventions.

Then backing up to main of the folder, all the systems folders such as (nes, tg16, etc.) would have a theme.xml only pointing to the (Detailed or Video, Default.xml)

Doing things in this manner would theoretically make changing a Detailed layout or logo set as easy as having modules in the right folders with correct naming conventions.

Changing the layout file you want to use to Default.xml and logo folder you want use to be named Default. If anything is unclear I apologise as I'm just waking up, if you have questions or reasons it wouldn't work feel free to let me know. I also understand that certain elements wouldn't be super modular such as fonts. The purpose of this would be if this was added to RetroPie after the System Carousel.

Let's say you have (Carbon, Eudora, Simple folders) in (System "Carousel", Basic, Detailed) by switching those around you could make 27 different theme variations (if Carousels were different for all three).

Zigurana

@Syhles I think your [Enter]-key is broken.

But seriously, @jdrassa, any update on this?

Nismo

@Syhles OMG my eyes!!!! what a mess!!

Syhles

I'll try and fix later on the computer. Sorry for the badly formatted and written text wall.

jdrassa

@Zigurana its mostly done. I've been distracted working on other things. Currently focused on a z-index implementation. Once that is done, I will probably switch back.

Zigurana

@Syhles
I'm still not quite sure what you are trying to accomplish here. It looks like you want to merge together all themes and potentially select a different element for each system?
Not sure what the modularity is what you keep referring to, part of a theme maybe?

The main issue with this approach is that these themes are designed by different people, who each try to create a very specific look-and-feel with their theme. So I don't know how well they would like it if we were to put it in a blender like that. (Not to mention differences in licenses).

But maybe I missed your point altogether, and you are trying to solve a different issue?

Syhles

@Zigurana
EDIT: Fixed some sentences and added some things.

My thought process isn't really to use others themes it's more to make multiple themes that have multiple xmls.

Such as a System.xml (for the carousel)
A basic.xml
A detailed.xml
And possibly a video.xml

That could potentially be swapped to make varying themes.

Example:
(Theme A)
System A.xml
Basic A.xml
Detailed A.xml
Video A.xml

Example:
(Theme B)
System B.xml
Basic B.xml
Detailed B.xml
Video B.xml

Want I want is:
System B.xml
Basic A.xml
Detailed B.xml
Video A.xml

My idea is that if 3-4 theme makers made a modular theme like this that were compatible with each other.

I want people that normally would just pick the theme that they just disliked the least because they have neither the time nor the ability to be able to have a more personalized theme by swapping some modules in and out to get more what they would like.

This could possibly end with more people actually making themes, after swapping modules leads to "maybe I'll edit this one thing" ends up a being a brand new theme.

I understand that this would lead to limitations in themes but not all themes need to be modular.

Please tell let me know if your still lost on what I'm suggesting or if I need to better explain or clarify anything.
Also feel free to tell me your thoughts on this.

Nismo

@Syhles I still don't understand that very well, where is the main.xml? where to place the art?

For example how can a image that I designed in my theme.xml to be displayed at 235x187 fit in other xml that uses 340x80?

All modular themes should follow the same template, otherwise the images would be stretched or deformed, metadata in wrong place, etc. So in the end all themes would be very similar to each other except for minor modifications.

With the disadvantage that in addition to being all very similar so that they can fit the images and metada from one to each other themes, it has twice work for theme developers.

And what about themes like mine? Where most systems are like a different new theme for each system? (not all but lot of them).

I still don't understand the point of this.

Most of the advances that are being made to ES (carousel, video preview, metadata, etc) are to give more freedom to the theme developers, and have more theming possibilities, while this limit the creativity of theme developers.

I personally see it a step back. This is just my humble opinion.

Syhles

@Nismo
I previously stated that this isn't something that all or anything theme makers need to do.

The whole idea behind this is for non-theme makers to be able to use these to make a slightly more personalized themes.

For example let's say 3 people make completely different theme layouts, that were compatible with each other and let's say that they each only have the system.xml, basic.xml, and detailed.xml.

With that alone you could make 27 unique themes granted 27 is a little bloated because basic.xml it's more like 9 unique themes.

I also stated making modular themes that were compatible would be constricting.

To answer your question about the main.xml it would be a placeholder basically.

The image size question, yet again modular themes would have restrictions to what would be possible.

Again I would like to reiterate not all theme makers need to do this and better yet this should not be the standard, it would be a major step down in theme making. This idea is entirely for the end user not theme makers exactly.

**Edit:**Art would go in (Default) or (art) for compatibly reasons. Also how would this effect how metadata is displayed as in this case the metadata would be in Detailed.xml so it would be in charge of it's layout.

mattrixk

@Syhles I kinda see where you are going with this, but it's an awful lot of work. I actually did something similar with the Io Theme, which used <include> to choose between code aimed at large, medium and small sized screens.

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.