Testers Wanted: GameListView Theming Refactoring

TMNTturtlguy

@Zigurana where are you at with backward compatibility? The more I keep reading on this, I still see your descriptions stating things that either will be required to be updated to work, or things like features tags that will be phased out. I am concerned that there are a ton of themes out there, and not all of them are actively managed. Then there are some of our themes that support a huge number of systems. My ComicBook theme has 4 versions (due to current issue with themeing that you may be resolving), each of my versions has 116 systems and each systems theme.xml has unique properties so a lot of changes cannot be handled by a find replace all tool.

Anyways to keep on topic, in my opinion it is important we support legacy themes, otherwise a lot of content may be lost. Thanks

Zigurana

@tmntturtlguy, thanks for sharing your concerns, let me try to put them to rest.

I would never even consider breaking support for our archive of existing themes, as I consider that to be one of our greatest assets.
The proposed changes are not meant to break any existing themes. If that's the case, I would consider that a bug that needs fixing before we commit it to the master branch.
The legacy GameListView types ('basic', 'detailed', 'video') will still be listed. The difference is that they will be generated by a single generalized method, as opposed to three hard-coded ones.
I've kept these hardcoded ones in place for ease of testing, but they should be essentially the same thing.

Rest assured that this activity is meant to reduce the amount of work for themers, not increase it. For instance, it will no longer be necessary to create separate 4:3 and 19:9 themes, while 90% of their assets are the same. Now, you could just create another view within the same theme, and reuse these assets. That saves you from having to maintain multiple copies of a very similar theme.
Similarly, you can supply presets for color variations, without the end-user having to go and edit the xml themselves.

In terms of functional improvements, these changes allow you a much more fine-grained control over what Metadata elements you want to include to the different views or not, rather than the current all (detailed) or nothing (basic).

Regarding phasing out the 'supported-feature' tag (and the 'extra' tag while we're at it), these are workarounds to have ES play nice with themes that contain more elements than expected. If I get my way, ES will just ignore the tags it does not recognize (instead of failing to parse the theme altogether). Thus, we do not need these workarounds any longer.

In that sense I am not planning to retain backwards compatibility for people using older versions of ES with newer themes. I think those folks should just update their ES.

If there is an issue with newer versions of ES which prevent them from updating, then that issue should be addressed separately. But we should not bend over backwards to accommodate older ESes.

I hope that this clears things up for you, thank you for bringing this up.

Zigurana

@pjft that is really just a brainstorm item, where I tried to tie in this new possibility of many views with the filter functionality. Basically letting the themer set a filter for the user.

Then we could show all games of a certain genre, with a view relevant to that genre.

Would be even better if we would have free text filtering on game-titles...

pjft

@zigurana Got it.

Sounds interesting, though then those themes would start from a collection of "all games" and filter them out, is that it?

I can certainly see that for non-free text filters. As for free-text filters, it starts being a can of worms - "Mega Man", "Megaman", etc. - but I think there might be something there to explore. On the other hand, with custom collections, we might solve that in a way that doesn't necessarily explicitly tie the view to the data. But we'll see!

We can certainly add free-text filtering on game titles at a later stage - I have just avoided doing anything that requires a physical keyboard for the user to use so far :)

Thanks!

Zigurana

@pjft quite, very much in the brainstorm domain for sure!

Zigurana

@jdrassa said in Testers Wanted: GameListView Theming Refactoring:

The showSnapshot options for video do not work. This appears to be due to the fact that the image is never being set on the VideoComponent.

Looked at this yesterday and tonight, and the issue is not straightforward to solve.
The way I understand it: Rather than setting a single value, the VideoComponent needs to use two game-dependent values: the video-path and thumbnail path. This is also the reason why the setValue() method is not being used in the current VideoGameListView, but instead two calls are made: mVideo->setVideo(video_path), and mVideo->setImage(thumbnail_path);

Currently, the VideoComponent class is the only one with this behavior, the other GuiComponent subclasses can suffice with a single call to SetValue() to update the content based on the currently selected game.

Now to solve this, there are a couple of solutions:

make an exception for the VideoComponent while populating its values (hacky)
change all the implementations of SetValue to take the full metadata, rather than just a single string (muchos effort).
leave as is, and create an ImageComponent as well as a VideoComponent when we encounter md_video in the theme. (simplify videocomponent + thumbnail member becomes obsolete?)

Personally I don't use videoviews, and I am unsure of the difference between the games image and its thumbnail (I guess the thumbnail is a still from the movie?). I'd like some feedback on this, and if people have other suggestions.

pjft

I like the simplicity and option 3 is probably the best - even if in the worst case themes would need to explicitly add an image element under the video.

Unless we would make the video component contain an image component as well? Would that be an elegant solution?

Or what else could we think of?

Zigurana

@pjft said in Testers Wanted: GameListView Theming Refactoring:

Unless we would make the video component contain an image component as well? Would that be an elegant solution?

That is the current design, a single component, where we need to somehow set two values with a single SetValue() call.
I'll think about it some more. See if I can make it work.

pjft

@zigurana but is the problem that we need to set to values with a single call, or is it more that each new object you're defining is meant to have a single "value"?

I was interpreting it to be the latter.

If that's not the case, then we could think of options to make it happen in an elegant manner.

A12C4

Any update on this ? I haven't commented here yet but I'm following this since the beggining and would love to see it happen.

Zigurana

Sadly, this has been put on hold for the time being.

A12C4

@Zigurana If you want, maybe I can take a look when my job on the grid view will be "finished". I start to understand well this part of the code base.