I think it needs some tweaks to make it more user-friendly and streamlined. I’ve produced a mock-up of some changes:
What do you think?
- Can switch cores without having to use “Update”.
You could always do this. Why would you need updater for that?
Movie options sent to Video/Movie. Netplay options sent to Netplay. Config file, Path sent to General options.
FFmpeg/movie/netplay should go into a different menu, ye. They’re not used enough to justify the spotlight. Config file is quite central to multi-config setups and shouldn’t be hidden away too much. (Settings -> Save RetroArch config + config swaps, fairly useful).
Then again, remember that Linux and OSX doesn’t have the Updater. The UI should still make sense even without that. Dumping a big list into the spotlight like that is very glaring to me. Also, what do you do without internet connection (which updater relies on)?
Also, I can’t justify taking time to rework Phoenix, especially when it’s purely cosmetical. I’d really like someone else to make a more “beginner friendly” frontend, or keep working on Phoenix (very unlikely). I only do basic maintenance on it these days. I mean really, if someone could replace RetroArch-Phoenix, I’d be happy. It was never designed to scale to what it is today, and it’s only a burden to maintain.
I detest working on UI code, and I don’t have the energy anymore to write “programmer GUIs” or whatever.
Since RGUI has become so robust, all we really need is some way of getting into that interface. RA-P is definitely nice to have around for the button mapping and that sort of thing, though.
Dumping a big list into the spotlight like that is very glaring to me. Also, what do you do without internet connection (which updater relies on)?
In the mock-up, Updater itself stays right where it always has been. The list that’s available is just a core selector to choose between already downloaded cores. No internet connection required. Also “architecture” and “library” columns aren’t needed. One that describes how CPU intensive the core is, and another that describes how accurate it is, would be useful. Especially to newcomers who don’t know the difference between all the different cores for the same system.
Additionally, I came across this post on /vr/:
Man, have you seen the GUI for OpenEmu? Completely wipes the floor with RetroArch, despite (in my opinion) being inferior to RetroArch. Needs some graphic designers and dedicated GUI programmers badly.
I also made a new mockup:
Added back Config file.
Also, I can’t justify taking time to rework Phoenix, especially when it’s purely cosmetical. I’d really like someone else to make a more “beginner friendly” frontend, or keep working on Phoenix (very unlikely). I only do basic maintenance on it these days. I mean really, if someone could replace RetroArch-Phoenix, I’d be happy. It was never designed to scale to what it is today, and it’s only a burden to maintain.
I detest working on UI code, and I don’t have the energy anymore to write “programmer GUIs” or whatever.
That’s perfectly reasonable. You guys are overworked as it is. There should be some new people recruited specifically to work on GUI.
RetroArch was designed to be CLI first and foremost, so it’s no surprise that OpenEmu beats it in GUI polish, and they’re only writing for a single platform, rather than 3. Besides, they’re OS X guys, so GUI polish is their bread-and-butter ;).
Personally, I always expected each platform to get its own frontend and maintainer, the way Toad King has taken such a major role in the Gamecube/Wii and Raspberry Pi ports. I’m in no position to talk, of course…
FTFY … 
Add meancoot for iOS, and CatalystG on BB. Yes, we place functionality and tech over UI/UX/whatever. Still, we’re spread really thin (me and Squarepusher) … :\
heh, I restricted it to 3 for RA-Phoenix, but yeah, writing all of the other stuff for all of the supported platforms is obviously an even larger task.
Ah, I totally forgot about meancoot for iOS. I know he did an awesome job with that one. I didn’t even know about CatalystG, though. I’m glad to hear it’s a better situation than I had thought.
Man, have you seen the GUI for OpenEmu? Completely wipes the floor with RetroArch, despite (in my opinion) being inferior to RetroArch. Needs some graphic designers and dedicated GUI programmers badly.
Those people don’t understand that clobber (part of OpenEmu) works together with us and that we share codebases and cores (well, it’s not as clear-cut as XBMC which just uses libretro cores verbatim - OpenEmu takes some of the libretro cores, modifies them a bit to have them fit into their framework and then it works as such in their framework).
Here is how I see this panning out -
Things like XBMC are going to become the ‘new frontends’ for the GUI fetishists - RetroArch just supplies a MAME OSD-like system (RGUI in this case) and that’s it - if you want more than that, have your own frontend hook around RetroArch - there are plenty of opportunities to do that.
I really don’t see anything like Qt/GTK+/Aero/whatever kind of widget thingy having a long shelf life at this point -you can see on Linux already that things like KMS are starting to gain more and more traction, and on Android/iOS/Blackberry/whatever - none of these ‘widget’ frontends would really work out or be ‘portable’ enough.
On consoles we have no choice and we often have to write our own GUI system from scratch - RGUI comes originally from the Wii port and it’s the most portable GUI system so far. The PS3 has its own ‘frontend’ - RMenu (which I’m trying to mimic now as closely to RGUI as possible) - and for Xbox 360, I use a GUI interface pre-supplied by Microsoft (XUI) - I call this one RMenu XUI. The iOS port has some kind of Cocoa interface but you can still access RGUI all the same.
The problem with all of this stuff is that it is hell to maintain and that the GUI codebases can quickly get out to date and need constant patching up whenever you decide to order something around differently. We have been spending quite a few weeks now trying to bring RMenu (PS3/Xbox 1/Xbox 360) and RGUI (Wii/Android/iOS/Blackberry/PC) closer together and still it’s a lot of manual labor everytime to ‘add’ something. You can’t really understand until you place yourself in our shoes and have to deal with this stuff.
I and others understand it is not easy work maintaining a GUI, especially when it comes to portability, which is one of RetroArch’s main strengths. That said, I do believe something eventually has to give somewhere. Maybe not now or even in the near future, but at least on the PC front, where people have higher expectations, there will eventually have to be a more user-friendly interface. I am not asking you to commit precious time and resources on this now, or even at all, for I know you guys are stretched thin as it is and have your priorities elsewhere, namely in making sure RetroArch actually works as intended. I personally can get by with Phoenix without issue, and any flaws I find with it are EASILY nothing compared to all the things it does right. But I am not most users, and I believe most users want something they can download, quickly set up, and have it running in minutes. As it is, many people don’t even know where to download the cores, because it’s not something that’s immediately obvious without reading a guide such as hunterk’s, which is not linked to in the main page or in the forums.
Don’t even know where to download the cores? On Windows it couldn’t be much simpler with Phoenix and the Updater service.
I am sorry but those people are going to have to understand that RetroArch is about being powerful, not about appealing to their weak-kneed GUI fetishes. That is why we keep saying that people who want that kind of stuff should make their own frontends.
BTW - the MAME project doesn’t give you these GUIs either - neither does MESS - neither does anything really. Frankly, it is a bit obscene to ‘expect’ us to really start offering some kind of ‘cover flow’ contraption to people when actually zero other projects are even doing that to begin with.
RGUI is more than enough in the interim.
What you and others are asking us to do - would be like asking Linus Torvalds to drop in some kind of ‘GTK/Qt alternative’ into the Linux kernel just because ‘users expect a GUI in a program these days’. It is that inappropriate and it shows that these people don’t understand the scope of our project or what its role is really - our project has zero to do with this and it’s for its own sake that it doesn’t try to even go there. RetroArch (and the libretro API by extension) lives for frontends to ‘dial into’ - it doesn’t live in a vacuum.
What you guys also don’t understand is that adding all those graphics assets would make the entire codebase into a big bloated sorry mess - again, not something we have any interest in doing.
I don’t know how many more times we are going to have to repeat ‘make your own frontends’ before this finally starts becoming clear to people - nothing is preventing you from making your own GUI wrapper around RetroArch. Just don’t expect us to start doing that - we have zero interest in it.
I also think that RGUI is enough. It was actually a dream to see it get ported to PC, because now I can make a powerful “console” with much more ease than before.
Hmm, I’ll have to admit that I was one of those who didn’t understand then. But I have to ask, why did you even make these GUIs if you have zero interest in them, and why are they included in every release?
I already answered that question for you if you had read the previous post -
On consoles we have no choice and we often have to write our own GUI system from scratch -
That doesn’t explain why you have “no choice” on consoles though. It’s just nicer for us ungrateful users to have a GUI.
On consoles, you have to create a UI, or you have a black screen to stare at. On PC you have plenty of alternatives though (frontends, CLI, RGUI-style …)
Anyways, Phoenix had its purpose once. It was necessary to have something somewhat usable on Windows, since command line on Windows is very user hostile, and I wouldn’t even use it myself (being a CLI lover).
These days it’s pretty much a glorified config tool because it’s slightly more convenient than a text editor, but that’s about it. The WIMP program model is broken for portable frontends like this, because you’re forced to use keyboard + mouse (only PC).
Not if you add rom and core to the config file. Not that I would like to use it that way, but it would work.
Not if you add rom and core to the config file. Not that I would like to use it that way, but it would work.[/quote] how do you propose we do this on consoles? do you want me to fire up a text edit program each time and edit the new ROM path in by hand?
Like this:
sd:/retroarch/cores/genplus.dol
sd:/roms/md/sonic.bin
RetroArch would only have to parse the config file and launch the game with no GUI stuff. Then to turn off, just press the power button, like you do with GameCube games. And yes, you would have to edit the config file in a text editor by hand every time you want to change core or rom, but at least it works.
However, just to make this extra clear: I do not “want” you to do this. I like RGUI and I would like to see it supported in the future, and I have never complained about it. I am just saying that you are not “forced” to make any GUI. A GUI is for ease of use, convenience and aethestics. I also find it very odd how Squarepusher can work on something almost every day and then say he doesn’t really care about it and how bad everyone is for thinking he does, and then get accusatory and almost hostile towards everyone who doesn’t fulfill the requirement of 1) knowing C++ and 2) having read every single post he’s made. I have never said or done anything to disrespect any of you or your work, I have never demanded anything, and every bug report, suggestion and feature request I have made I have done under the assumption that those involved care about it. If I have done anything that has been inappropriate it was most likely due to a misunderstanding. So yeah… If, despite all of this, I am so hated here then there’s really no reason for me to stick around, and one of the admins is free to remove my account. I could not find a way to do so myself.