EmulationStation Fork?
-
@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.
-
@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...
-
@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
-
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!)
-
@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.
-
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 :)
-
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.
-
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. -
@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.
-
@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.
-
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,
-
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.
-
@pcal what did you do specifically?
-
@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
-
Could you explain this in English? I don't speak code
-
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.
-
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.
-
@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
-
@pcal Another way to work around this is to use PSX2PSP files:
-
Thanks for the replies everyone
@pcal that's the main reason we removed bin as an extension from psx. Just a diff way of filtering.
Right. Which totally makes sense.
I just wanted to take it a step further, giving myself the option to keep each game in a subfolder on disk while having them appear at the top level in the ES menus
Another way to work around this is to use PSX2PSP files:
Ah, that's an interesting trick, didn't think of that.
You can submit your case on the RetroPie github fork of emulationstation for discussion
Ok. Let me clean up my change and I'll try to get a pull request submitted this weekend.
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.