EmulationStation Fork?

meleu

@ben_thatmustbeme
Good to see a person excited to implement improvements in emulationstation specific for RetroPie. :-)

When your fork is ready for use, I think it'll deserve an install module at the experimental packages in RetroPie Setup.

I would be glad to install, test and give feedback.

Botolo

Hi there, I'm not a coder but I'm quite good in testing things and breaking them apart to understand how they works.
I'm interested in contributing how I can in this discussion and in planning the feature of the retropie frontend, because now it seems a dead end.

Emulation Station for what I can see seems too much complex and I'd say in a non useful way and the theming system doesn't seem easy to evolve in something more elastic, in order to open the way to new kind of layouts. That's my impression, but as a wrote I'm not a coder.
If you want to try to continue with ES I'm willing to follow the lead and do my part, as small it can be.
Just point me to the fork of your choice :)

Attract Mode can be very fancy for a cabinet project, but in my experience it can be a pita with huge romsets. It may be need a more tight roadmap and a bigger team to became an excellent frontend.

Retroarch/Lakka adopted a interesting minimal strategy and I guess it can be a good starting point for a full kodi like frontend. Now the preview/snap system il very limited and not so nice to see.

Meh Station sounds promising, but it's a one man project and it can have the same limitations as Attract Mode.

I didn't know about Phoenix but it seems aimed for a desktop/keyboard system and I am somehow worried about the QT libraries.

Zigurana

@dankcushions said in EmulationStation Fork?:

@ben_thatmustbeme don't create ANOTHER es fork:) that herdinger fork in the the thread already has some fixes, enchantments and possibly a future. I suggest helping that one.

@ben_thatmustbeme : I would like to stress this as well. There are many people with good intentions, but are you really able and committed to deliver long term stable support for the ES-of-the-future? If there is even a small trace of doubt in your mind, I would suggest joining an the Herdinger fork and help there. (Maybe even get a formal role to look after RetroPie specifics, who knows?)
That way you/we have at least 'some' embedding in an existing project, people to brainstorm with and a common goal.
The last thing RetroPie needs right now is another ES-dud.
See also this.
As you can see from this topic, and other initiaves from the last year or so, there is some willingness from the RetroPie community to help out, but there is probably not enough to sustain a functional development team. Teaming up with an existing fork really is the only feasible way forward. We'll just need to safeguard the Rpi specifics 'from within'.

I hope I do not seem too overly pessimistic, but I really want to see this succeed.

Zigurana

@Botolo
You make some good points, but you forgot to mention the one big advantage of ES: its mature.
Sure, its a mess and theming needs a big overhaul but there are many more people using ES than any of the newcomers (attractmode excepted maybe? ).
Looking at the amount of forks for ES alone and the continuous stream of issue and PRs submitted to the original repo, its undeniable that ES still has a great amount of momentum. It really would be a shame to let that go to waste and start from nearly scratch again.

Then again, as I said up-thread, I'm fully pot-committed, so my observation bias should be taken into account as well...

ben_thatmustbeme

@Zigurana the only this is that there no active forks at all of ES right now. Herdinger's fork hadn't had a commit in a month and those were very few, it's not what I would call active development at all.

Also, it's git. It's a little confusing of a forked project vs a fork in git. They are really all still trying to continue ES but without any central repo as Aloshi never gave anyone else commit access. As a result, people are almost trying to do it independently and failing. This is why actual forks of projects start. A change in name gives a new effective namespace. The project needs to not be just another emulationstation or else no one knows why it's different than any other. The difference between me and Aloshi, Herdinger, etc is I WANT to give out git access o anyone else committed to the project. Including those other guys when they get time. That's how projects live past one person.

Also I know that xkcd well. It comes up a lot at the w3c

dankcushions

@ben_thatmustbeme

Herdinger's fork hadn't had a commit in a month and those were very few, it's not what I would call active development at all.

i think that describes almost every git emulation project i follow! they're still working on it: https://github.com/Aloshi/EmulationStation/issues/563#issuecomment-229388606

The difference between me and Aloshi, Herdinger, etc is I WANT to give out git access o anyone else committed to the project.

sorry but herdinger's project has more than one maintainer. they're not limiting access. they asked for your help above.

(i don't really care what ES fork people work on - all work is good!)

Zigurana

@ben_thatmustbeme : Its good to see that at least you have given these things some thought.

Some remarks though: I do not think that a single month of inactivity means that the project is inactive, and I would urge you contact the Herdinger ppl to see if there is room for a common way forward.

I have no real opinion as to switching to a new project name or not. there are advantages and disadvantages. You gain a fresh start, but lose recognizability.

Botolo

I know ES is mature and is probably the only real option to grow, for the moment at least.
That's why I think it's important to choose one project/fork/clone and keep an official focus on it.

I'm new here so I don't pretend to suggest anything. I don't know you, how you work and how good are you. It's simply not my place to say anything about what has been done so far.

I'm simply willing to help whatever the majority choose to do :)

ben_thatmustbeme

Yes Herdinger has said he is still interested but does not have time right now. To me, that equates to no active leadership to a project. Herdinger is also saying that they need unit tests as first priority, which is a good thing to add, but not really how you get new people interested in a project.

Don't get me wrong, I am reviewing every difference between Herdinger branch and my own. And bringing in any of them that don't break on the pie. There are some good additions in there and it's a pretty easy task to merge changes between them.

As far as project stewardship i'd certainly be happy to keep it under retropie's control. I think that makes a lot of sense for centralization and long term maintainability. But let's start out externally and see if we can maintain a stable level before suggesting anything like that. Note that a name change is a matter of a single text document. I forked from retropie's code base, so it would be trivial to make a PR to a branch under that.

Honestly, there is no reason to not have multiple forks, especially since I am going to focus mainly on retropie. Retropie's version has already diverged from Herdinger's in a few ways before I start changing anything. Herdinger can deal with the extra work of maintaining on multiple os's, by focusing on pie, a small dev team becomes realistic for maintaining a project.

ZombieRobot

I'm keen to help in any way i can.
I don't have any programming skills but have a background in coding skins for kodi and i'm sure i can handle some bug testing if a fork gets off the ground again and would love to see some more flexibility in the theming department mainly the ability to add a second or third image in relation to the current focused game (See Here) fingers crossed we can getsome momentum behind this awesome project again.

herb_fargus

@ben_thatmustbeme just remember that RetroPie can also be installed on a Linux pc so it would be useful to maintain compatibility with both platforms.

ben_thatmustbeme

@herb_fargus certainly. That won't be an issue. Especially since my home machine is Gentoo Linux and that's where all my development will really happen.

Keigan

If anything, can we lose the white bar on the systems select menu? When theming it's the most annoying part considering you cannot remove it and have to try and implement into the design.

Also when using the slide option, instead of getting to the far right and having it go left to the start, can it endlessly loop around?

And allowing more images and such in the gameslist, for screen shots, etc. This is also for theming if people care to use it.

Those would be things I'd like to see, but if you change the whole thing, and have the grid, option, etc these likely won't even be an issue.

Thanks,

pcal

Hi. Sorry to necro the thread but I'm also interested in the future of EmulationStation development. I recently made a fork to add a small enhancement that I wanted:

https://github.com/pcal43/EmulationStation

I'd be interested in contributing this and other fixes but it doesn't really seem like there's a place for them to go.

lilbud

@pcal what did you do specifically?

suprjami

@pcal: aiui we're accepting well-tested PRs which do not add/change major functionality against https://github.com/RetroPie/EmulationStation

This is more of a stable/maintenance branch for RetroPie than any sort of forward-thinking development branch

Unless someone steps up and truly takes over ES development, compiles all the little mods out there into one stable tree, and stewards the project and its community moving forward, major ES changes are unlikely to occur

@lilbud look at the changelog:

https://github.com/pcal43/EmulationStation/commit/a9e801c6ff53559f29e86bd2128d24a677d284f2

lilbud

Could you explain this in English? I don't speak code

suprjami

@lilbud

add support for 'collapsing' games that live in their own directory

I guess that if a game is like:

roms/psx/Castlevania SotN/Castlevania SotN.bin
roms/psx/Castlevania SotN/Castlevania SotN.cue

Then you can collapse it down to just have one neat menu entry for that game, instead of having to go into the directory and then launch the game.

pcal

Then you can collapse it down to just have one neat menu entry for that game, instead of having to go into the directory and then launch the game.

Yes, exactly.

Some of those PSX games have lots of files (20+) and merging them into an .iso doesn't always work. I really don't like tossing all of those files from different games in the same directory. I guess I'm kind of OCD about stuff like this. :)

Anyway. So, yes, an extremely minor change. :) But I'm happy to clean it up and submit it to the RetroPie branch if there's interest.

herb_fargus

@pcal that's the main reason we removed bin as an extension from psx. Just a diff way of filtering. You can submit your case on the RetroPie github fork of emulationstation for discussion