Gui coding

[DarkJezter]

Well one of the things that kinda concerns me about the directions this emulator is going is that right now, we have two separate graphical frontends, and with the win32 branch I suspect there may be another around the corner (unless I'm just totally wrong about how that project's going) On top of this, there are many components that need graphical frontends, for example the debugger and the cheat code interface, heck, even the plugins.

Right now, if we want to add a feature that needs a gui, to some extent we either have to either pick a toolkit, or implement a seperate gui for each toolkit.

Either we need to make sure we have a nice clean segregation between the functional code, and frontend code to make it easy to code multiple gui's, or else we need to come up with a framework that will allow backends to create their own frontends irrespective of the toolkit used.




Just some thoughts I've had. The easiest solution is no doubt to scrape as much functionality as possible out of the frontend code and try to define some kind of guidelines for what the backend interfaces to the various frontends should look like.

Any thoughts or impressions?

[Richard42]

We've already gone through one round of discussions about this and didn't come up with any good solutions. The way that the code is organized now in the core is pretty clean - the GTK and KDE4 GUIs live in their own folders and it's easy to build with either gui or no gui support.

The design decision which completely screwed us here is the plugin-based model. I've worked on about a dozen different emulators and the N64 emus are the only one's I've seen which use plugins. They do bring advantages (you can have 3 broken video renderers instead of just 1) but the killer disadvantage is that each plugin needs to have its own configuration GUI. So supporting multiple GUIs becomes very painful, because instead of making 1 new GUI you have to make 5. Someone suggested inventing a totally new cross-platform GUI construction framework, but that's totally outside the scope of this project.

If we decide to somehow refactor the human interface on this project it will be an enormous undertaking. The only scenario that's even remotely attractive to me would be to remove all the GUI code from the core and the plugins, standardize the config files, and then write a totally separate front-end application for the human interface. We could standardize some kind of IPC interface to allow the GUI to control the running core and keep the existing functionality.

But I think the benefit/cost ratio is way too low to support this kind of massive overhaul. The only benefits that I can imagine are easier portability to other platforms, and decoupled GUI/core development. The problem with programmers is that we like to write code. After a while writing code becomes pretty straightforward and you realize that a broader challenge is allocating your time to the right features.

Over the long term, I think this project would provide the most value to our users if we A) perfected one video plugin so that it worked properly with all or nearly all the games, then B) got rid of the plugin architecture and used static libraries to build a monolithic executable (unnecessary options are bad), and then C) re-worked the GUI so that all configuration was centralized.

[Surkow]

Well one of the things that kinda concerns me about the directions this emulator is going is that right now, we have two separate graphical frontends, and with the win32 branch I suspect there may be another around the corner (unless I'm just totally wrong about how that project's going)

The most logical thing would be to just stick with the GTK+ and the Qt GUI because both toolkits are supported on Windows (and the old Mupen64 port was GTK+ based anyway).

[DarkJezter]

Well what about something like FLTK? It's perhaps the most solid as far as I've seen as far as portability goes, without the resource usage that I've seen with something like wxWidgets.

Has there been any progress on getting this emu to compile on win32?

And does anyone have any idea what toolkit was used in the osx port when it was still alive?


As far as practice goes, we should probably continue to seperate the interface from the backend, which is already done most everywhere except for the debugger as far as I know. (just checked the cheat system, nice job btw)

So, is there any merit to me peeling the gtk stuff out of the debugger, and moving it all over to the main/gui_gtk/ folder? I mean, this may not matter to portability, and it's probably not even something that most users are ever going to interact with. I'm kind of torn on the issue.

[okaygo]

I think we should only work on one plugin for each component. Also Windows will be using GTK and SDL

Edit:

After re-reading the thread Richard you already suggested what I have been thinking.

Let me go in-depth a little bit:

I believe that we should support GTK/KDE for all distributions (Windows included) also SDL. I think that focusing video work on ricevideo, blight_input, jttl_audio, and mupen64_rsp should be important as we should have all these plugins run on all the platforms too (same code).

TASers would also want the ability to have precise control over the input without a controller, this means that we should port TASInput (an open source Win32 input plugin) to SDL and GTK/KDE and complete it. If we end up scrapping plugins, there should be an option to switch between these two.

Win32 will use GTK and SDL for its initial release, and there are no intentions of changing that in the future. This means that windows builds will be significantly bigger in size, however cross compatible without many changes.

Rice Video should eventually be renamed with credits given to who deserves them, once we have extended work on it. Currently it is being chosen for our on screen display feature.

jttl audio should be given a GUI to config, and should be renamed because we have done a lot of work on this plugin. It also is the only plugin that will work with our speedup functions.

blight_input should be renamed and given a new GUI...

[okaygo]

One plugin for each component? You mean one video, one sound, one input?

That is what I mean, except with input we should eventually have 2.

[Richard42]

Well what about something like FLTK? It's perhaps the most solid as far as I've seen as far as portability goes, without the resource usage that I've seen with something like wxWidgets.
...
So, is there any merit to me peeling the gtk stuff out of the debugger, and moving it all over to the main/gui_gtk/ folder?

Okay, let's stop the GUI proliferation. Back up. What is the compelling reason for switching to Yet Another Gui Framework? The target platforms for this project are 32-bit and 64-bit Linux. Are we searching for the One GUI To Rule Them All? I don't think we'll ever find this.

I think it would be a good choice if you moved the GTK code out of the debugger folder and into the gtk_gui folder, assuming that the debugger is not too tightly tied to the GUI. It would require some work to design and build the interface between the functional and GUI code, but from a design standpoint it would be better.

One plugin for each component? You mean one video, one sound, one input?

The only component for which we currently have more than one plugin is video, and the only reason we have more than 1 is that none of them work with all the games.

[DarkJezter]

Alright, sounds like I got some work cut out for me then. I agree with you about moving the gtk code, and I'll make that a priority before I start fleshing out any extensions or enhancements to the debugger.

In the mean time, since refactoring the debugger will no doubt take me some time, I think we should include the present version in the trunk. Just to get it out there and at least make it available in the mean time.

[nmn]

Over the long term, I think this project would provide the most value to our users if we A) perfected one video plug in so that it worked properly with all or nearly all the games, then B) got rid of the plug in architecture and used static libraries to build a monolithic executable (unnecessary options are bad), and then C) re-worked the GUI so that all configuration was centralized.

The more I think about it the better it sounds. At first I opposed this, but If we were able to do everything all other plug ins could do with our branch of Rice Video and JttL's SDL Audio, we could make plug ins irrelevant (as long as we somehow re-merged Direct X support with Rice Video for building on Windows, but Windows is somewhat irrelavant too at this point)

Honestly though, there are a few things to think about. Like z64 and Jabo. Jabo's DirectX 8 plugin is definitally very much an improvement over Rice on some things, and it would take a very long time to come to where it has. (Likely in PJ64 1.7 it will be arguably the best N64 Video Plugin if it isn't in the beta releases.) z64 was possibly the first and probably the best low level plugin, solving the major problems like those in Mario Tennis (Though some more minor ones do remain, other plugins have fixed them and it is definitally possible to fix them in z64, albiet not easily.)

Perhaps it would be better if we integrated JttL Audio, the RSP, and blight input into the emulator when they reach the proper point of maturity, and we can leave in Video modularity? Unless we surpass Jabo and implement LLE Video i think merging plugins into the emulator would be suicide. And of course there are other things to think about (TAS Input Plugin, for example.)

[MasterPhW]

The more I think about it the better it sounds. At first I opposed this, but If we were able to do everything all other plug ins could do with our branch of Rice Video and JttL's SDL Audio, we could make plug ins irrelevant (as long as we somehow re-merged Direct X support with Rice Video for building on Windows, but Windows is somewhat irrelavant too at this point)

Honestly though, there are a few things to think about. Like z64 and Jabo. Jabo's DirectX 8 plugin is definitally very much an improvement over Rice on some things, and it would take a very long time to come to where it has. (Likely in PJ64 1.7 it will be arguably the best N64 Video Plugin if it isn't in the beta releases.) z64 was possibly the first and probably the best low level plugin, solving the major problems like those in Mario Tennis (Though some more minor ones do remain, other plugins have fixed them and it is definitally possible to fix them in z64, albiet not easily.)

Perhaps it would be better if we integrated JttL Audio, the RSP, and blight input into the emulator when they reach the proper point of maturity, and we can leave in Video modularity? Unless we surpass Jabo and implement LLE Video i think merging plugins into the emulator would be suicide. And of course there are other things to think about (TAS Input Plugin, for example.)

Do you really think dropping down the plugin architecture is a good point? I think it's sometimes great to have a very compatible emulator with all build in (perfect example is SSF or PSXemulator) but I think it would require a lot of work to recode an emu with plugin architecture to a build in system.