For sample, Open file, Open BIOS, Select BIOS, Save/load state, etc.
There is a $130 open bounty on this issue. Add to the bounty at Bountysource.
We should probably separate the Desktop GUI from the emulator code and use an approach similar to what mupen64plus does: http://m64py.sourceforge.net/
That way we'd have a unified code path for all platforms and don't introduce big dependencies in case we don't need a GUI.
Yes, it's possible too ^^
I'm always in more "integrated" things than just a front end (So that you can actually pause and change settings during run time). Most of the user friendly things can't be done yet though (save states don't exist, input is only keyboard for windows)
That doesn't conflict with the python-gui approach. You can actually call c functions from python and vicd versa. I was already looking into doing something like that, but stumbled over a bug in my SDL2. I see if I can work around that.
Well, that could work then. (Keep in mind python is a very foreign and pita to setup thing for windows users, though)
Well, there are things like pyexe which turn python programs into exe files that are runnable without python installed. The m64py people even have a Windows portable build for download, so has to be a way to make it user friendly. I'll look at the code and get in touch with them eventually.
We should think about separating the current platform-specific user-interface stuff (loading settings, creating a render surface, and sorts) from the core reicast code, so that we can turn the latter into a shared library that both the current UI and the future GUI can access.
That way, a user can simply install reicast and if he/she later decides that a GUI is required, it can be installed afterwards, but you don't have to compile and keep a second copy of the core reicast stuff. This mainly affects linux - windows users usually expect a GUI (and the display server is installed anyway), so if we had a GUI, I think we should always include it in the windows version.
I've got a basic Python GUI working now, which does not integrate with reicast just yet, but the concept seems to work. After the GUI is created, I get the HWND/XWindowID of one of the widgets and pass it to some C code that creates an SDL2 window with OpenGL 3.1 support from it and draws a black background on it. Works fine as far as i can see.

That GUI is currently written in Tkinter (Tk/Tcl), since that is part of the python standard library. wxPython might be prettier and look much more native, but that can be done later.
I'm currently working on the reicast infrastructure part. As I said, I'd like to make reicast a shared library that my glue code can use to call stuff like dc_init(), dc_run() etc.
I'll use #832 as a base for that, since I need SDL2 (SDL1 does not have support for the OpenGL 3.1 core profile).
It works!
Code isn't quite ready for merging yet, but it does work.

Id really like this im not knowledgeable enough to configure everything without a gui lol
@Holzhaus any progress on this? Would be nice to have an MR no matter the state, so people can improve it
I guess https://github.com/reicast/reicast-emulator/compare/holzhaus/gui ? Will review later on. Also #1150 for follow up
I hope to solve the issue with no bug for Windows 10 (x64)
I would also keep the GUI separated from the core like @Holzhaus mentioned.
However I'm not sure if using Python would be a good idea as the rest of the code is C(++).
It would be C(++) for the core, Java for Android and Python for the Desktop GUI. We should leave Python out of the equation (my opinion).
What toolkit should be used for the GUI? I'm currently experimenting with Qt which would be available to Linux and Windows (not sure about Mac).
http://doc.qt.io/qt-5/supported-platforms.html?hsLang=en
@dmiller423 mentioned already starting to work on a Qt interface, too.
@flyinghead I think you should claim this now that the imgui UI has been added
Done. Just need this issue to be closed.
Most helpful comment
It works!
Code isn't quite ready for merging yet, but it does work.