Variable Support in Themes in EmulationStation

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.

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.