Last Played Collection - Possible to limit?

mediamogul

@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.

mediamogul

@pjft

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?

Alturis

@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. ;)

mediamogul

@alturis

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.

pjft

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 :)

mediamogul

@pjft

All very sober considerations.

pjft

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.

darknior

Thanks a lot, really good idea :)

Alturis

@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

@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!

mediamogul

@pjft

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.

Alturis

@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?

mediamogul

@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.

mitu

@mediamogul Are you using the emulationstation-dev package, because otherwise you'll be updating from the stable branch, whereas the modification has been committed to the master branch.

mediamogul

@mitu

Ah, good to know. Thanks.

hiulit

Wow, that was quick! Thanks @pjft :D!!

mediamogul

@pjft

Everything seems to be working well. From a user experience point of view, the list now definitely feels less cumbersome and more manageable. However, your first instinct to include 100 items may have been more appropriate, as 50 bottoms out a lot faster than I would have thought. The best number for this is always going to be subjective, but it'll be interesting to hear a consensus after more people have had a chance to try it. Fantastic work!

pjft

@mediamogul thanks for testing. I'd definitely be interested in hearing others' thoughts after a week or so of use, and then we can certainly adjust.

I have another fix for ES to keep me busy before lr-fuse, so it'll still be easy to change if needed.

Best.

cyperghost

@pjft Wow nice add-on
I vote for 100 items as default.

Clyde

I'm amazed what an idea plus some collaboration can accomplice. I love such communities like this one. :)