Favorites for EmulationStation

ruckage

@sokiee said in Favorites for EmulationStation:

what i meant is add support for font awesome ( with all the glyphs included ) then you can let people not only customise the icon ( choosing any glyph ) but then you can also customise it as a font ( size, color ecc )

Yeah, but picking from a selection of pre-defined glyphs isn't enough. I would want to draw my own icons to match my theme, as would many other themers.

sokiee

@ruckage said in Favorites for EmulationStation:

@sokiee said in Favorites for EmulationStation:

what i meant is add support for font awesome ( with all the glyphs included ) then you can let people not only customise the icon ( choosing any glyph ) but then you can also customise it as a font ( size, color ecc )

Yeah, but picking from a selection of pre-defined glyphs isn't enough. I would want to draw my own icons to match my theme, as would many other themers.

Then yes, I agree adding support for icon would be better then ( and probably easier too )

Chillimonster

Been following this thread and was thinking (and forgive me if its been covered already), could the 'favourite' not be highlighted by a colour change fro the fame name, say from white to green?

This would mean that no additional formatting issues would arise with different themes etc.

sokiee

@Chillimonster said in Favorites for EmulationStation:

Been following this thread and was thinking (and forgive me if its been covered already), could the 'favourite' not be highlighted by a colour change fro the fame name, say from white to green?

This would mean that no additional formatting issues would arise with different themes etc.

Yes, but what if people don't like green? what if they want it red because it matches their red theme :P
It's better if it's customisable.

ruckage

@sokiee said in Favorites for EmulationStation:

@Chillimonster said in Favorites for EmulationStation:

Been following this thread and was thinking (and forgive me if its been covered already), could the 'favourite' not be highlighted by a colour change fro the fame name, say from white to green?

This would mean that no additional formatting issues would arise with different themes etc.

Yes, but what if people don't like green? what if they want it red because it matches their red theme :P
It's better if it's customisable.

I imagine if used it would be implemented in the same way as folders, it would have separate tags to define 'selector bar' color and 'font' colour for favourites. However this is a bit of a limited approach and as with folders currently how would you know that the different colour signified the game as a favourite? Icons in some form are a far better idea as it's much clearer.

Chillimonster

@sokiee True, but if customisable it can be made to match a theme

@ruckage I was thinking more to do with the lack of intrusion in various themes rather than the colours, or even Itallics or Underlining. Just spit-balling ideas really :-)

Zigurana

@ruckage
Do you have any idea how many glyphs are included in this particular set? Which one in particular are you missing?
The one thing that using a font has going for it is that the implementation is a lot easier to accomplish.
My proposal would be to start with the star hard-coded (as in the initial implementation for recalbox).
After this, we could allow it to be a themable element, from the FA set.
If then there is still a need, we could consider heavily modifying the GUITextListComponent to create some sort of hybrid list that includes both images and text.

Zigurana

@ruckage said in Favorites for EmulationStation:

@sokiee said in Favorites for EmulationStation:

@Chillimonster said in Favorites for EmulationStation:

Been following this thread and was thinking (and forgive me if its been covered already), could the 'favourite' not be highlighted by a colour change fro the fame name, say from white to green?

This would mean that no additional formatting issues would arise with different themes etc.

Yes, but what if people don't like green? what if they want it red because it matches their red theme :P
It's better if it's customisable.

I imagine if used it would be implemented in the same way as folders, it would have separate tags to define 'selector bar' color and 'font' colour for favourites. However this is a bit of a limited approach and as with folders currently how would you know that the different colour signified the game as a favourite? Icons in some form are a far better idea as it's much clearer.

This is actually not difficult to implement at alk, we already have 'primary' and 'secondary' colors values for the gamelist element (which should really be called 'file' and 'folder', as that is what they are used for anyways).

Adding more colors is a 15 min job, but that strategy only works for a limited number of modifiers. Ie: how many could you really expect a user to remember? Also, what about favorite folders?

pjft

@Zigurana If we use a standard font set for the star, regardless of the theme font, I am supportive of that for now. Feels fairly small and self-contained, and wouldn't require themers to develop their own fonts.

We can later on add more to it if someone feels brave enough.

sokiee

@Zigurana said in Favorites for EmulationStation:

Also, what about favorite folders?

I really think the current implementation is fine, that is no favourites on folders. If you filter by favourites, you look inside folders if they have at least 1 element matching the filter ( which is how we both implemented it ).

TMNTturtlguy

@pjft @Zigurana I don't want to be difficult because you guys are awesome in building all of this for us, but what happens when i want to use the comic book "pow" symbol as my star system? Right now I can use any image i want and as long as i name them correctly they will work instead of a star. By making the symbol a font, i can no longer use any image i want, but have to choose from a selection of characters? I might be missing something here?

sokiee

@TMNTturtlguy said in Favorites for EmulationStation:

@pjft @Zigurana I don't want to be difficult because you guys are awesome in building all of this for us, but what happens when i want to use the comic book "pow" symbol as my star system? Right now I can use any image i want and as long as i name them correctly they will work instead of a star. By making the symbol a font, i can no longer use any image i want, but have to choose from a selection of characters? I might be missing something here?

afaik it's gonna be:
step1: implement favourites with a star icon. no themeing support, but a lot of people asked for this
step2:implement either a font glyph system or icon and themeing support for it ( maybe including alignment, position, ecc )

pjft

Correct.

Otherwise it'd be like not ever having implemented Videos in ES because we couldn't get them to have good performance on the Pi. Or not implementing videos in gamelists because we didn't have them in the SystemView as well. Or not implementing filters because we don't yet have the right data architecture behind it (will it be SQLite? Something else? Still under discussion) :)

In fact, there are a few things being discussed here that are worthy of breaking down - even though, to be fair, I'm just watching from the sidelines. A reasonable, task-driven approach to making something like this happen could be (these are not necessarily sequential or ranked by anything other than what comes to mind):

Step 1: adding favorites metadata and labels.
Step 1a: adding basic theme support (to give feature parity with ES Kids). This means adding a metadata icon, just that - it's not theming the gamelist.
Step 1b: Optional, as a separate PR potentially, adding some sort of visual cue in the gamelist for favorite games. Something that works, not something that is the end-all-be-all of these solutions. Colors, stars, whatever.
Step 1c: Optional, as a separate PR potentially, integrating with sorting and filtering.
Step 2: figure out if/how we'd want to theme the gamelist. And then someone does it, they way they feel responds to the needs of theme makers, to their own preferences, and ultimately in a way that's achievable and manageable. :)

This way it's a practical approach to bring small, but meaningful improvements out to the community, and make these relevant - but sometimes hard to get closure on - architectural and design discussions to block only the actual things that they affect.

So, a proper answer - unless @Zigurana, @sokiee or someone else who'd like to take this on think differently and already have a proper solution in mind - is: "in the short term you wouldn't be able to use a custom image for that purpose (as you currently can't), but it is certainly under consideration for the roadmap" :)

Zigurana

@TMNTturtlguy
I think it's good to discriminate between a single separated element/icon that can be themed to be whatever, and the element that could be added to the gamelist itself (which scrolls with the game names), which I (for now at least) propose to be a text symbol.

We can have both of those solutions be present at the same time.

ruckage

@Zigurana said in Favorites for EmulationStation:

@ruckage
Do you have any idea how many glyphs are included in this particular set? Which one in particular are you missing?
The one thing that using a font has going for it is that the implementation is a lot easier to accomplish.
My proposal would be to start with the star hard-coded (as in the initial implementation for recalbox).
After this, we could allow it to be a themable element, from the FA set.
If then there is still a need, we could consider heavily modifying the GUITextListComponent to create some sort of hybrid list that includes both images and text.

No need to be combative, I assumed you would want the opinion of those who are making the themes. I'm well aware of how many glyphs are included - doesn't change the fact the symbols I want are not included. I've taken great care to make a theme with a specific visual style so I wouldn't want to be forced to use something that just didn't match up. Other themers may disagree but I think my concerns are valid.

I would much prefer just a metadata icon that could be displayed like the rating icons.

pjft

@TMNTturtlguy and @ruckage Thanks for the comments, and definitely be sure that the more information the better, so that whatever decision is taken, it'll be taken with a good idea of the choices and consequences, as well as the effort and return.

I think @Zigurana last comment might actually have been more relevant then.

In the ES-Kids mode, there is a metadata icon, just like the ratings icon, that can be displayed. It's perfectly configurable per theme!

It is not, however, shown in the gamelist.

@ruckage What exactly would you be thinking about here, just so everybody's on the same page? I thought it was the latter (gamelist), but your comment now seems to suggest that the former is what you were looking for?

For some reason all images I've found lead to broken URLs, but there was a nice heard and teddy-bear icon that @Zigurana had in the themes.

Syhles

@Zigurana
Maybe you should take it to a vote with as many themers as possible, I feel that normal end users could care less if it was text vs icon. Where as the themers most certainly care which of the two routes are taken, also I understand @pjft thought process of not wanting to do 12 things at the same time, wanting things to be implemented piecemeal.

All in all I think you should take it a vote with themers on text vs icon, but we aren't the ones coding so it ultimately falls into your hands on how things are implemented. Though I feel that if we're going the text route vs the icon route just because of ease of coding and implementation that it isn't necessarily the route we should be going.

I understand the merit of both routes, I just feel that the text route is the less accessable easy route, were as the icon route is more flexible for themeing but harder implementation route.

Yet again I have no experience coding so alot of this may be way off target regarding the coding aspect, but as a themer these are my opinions on the matter.

ruckage

@pjft Thanks for the reply.

I do honestly think having an icon in the gamelist is a pretty good idea for easy visibility (you can see I went to extra trouble in my theme to do something similar to add the folder icon on my nes theme).
However if that meant I lost control over the look I would prefer to just have the single metadata icon (like the rating icons) that I can theme myself.

Es can already be quite restrictive regarding theming so I think making sure future additions give us the freedom to theme them how we like is important.

cafarellidigital

Hi all, I've been following this font discussion closely, and it's been really insightful. I'd like to offer a suggestion that I think is a compromise for all.

The basic issue here seems to be that it is much easier to implement favorite icons as a font than as a PNG/svg image, but then the icons can't be easily changed as per the theme's desire.

I would suggest using a font, but allow that font to be changed to any font the themer desires (just like any other text in ES). The font we use as a default can be laid out as such...

A = Folder icon
B = Favorite icon
C = Kid Friendly icon
etc...

Then if a themer wants different icons, they just take the default font, modify the icons per letter, save out the new font, and use it in the theme.xml instead of the default one provided.

I used to do some font modifications, and it's really not that difficult, once you have the tools. If you'd like, I'd love to lend a hand in creating a couple of fonts with icons instead of letters for you this week.

I think this is the best solution, since it satisfies the ability to change the icons however you please, while also keeping it a font, which seems to be the ideal method.

Thoughts?

pjft

@cafarellidigital I suspect that could be an option, but I believe the angle I'm hearing is that it'd be hard to color it differently to the actual text in the gamelist line? Though I may certainly not have the full context here - I am far from a themer.

@Syhles Your comment is certainly fair, and just to make sure I'm being clear: I suppose it's not as much about taking the sub-optimal route because it's easy, but it's more about delivering something that's useful right now, and later on flesh it out further, rather than keeping everyone waiting for this for long. As you mention, normal users likely won't care, so if we can get them something earlier, and then later deliver on the full-fledged solution, that's usually always better than delivering on everything for everyone later :)

The two cents of someone who's just watching and supporting wherever he can.