I personally don't think adding a large new UI to the core program is a good idea. I would actually suggest something very different:
Add a lightweight socket-like API to Dolphin that effectively lets you remote-control the software once launched. This API allows you to get/set config elements, get a list of available games, their paths, icons, etc, and most importantly launch games.
This would allow two things:
(1) Another computer, mobile device, something else, can control Dolphin and/or make queries to Dolphin over a network.
(2) A local program can control Dolphin, acting as its UI. This means anyone can write a new UI or integrate an existing one (such as XBMC/Kodi) without having to mess with the core application, as long as they follow the API spec.
Perhaps Dolphin could have an argument that launches it "headless mode", so a launcher or other UI won't have to contend with the QT window, effectively running it as a service.
While some of the above can be achieved using launch arguments, they are unwieldy and require odd work-arounds depending on the usage (such as in Steam), and don't let you have simple access to config or the list of available games that Dolphin knows about in its path.
Sounds like a good idea but then you run in to the same problem of how to make a good "pause" screen within the game's window/context.
I'm not sure if that's possible but how about writing this "big picture" UI as a overlay to be drawn on top of what Dolphin is rendering (like Steam/Origin/Uplay overlays)?
(08-03-2016, 09:43 AM)Jhonn Wrote: [ -> ]I'm not sure if that's possible but how about writing this "big picture" UI as a overlay to be drawn on top of what Dolphin is rendering (like Steam/Origin/Uplay overlays)?
It should be the UI when you open it up but have a background. If you have a game running the background is just the game, perhaps?
To be an overlay, the UI has to be rendered within the same process, and in the same context too.
Steam actually injects a DLL into games which hooks the end of frame commands of whatever opengl/directx context it's using and draws in the overlay (such a DLL could communicate over a pipe or socket with the main process).
If you are going to make a GUI especially for Dolphin, then embedding it inside Dolphin itself is the way to go.
However, the inverse option is available too, where you modify Dolphin to run as a DLL/Library within another process (say one implementing the retroarch API) that is the launcher. These modifications are less than trivial, as Dolphin is a little fussy about how the contexts are setup, and other memory management/exceptions issues.
About Big Picture Mode ... maybe instead of writing some kind of UI just speak with the guy who created ICE and implement something similar in Dolphin to work OOTB? Just an option to automatically add game shortcuts to Steam?
https://github.com/scottrice/Ice
I'm using this ICE stuff - it added my Wii/GC games, those are available in Steam Big Picture - I can run games from there using my XBox ONE Controller, stop them and so on.
Would be nice if Dolphin could configure itself into Steam without 3rd party software
"To be an overlay, the UI has to be rendered within the same process, and in the same context too."
Then wouldn't the most useful and flexible enhancement for Dolphin be a hook/socket/something that it exposes that can be used as a render target or output of another UI? While I am an experienced programmer, it is entirely with data and business logic, so I've no idea if this is a sane suggestion, but it seems like it should be possible?
"If you are going to make a GUI especially for Dolphin, then embedding it inside Dolphin itself is the way to go."
This seems the opposite of best-practice design/programming. Making it easy for 3rd party UIs to hook into Dolphin, then writing a default big-picture UI that uses it, seems like the best bet.
(09-16-2016, 08:41 PM)Durandle Wrote: [ -> ]"If you are going to make a GUI especially for Dolphin, then embedding it inside Dolphin itself is the way to go."
This seems the opposite of best-practice design/programming. Making it easy for 3rd party UIs to hook into Dolphin, then writing a default big-picture UI that uses it, seems like the best bet.
Not inside Dolphin's source code, but the GUI code need to be embedded into the same processes as Dolphin, somehow. Some kind of scripting interface, or dll loading.
There are basically two options:
A) Dolphin is built as a dll and embedded into a program that does the GUI. This is how RetroArch and friends work, but dolphin is currently incompatible with this technique.
B) The GUI is built as a dll (or a script) and embedded into dolphin. This is how things like the steam overlay are usually implemented.
Personally, I'm in favor of a scripting interface that is powerful enough to partially or fully replace the default Dolphin GUI.