Ugly text based menus for all the scripts
-
I get that retropie-config and setup, etc, all shell out and run a script or something that displays the text based menus. Is there any way around that or plans to make this either more graphic or included in ES? It seems so old fashioned, like the equivalent of having to shell out from windows to DOS on a PC and run something created as a batch file menu. And besides being unattractive, you have to switch interfaces. Instead of just highlighting an option and selecting it, you have to navigate to the select or cancel buttons and choose them.
Same with RetroArch that looks horrible compared to MAME and some of the other emulators despite them also being graphical representations of text based menus. It doesn't have to be DirectX like my PC version of RA, but it could look like MAME, no?
This isn't an insult to how the system works, just wondering why it still works this way and if there is a way or plans to change it to be a more integrated and user-friendly experience. FWIW, I have an expert level understanding of Windows and DOS, but am more of a hobbyist regarding Linux, even though I had some experience with Unix and Linux systems I supported years ago. I don't use it every day other than to tweak Retropie, so my lack of understanding could be due that.
-
it's a matter of time. who will code a better menu, that can be maintained and added to as easily? it's the sort of thing that could be looked at if everything else was done :)
plus there's a bunch of those scripted menus that are part of raspbian that if we rewrote them, we now be maintaining parts of raspbian, and have to update them every time they changed, etc. i think you could never escape those menus entirely.
@flightrisk said in Ugly text based menus for all the scripts:
Same with RetroArch that looks horrible compared to MAME and some of the other emulators despite them also being graphical representations of text based menus. It doesn't have to be DirectX like my PC version of RA, but it could look like MAME, no?
RA menus are a bit of a different thing - we could use the GLUI driver (a crisper version of the current 'green' menu) or even the XMB driver (the same one as on the PC) as they run fine on pi2/3, but all of our documentation is for the old RGUI green menus. i'm sure there's other reasons but it seems more likely that this could be revisited.
you could always change it yourself. the setting is menu_driver in /all/retroarch.cfg - change to XMB or GLUI
-
@FlightRisk We await your pull request.
-
@zerojay said in Ugly text based menus for all the scripts:
@FlightRisk We await your pull request.
I take it that was a suggestion that if I wanted those features I should code it myself? ;) I'm a Delphi and VB.NET and some C# guy, wouldn't have a clue how to develop on Linux in C++
-
@dankcushions said in Ugly text based menus for all the scripts:
you could always change it yourself. the setting is menu_driver in /all/retroarch.cfg - change to XMB or GLUI
Awesome! I will give that a try. I just can't read that green menu. I'll look for the transparency setting also since that seems to be part of the problem. Either that or it is just faint or makes it hard to read because of the checkered background. I don't need or probably want the XMB blue animated swirl version, but the GLUI version sounds like what I am looking for.
-
@flightrisk said in Ugly text based menus for all the scripts:
Instead of just highlighting an option and selecting it, you have to navigate to the select or cancel buttons and choose them.
Not on my controller - I can select an item directly (apart from within raspi-config which is not actually part of RetroPie).
The text interface is a configuration interface so it's not required to be used constantly - once you have things running how you want you don't need to use it. It doesn't need to be pretty, and it's the simplest way of doing things from within bash. There are no plans to change it (nor do I want to).
-
@buzz said in Ugly text based menus for all the scripts:
The text interface is a configuration interface so it's not required to be used constantly - once you have things running how you want you don't need to use it. It doesn't need to be pretty, and it's the simplest way of doing things from within bash. There are no plans to change it (nor do I want to).
To be fair, maybe a few things would benefit from being upgraded to a full-fledged user-friendly menu. Thinks like updating things (system, cores, themes...), installing themes, etc.
However, I understand very much how complicated and "not important" it is. -
@flightrisk said in Ugly text based menus for all the scripts:
@zerojay said in Ugly text based menus for all the scripts:
@FlightRisk We await your pull request.
I take it that was a suggestion that if I wanted those features I should code it myself? ;) I'm a Delphi and VB.NET and some C# guy, wouldn't have a clue how to develop on Linux in C++
Well, there's quite a few people in the community that have learned those kinds of skills through hacking around and trying to get something working. If you want it badly enough, you can find a way and others might be willing to help.
-
Instead of dialog/whiptail use ... what? Be more thankfull that there are "guided" menus and not only text inputs.
-
@cosmo0 said in Ugly text based menus for all the scripts:
To be fair, maybe a few things would benefit from being upgraded to a full-fledged user-friendly menu
I like the dos like look. The moment retropie starts looking like an apple product is the moment I leave the project
-
@herb_fargus It's not first of April today!
-
This discussion shows why options are preferable to suit the many different tastes, but they do require more effort in development. Thus the invitation to help creating the features requested.
As a long-time Linux user who uses GUIs as naturally as the command line, I understand both sides. A pretty design doesn't contradict functionality per se, but in reality it tends to reduce the available options, since they have to fit into the design. And prettiness lies in the eye of the beholder anyhow.
I often compare software design to cars: everyday controls are best placed on the dashboard, the rest goes under the hood. There will always be exceptions that depend on personal preferences rather than functionality, but even among car enthusiasts only a select few care about the visual design of the engine compartment. :) But I think we shouldn't shun the ones who do.
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.