Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Theme System Changes #139
So the next EmulationStation "update" (when I merge the unstable branch into master) is going to break everything to hell (but there's an integrated scraper now!). In particular there's the new XML format for es_systems.cfg format and the theming of the fast select box completely changing (which no one was using anyway). I feel these are honestly pretty minor changes, but breaking backwards compatibility is not to be taken lightly.
There is one more big change I have been considering: changing the theme system. I'm bringing this up now because I'd like to break everything in one update, rather than two.
The current theming system is incredibly flexible. This was good when there wasn't really a strong sense of how the game list would look. It gave people much more artistically inclined than myself the option to tweak things as much as they wanted. When there was only one screen (the game list), it worked well. Now, the game list has settled on a few basic elements: a background image, a header, game art, scrolling game info, and maybe a divider.
I think the biggest mistake I made designing the current theming system was allowing each system's theme to create elements individually. That flexibility comes at a price: introducing new ways of viewing the game list will fundamentally require new themes for every system, similar to the distinction between
I see a few ways to go:
(A) Completely get rid of the current system, only allow themes to specify resource paths. Layouts become completely hardcoded. This offers the most developer control and the least artist flexibility, but it would be possible to get any theme to work and look mostly consistent across multiple views without changes to the theme.xml. Consistent resource naming and typing is obviously very heavily enforced.
(B) Split themes into "resource" and "layout" definitions. This would require significant work, but almost completely keeps flexibility. Instead of allowing a system's theme to move elements, only new resource paths and parameters can be specified. Almost all of view design complexity is moved from C++ to XML. So long as themes follow resource naming consistencies, introducing new views should not be too much of a problem. Animation details can be worked into the layout format.
Detailed example, I am making this up as I go along:
(C) Don't change the theme system. Add new tags like
This has serious consequences for folks who use EmulationStation and potentially spent a lot of time tweaking their themes to get them just the way they like, so I'd like to ask the community:
B) the coding hell. in this case you are not building a frontend for emulation, you are building a animation e GUI framework. like LUA. you will have to code every feature and create a XML interface to let the user use it in the themes files. emulationstation will never have a user experience, everyone will do each own (or copy it from somebody) and probably you will need a team just for take over the open bugs and features requests.
C) the maintenance purgatory. if you code a nice feature you will have to put it the themes system and any old themes will no longer be valid (or look ugly) so everyone will need to update it.
sorry for bad english ;)
You're exactly right, I think.
I think I'm going to go with A.
B works for the current game list example I gave and maybe a "tile view" example...but indeed evolves into basically building a scripting language as you do anything complex (by "complex" I mean something on the level of pretty much any XBMC view or displaying more than one game's metadata at a time).
Going through the existing RetroPie themes, I think that it should be possible to encompass almost every existing design with:
The only outlier might be the Genesis theme (its header is designed to take up the top left corner). Since this seriously affects RetroPie, what do you think @petrockblog?
I would also prefer a unique look and feel, so option A) sounds good!
Doing a bit of brainstorming, I am additionally thinking of
I am not sure if these ideas fit into the context of this thread, though.
I've almost got everything in the unstable branch working as well as the stable branch. I think all that's missing right now is some of the metadata display and the animation for when game images come in/go out. Here's a partial changelog. The new theming system is a lot more limited than the old system was, so I'm pretty hesitant to call it a feature.
You should be able to test it out with my RetroPie-Setup fork, which uses the unstable branch. The only thing it's missing right now is a way to install SDL2, since it's not in the repositories (well, 2.0.1 isn't, at least). If you install it manually before compiling ES it should work fine (download, run
I recently set up RetroPie and now i am about to customize my themes for EmulationStation. Attached a first impression of what a theme could look like based on the current ones. I did the SNES theme first because it's my favourite retro console :-)
What do you think? ... and is this possible with the new theming system? I am using a build of ES from Nov, 3rd.
I am a graphic artist and familiar with interface design, so for me it wouldn't be so good to restrict the possibilities in theming. I would love to see EmulationStation with a theming system like XBMC where the user has complete freedom.
That design is mostly possible with the old theming system (which is what is currently in RetroPie). I think the only thing that is not is moving the description text to be on the right of the game image.
Now that the theming system has been re-implemented I'll show it off a little...(you can see all these pictures in their original resolutions in this album if you prefer)
This is the current "detailed gamelist view" screen. It's almost identical to the old one. I still haven't re-added the fade in/out animations or the extra metadata to the description text.
Another for NES (the box art is too big here to display the description...better add some better resizing stuff later!).
The theming system has changed how it loads "defaults" now. It starts out with the initial programmer-defined defaults (useful because default images can be compiled into the source now). Next, it loads the
So these are the magical theme files that make those two pictures:
As you can see, it's really easy to do. There's also no more duplicate definitions all over the place.
If you're wondering what the
You can't see it, but the transitions between gamelists are also waaay nicer now too.
And to address the problem of making things more restrictive...here's one of the perks to doing it this way.
This new "grid view" was written in a couple of afternoons, and requires no changes to the existing theme file(s) to work.
There's no perfect answer. Making something like XBMC is possible, but really beginner-unfriendly. It's hard to say for sure, but I think most people would rather not take the time to learn to use complex but powerful tools. Anything you could do through any scripting layer I add can be done (and usually done better) on the C++ side. That said, it would be possible to bring back most of the old functionality through some sort of view-specific "add extra components" tag. I am not sure if I want to do this yet.
Secret bonus: sometimes I get bored while debugging and this happens
thank you for showing us the work you've done so far. As i am more from the graphics and UI side, i don't know if i did understand everything in your post. I will try to explain how i see it.
So EmulationStation will provide a hardcoded default theme if no XML files are present. If
The problem i see here is that all the elements have fixed positions and dimensions, because there are no attributes in the XML to control that. That would restrict creative freedom in creating themes a lot. I would go a different approach, very much like the old system where the user can use and place pre-defined elements like "boxart", "description", "list", "header" where each element has various attributes like "font", "size", "position", "tiling" and so on. I think this approach is more in the mind of the users out there because freedom is everything for a community. Theming should be entirely XML based and not hardcoded. The stock-version of ES could provide themes which the user can modify or replace by his own. that said, i would love to work together with you to create the stock-themes for EmulationStation.
As for the grid views, i think that's a great idea. As for the system select menu: Are you planning a sort of hierarchic menu structure where the user first selects the system, then the game from list or grid view? i personally think there is no need for the system menu, i mean it's nice but it's a step more to get to the game you want to play. besides, the list or grid view communicates which platform you are viewing at the moment, so thats another reason to drop that screen.
No matter if you want to restrict theming functionality or not, i would love to work together with you to create solid and nice-looking stock-themes. That would be a project i always wanted to do.
Can we talk about theming in a greater depth? I'll drop you an email.
@retrofan87, could you provide me with the theme that you have shown above? I am almost done with my RetroPie, and I would love to use your theme. My email is billipo at yahoo.com
Again, I hope you and Aloshi are able to work together in the future to really refine the look of Emulation Station. I believe it's one of the best emulator platforms available for 80's and 90's games.
I am using a build on my Pi called Ultraslim. It features ES with Retroarch and XBMC etc.. I'm sure you're all aware of it.
Anyway, the themes above (grid view etc), are these attainable at the moment with an update? Or are these still in development? The system selection menu seems fantastic and I would love to implement it into my build.
Still in development. The system select screen has been redone since then to work like an endless carousel (picture). I've been working with @retrofan87 over the past couple of months, and a lot has changed. The theming system has been rewritten again because he finally convinced me it was a stupid idea to remove such an important feature from ES. We've finally got a plan for how ES should work, and are slowly putting it into action - for example, here's the first version of the new menu style (not final!).
That said, there is still a lot to do. The biggest reason no one can really try it out yet is because no themes exist for the new theming system (except my private rewrite of the RetroPie SNES theme and @retrofan87's SNES theme).
It's still going to be a while, unfortunately.
retrofan87 speaking :-) changed my nick to my default one. After @Aloshi and me have implemented all the UI stuff (menus, help system etc.) i will finish building the system-specific themes (shown earlier in this post) including the system select screen posted by @Aloshi. The themes for the different systems will be similar to each other, only the logos and the box art will change. my goal is to create a very clean and uniform theme-set.