Grid tile content (image, text, or more ...)

[lilbud]

@a12c4 Looks good to me. But will there be a way to control the numbers of rows and columns?

[EctoOne]

@lilbud good question actually. i assumed that the numbers where defined by the grid size so that it adapts to various screen resolutions.

[A12C4]

@ectoone

The proposition looks easy enough to me, although I have some questions: What are <backgroundColorCenter> and <backgroundColorEdge> exactly doing? Is that some kind of gradient or is <backgroundColorEdge> supposed to be some kind of tile border?

<backgroundColorEdge> is the tile border, not a gradiant, but you can still insert a gradiant manually in the image you use as the tile background. I need to try it out, but it shouldn't render badly due to the way the background is resized (the background image is splitted in 9 part so the corners don't get distorted and the borders are only distorted on one axis, only the center is completly distorted but should be hidden by the game image). As I said I need to try it out to be sure.

Point is, (no offense) just because something doesn't make sense to you, somebody might be able to make something nice out of it if he/she has the option to try it out. So don't take away (simple?) things. :)

I still have to make design choices somehow, and not supporting a feature which have no use case allow lighter and easier to maintain code. That's why I wanted to open the debate to more people and created this post on the forum, so I can have more feedback and maybe reconsider some design points due to new informations.

[A12C4]

@lilbud This is where the fun begin, I hope you like maths :)

The number of rows and columns depend on the grid size, its margin, and the default grid tile max size.

The formula is the following :
GRID_SIZE = COLUMNS * TILE_SIZE + (COLUMNS - 1) * MARGIN
(same formula for the rows, note the "COLUMNS - 1" as we always have one less margin than column)

Let's say you want a grid which take 80% of the screen, and 4 columns and rows.

The grid size will be 0.80 0.80 and we have 4 columns, this leave us with the following formula :
0.80 = 4 * TILE_SIZE + 3 * MARGIN

We want to add small margin so the tiles are not too close to each others, let's say 0.03

So if I take back last formula and replace the margin with its value, this give us :
0.80 = 4 * TILE_SIZE + 3 * 0.03
<=> 4 * TILE_SIZE = 0.80 - 3 * 0.03
<=> 4 * TILE_SIZE = 0.71
<=> TILE_SIZE = 0.1775

I hope you like it, this is @jdrassa idea :)

EDIT : Also note that this is just the tile size, the image will adapt to the tile size (minus the padding) but keep it aspect ratio, and the background fit the image size (plus the padding). I will post a screenshot of it later today so you can better see what I'm taking about.

[jdrassa]

@a12c4 said in The Grid View need your opinion:

For example, adding md_title to all the view will break all the available theme, because to be consistent with other metadata, the md_title will be shown if the theme don't specify it position to offscreen.

md_title could be added to other views without breaking any existing themes. The key to preventing it from effecting existing themes would be to specify a default position in the code that is already off screen.

[lilbud]

@jdrassa said in The Grid View need your opinion:

md_title could be added to other views

Do it. Seriously a lot of themes could benefit from it.

[A12C4]

@jdrassa Which would bring inconsistent behavior as it's the only metadata positioned offscreen by default.

Not that this is a big deal by itself, but the code related to the game views is already so fcked up, I would prefer not adding another thin layer of complexity to something that is already a giant mess.

While a unique and modular game view would solve both this problems (messy code and different metadata) at the same time.

EDIT : What about md_marquee ? What about md_image ? Should we really spend time duplicating code all around instead of refactoring as this should have been done a long time ago ? I don't think so and I don't want to do that, if you want to, then go ahead and do it, but I don't support that.

[A12C4]

@lilbud

https://github.com/Koerty/es-theme-material

Wasn't the background color of the selected tile blue before ? Maybe it changed because I use different default values.

https://github.com/Koerty/es-theme-moderntv

This one look super bad because you set the path of the background to :

<path>/home/pi/RetroPie/splashscreens/modern/bg.png</path>

This is an absolute path and I don't have the image. Unless I missed something and the image is installed somehow with your theme, you should add the image to the git repository and set the image path with a relative path.

[lilbud]

@a12c4 You gotta add your own image. I designed the theme so that any image can be used, but the user has to supply the image.

[A12C4]

@lilbud Then from where the image you used in your screenshots come from ? The blue and orange image with sky buildings

I want to compare to see if there is any difference.

[lilbud]

@a12c4

[A12C4]

@lilbud Thank you a lot !

Original for comparison

My version

So, as expected, the game title isn't here because not implemented yet.

Beside that, on the original image, is the "white space" under the selected tile something you wanted to do on purpose ? Or was it just the space where the text, which is hidden, belong.

Because right now I'm centering the background with the image, so if people want to do something like that, with one of the side of the selector bigger than the others, they can't.

EDIT : I'm not sure but I think the tiles are slightly bigger in my case, I need to check something.

[jdrassa]

I give a bit more importance to keeping it simple for the user over keeping it simple for the developers.

Someone said this recently in an unrelated PR and I think it applies here as well. A little bit of code duplication would simplify things for users and theme developers.

@a12c4 said in The Grid View need your opinion:

While a unique and modular game view would solve both this problems (messy code and different metadata) at the same time.

This is true, but there is no guarantee this will happen anytime soon. When video support for first added, there was discussion about adding md_marquee to detailed view. The reason we didn't at the time was because their was discussion about overhauling the game view that would fix this "right way". Nothing ever came of it and support for md_marquee was never added to detailed view.

@a12c4 said in The Grid View need your opinion:

EDIT : What about md_marquee ? What about md_image ?

Ideally we should have consistent metadata available to all views.

@a12c4 said in The Grid View need your opinion:

Should we really spend time duplicating code all around instead of refactoring as this should have been done a long time ago ? I don't think so and I don't want to do that, if you want to, then go ahead and do it, but I don't support that.

Look I was not saying that you had to implement md_name support in all views, I was just pointing out that it was possible to do so without breaking existing themes. That being said, your statement about why you don't want to do it, could apply to the grid view in general. There was a bunch of code duplication involved. Maybe you should have held off until everything was refactored into the perfect solution. Maybe we should have rejected some of your PRs for the same reasoning. You didn't and we didn't. This just seems like a wierd arbitrary point to decide to draw the line.

[lilbud]

@a12c4 said in The Grid View need your opinion:

Beside that, on the original image, is the "white space" under the selected tile something you wanted to do on purpose ?

I honestly don't remember, its easily been years since I worked on this theme, or with gridview at all.

[A12C4]

@jdrassa

Someone said this recently in an unrelated PR and I think it applies here as well. A little bit of code duplication would simplify things for users and theme developers.

Ahahahah nicely seen. You won that point ;)

Look I was not saying that you had to implement md_name support in all views, I was just pointing out that it was possible to do so without breaking existing themes. That being said, your statement about why you don't want to do it, could apply to the grid view in general. There was a bunch of code duplication involved. Maybe you should have held off until everything was refactored into the perfect solution. Maybe we should have rejected some of your PRs for the same reasoning. You didn't and we didn't. This just seems like a wierd arbitrary point to decide to draw the line.

I have 3 things to say about this.

Firstly, I will do it for the md_name since it's on my way, but here I wasn't only talking about the md_name, but all metadata elements. Because if I start to do it for the md_name, I'm 200% sure someone will ask why I didn't do the same for the others.

Secondly, yes I had to duplicate a lot of code for the grid view (all the detailed view metadata stuff), and I didn't like it, but I did it because at that time I didn't know well enough the game view code back then to start a big refactoring which would have just lead me into a wall, and the grid view would have never happened. Now, things are different.

Ultimately, I'm doing this on my free time, I'm not being paid for doing that, so nobody should be able to order me to do something I don't want to. I do it because I have fun programing complex stuff and learning, if it can help the RetroPie community along the way, then it's even better, but I won't prioritize the second over the first.

I don't like this last argument, but well, you triggered me with the "Maybe we should have rejected some of your PRs for the same reasoning" and " This just seems like a wierd arbitrary point to decide to draw the line." ahahahah

[A12C4]

Ok I added a scrollDirection parameter to the theming syntax, where its value is vertical by default, but can be set to horizontal if needed.

Was kinda easy to do actually.

[jdrassa]

@a12c4 said in The Grid View need your opinion:

Ultimately, I'm doing this on my free time, I'm not being paid for doing that, so nobody should be able to order me to do something I don't want to. I do it because I have fun programing complex stuff and learning, if it can help the RetroPie community along the way, then it's even better, but I won't prioritize the second over the first.
I don't like this last argument, but well, you triggered me with the "Maybe we should have rejected some of your PRs for the same reasoning" and " This just seems like a wierd arbitrary point to decide to draw the line." ahahahah

No worries. I recognize we all are contributing in our free time. Hopefully, I didn't trigger you too much. I was a bit worried it may come across as harsh, which wasn't my intent. I appreciate the effort that you have put into this and especially the effort to break things down into smaller chunks which definately helps with reviews and testing.

[A12C4]

@jdrassa No problem, let's keep moving ahead together.

If I can't figure out, in a reasonable amount of time, how to properly refactor the game views into one single, modular game view, then I will add all the missing metadata elements to all the views.

But for now, please let me try my solution first.

I don't like to stupidly copy/paste stuff around, I feel like a bad IT student who just discovered stackoverflow.

[A12C4]

@jdrassa Btw, what's @BuZz policy for stable and master branches ? We are getting close to the version 1 of the grid view, so I wanted to know how I can plan ahead.

[jdrassa]

@a12c4 I wouldn't presume to speak for Buzz, but my understanding is that he will move changes to stable when he determines them to be stable. The stable/master split is a relatively new thing, and came about after a few contributions required fixes shortly after being accepted.

That being said, I would expect grid view to live on the master branch for a while before being moved to the stable.