Last Played Collection - Possible to limit?
-
FYI, just setting
<playcount>
to0
is enough to make a game dissapear from the Last played collection. No need to remove the<lastplayed>
tag. -
Well I found where the code change would need to go.
CollectionSystemManager.cpp
void CollectionSystemManager::populateAutoCollection(CollectionSystemData* sysData)
Just needs something like this at the end - need to read some code to figure out the right FileData collection class syntax
if ( sysDecl.type == AUTO_LAST_PLAYED ) { rootFolder->remove( max( rootFolder->count - 50, 0 ) ); }
Edit: changed min to max
-
@alturis The idea is good, in concept, but that can only be applied if - and after - it has been sorted by last played time.
Edit: after I looked at the code I see that that particular location would already be sorted.
I'd also need to make sure to update the "update" function to keep that number straight.
I'll look through that, and I'll fix it at 100.
Edit 2: for reference, it'd be here:
https://github.com/RetroPie/EmulationStation/blob/master/es-app/src/CollectionSystemManager.cpp#L280
-
@pjft Nice! Does this mean that it will be added to EmulationStarion at some point? Also, could the number be edited by the user?
Anyway, it's been fun playing with my script :P I'll release it anyway when I finish it, at least for learning purposes. -
@hiulit "At some point", yes.
Edited by user, no. As I said, I don't want to perpetuate a growing trend of adding yet another option to ES.
If anyone strongly objects to 100 and/or feels as a wide community that there is a consensual number that makes more sense, I can consider making that the default. But if everyone has different opinions, I'll quote Jim Barksdale:
"If we have data, let’s look at data. If all we have are opinions, let’s go with mine."
-
@pjft I wasn't trying to put any pressure, at all, btw ;)
And about the number, I think it might be a little too high. Maybe 25? But that's just a personal choice, of course. I'm fine with whatever number you decide :) -
@pjft said in Last Played Collection - Possible to limit?:
If anyone strongly objects to 100 and/or feels as a wide community that there is a consensual number that makes more sense
Personally, I think 100 has a nice, rounded feel to it. At first blush, 50 seems like more than enough, but if there is to be no setting, and I fully understand the aversion to adding one, 100 covers more ground and should please the most people.
-
Out of curiosity, is it bad practice to have a back-end only setting. Like say having the cutoff be 100 by default, but adjustable from
es_settings.cfg
? -
@mediamogul said in Last Played Collection - Possible to limit?:
Out of curiosity, is it bad practice to have a back-end only setting. Like say having the cutoff be 100 by default, but adjustable from es_settings.cfg?
That was my thought as well. Make it 100 unless someone cares enough to edit it in the cfg
I already feel bad for bringing it up and adding work to @pjft's plate. ;)
-
I don't think it ever hurts to discuss these things. Ideally, after talking through it, we should really open up a ticket on the github referencing this thread. From there, it'll be considered alongside everything else based on merit and the interest to see it resolved.
-
Not at all, and apologies if my answers seem a bit more rushed - time hasn't been abundant here, especially during the day.
I was looking into this right now, but I see that I fell into the old trap of believing that this had an easy solution, and that @Alturis 's suggestion would indeed work out of the box :)
Alas that's not to be, that would work partially if rootFolder was indeed a vector or something similar, but it's not. It's alright, we'll figure something out. I'll run with 50, as there seemed to be a reasonable preference for that number and it's still a few page scrolls.
In regards to the back-end only setting, I don't think there's any specific guidance or preference in that regard. There are a few guiding principles I try - or tend - to adhere to, but I'm not dogmatic about them.
My vision/perspective for ES is that it should be accessible and should not require someone to jump through hoops to make things run as intended. So that's check #1.
Second. options that rely on users to edit something manually can be error prone and result in situations that may break beyond your control. Think of a simple thing such as the frequent complaints that a new system isn't showing up because someone has a customized es_systems.cfg file. In this case, what if someone decides to make it a negative number? Zero? A number that's larger than the actual accepted integer range? A letter?
I know, one can claim that that possibility is already there because the options are a text file, but since we aren't in any way encouraging that use case, if someone mucks it up it's really purely their responsibility. From the moment we open that to others, it just becomes... meh.
The final check is that, if it's an option that will indeed be used by many, then it should be a visible option, otherwise it just reflects some sort of lack of decisiveness/thought process. "The Power of Defaults" is a good reading on that, and sometimes I feel that an excessive number of options stems from poor judgement or laziness - I have certainly been a key culprit of adding a lot of options when I was doing both the OMX Player work as well as the Collections one that these days, in hindsight, I probably wouldn't have added. The fact that some people may use them doesn't mean that they would be worse off with a different one by default, but the overall user experience in the end suffers as well as the code readability. Think of all the ES options that you probably never touched or left at their default settings. The comfort of knowing that things could be changed likely doesn't offset the pain that someone has in creating them, maintaining them, and keeping the menus from becoming a giant mess. :)
This case in particular is a fairly small thing - pick a number, any number. We'll start with 50, as it is the number most of you seem to gravitate towards, and then we'll run it for a while. If we feel it's too small, we'll change it.
Also, I doubt Buzz and the other folks would be happy with such a back-end option :)
-
All very sober considerations.
-
Here you go:
https://github.com/RetroPie/EmulationStation/pull/383
If anyone does want to test it out for bugs and such, I'd certainly appreciate a second pair of hands/eyes on it.
Best.
-
Thanks a lot, really good idea :)
-
@pjft wouldnt you just expose a new public method of FileData that manipulates the mChildren table to remove X elements from the end?
Simiar to the sort function itself?
void FileData::sort(ComparisonFunction& comparator, bool ascending) { std::stable_sort(mChildren.begin(), mChildren.end(), comparator); for(auto it = mChildren.cbegin(); it != mChildren.cend(); it++) { if((*it)->getChildren().size() > 0) (*it)->sort(comparator, ascending); } if(!ascending) std::reverse(mChildren.begin(), mChildren.end()); } void FileData::remove( int rmvCount )
-
@alturis said in Last Played Collection - Possible to limit?:
@pjft wouldnt you just expose a new public method of FileData that manipulates the mChildren table to remove X elements from the end?
Simiar to the sort function itself?
Nevermind. Looks like you already took care of this. Missed that. Thank you!
-
Holy hannah that was fast! Well done, sir. It seems as though it's about to be accepted too. I look forward to testing it.
-
@mediamogul said in Last Played Collection - Possible to limit?:
It seems as though it's about to be accepted too
It has been. I imagine if you update from sources it would be there now?
-
@alturis said in Last Played Collection - Possible to limit?:
I imagine if you update from sources it would be there now?
I updated from source about 45 minutes after the commit went through and still had over 800 games in the list. I'll try it again tomorrow.
-
@mediamogul Are you using the
emulationstation-dev
package, because otherwise you'll be updating from thestable
branch, whereas the modification has been committed to themaster
branch.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.