EmulationStation Fork?

[ben_thatmustbeme]

@herb_fargus grid launcher? Similar to a Wii home screen menu type of thing?

[herb_fargus]

@ben_thatmustbeme yeah or like kodi. Instead of a list the boxart is what you choose. I have a C++ developer friend who said he may look at ES after he finishes a few other projects so we'll see if that comes to fruition

Was in the original plans but never happened: https://github.com/Aloshi/EmulationStation/issues/234

[ben_thatmustbeme]

@herb_fargus That would me cool. Honestly its looking more and more like I am just going to try forking it first and then see if others want to join. I haven't worked in C++ in a while so its a good refresher for me.

[dankcushions]

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

@dankcushions I would certainly like to work with it, but I have not been able to get their code working, they introduced a lot of warnings and there have not been that many fixes added yet.

The fact that there are several forks is a good sign, its just a matter of bringing all those people together in one project with someone actually leading it.

[dankcushions]

@ben_thatmustbeme said in EmulationStation Fork?:

@dankcushions I would certainly like to work with it, but I have not been able to get their code working, they introduced a lot of warnings and there have not been that many fixes added yet.

The fact that there are several forks is a good sign, its just a matter of bringing all those people together in one project with someone actually leading it.

that was the intention of herdinger's fork, though :) apparently it's not that easy... good luck!

[Zigurana]

Yeah, I've created another fork in the past as well, and right now I am really looking for a ES-Addicts Anonymous talk/therapy group. ;-)

The mental investment in trying to understand the structure of it all is certainly non-negligible.

I mean, I have spend so much time into trying to wrap my head around all the layers that Aloshi introduced that it really has become a dark maze of inter-dependencies. And because I never got a proper toolchain up and running, debugging is a real pain in the @$$. So even fixing small issues takes hours to figure out.

I was hoping for the herdinger fork to pick up the reigns, but it too seems to have come to a halt. I seems like a cool project from afar, but when you stick your nose into the code, that initial enthusiasm is quickly tempered. So maybe its just the honeymoon period that has passed, lets see.

And when the Retropie team starts to look actively into ES alternatives, that does not really help to get that spark back either... I understand the reasons to hedge their bets, as they cannot remain dependent on a dead component for much longer.

So, by all means count me in! I am fully - as the poker players say - "pot committed" at this point.

To focus the project a bit more, you/we could consider a fork that focuses on Rpi (or Retropie) specific development. Currently the ES project is aimed to be platform independent, which is not always aligned with what we need it to be for usage on the pi.

[ben_thatmustbeme]

@Zigurana I'm with you on the project being pie focused. I am starting from a fork on retropie's fork. I'm working on getting Travis-ci working for the build testing but it seems to be having a problem with a few of the dependencies (going to have to go through their support team).

Anyway, documenting is certainly going to be a part of it. I plan to build a class hierarchy to help clear some of it up. I ran AStyle already on the codebase, so it looks a bit cleaner too (I'm a bit of a code cleanliness freak).

Let's get a list of known bugs together that effect rpie as well as some feature requests.
Check out github.com/dissolve/EStation3

[meleu]

@ben_thatmustbeme
about two months ago, before I understand the RetroPie's development workflow/goals, I did some feature requests here:
https://retropie.org.uk/forum/topic/177/emulationstation-feature-requests-here/

As @Zigurana alerted me, perhaps the RetroPie forum isn't the best place to keep such list. If you think the list has good feature requests, I would be happy to transfer it to "issues" section on your github repository.

BTW, I'm not a C++ programmer, but I think that we have 2 features that can be easy to implemment:

1. An "ignore the conflicts" for the Scraper. This way, I can scrap my entire romset and don't interrupt the process to decide what to do with the conflicts.
   [OBS.: there's a better way to scrap games sselph scraper, described here: https://github.com/RetroPie/RetroPie-Setup/wiki/scraper but it's console based and it would be great to see it on ES. Maybe an ES wrapper to sselph scraper is a doable thing.]
2. A simple way to choose the input for player 1, 2, 3 and 4. Maybe you can borrow some code/get inspiration from here.

[A Former User]

Yeah, I'd really like that custom sorting option. I don't think it needs to be in the UI; just make it so that the order in which the games appear in the gameslist.xml is the order in which they are displayed (just like the systems in es_systems.cfg).

[ben_thatmustbeme]

@SirDrexl @meleu @herb_fargus

Do these capture all your requests thus far?
https://github.com/dissolve/PieStation/issues

Also, better name now, more RP focused up front

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