Qt / KDE GUI Thread

[Tillin9]

Well, to be honest I think the current mupen64plus build system is not too nice It would never ever survive a port to windows for example, and I think OS X is doubtful also. I started hacking on a cmake-based system, it builds most things already. blight_input is a little... hairy though at the moment, it needs a few fixes.

Moving the build scripts to cmake or autotools would be much appreciated.

Using uic the .ui is converted to a header. You do need to do setupUi somewhere, you can either hide this inside a subclass or do it explicitly. If you use cmake and kde cmake instructions QToolBar, QMenuBar etc. will automatically be converted in the ui file to use their KDE equivalents.

Hm... I looked at http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KActions and this is my idea of manually. Basically only the KActions are in XML. I see no big advantage of having the properties in the code itself or in resource file for such a small piece of the UI. If having it in XML is more proper, obviously that's the way to go. However, there is no loading of widgets from a .ui then overloading them to have different properties (what I most wanted to avoid). I attached the initial .ui for the mockup I took a screenshot on the first page. Maybe the KDE3 .uis were a lot more inclusive?

Right, they should be installed somewhere where they can be found using generic approaches. Also take a look at the Qt resource system that embeds files in the executable

Again, the example uses code, not the .ui to do this. Hence I'd consider it manual. KDevelop Designer had no option for that, and tried to embed the icons in the .ui.

http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows
http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X
KDE4 is compatible with the freedesktop.org icon spec that was established during the KDE3 series.

Nice to know about all of this! I'll try installing my KDE3 iconset on my KDE4 setup.

How am I supposed to comment on this?

Just my (and a few others I know) opinion. I know I'll end up putting off actually using KDE4 full time until I can make it look > 95% similar to my KDE3 setup.

Ug... Attachments don't seem to work. I put the .ui here: http://sknauert.web.wesleyan.edu/Mupen64Qt.ui

 

[Slougi]

Moving the build scripts to cmake or autotools would be much appreciated.

Expect a patch soon.

Hm... I looked at http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KActions and this is my idea of manually. Basically only the KActions are in XML.

Right, what else should be in the xml?

I see no big advantage of having the properties in the code itself or in resource file for such a small piece of the UI. If having it in XML is more proper, obviously that's the way to go. However, there is no loading of widgets from a .ui then overloading them to have different properties (what I most wanted to avoid).

I'm sorry but I don't understand what you just said

I attached the initial .ui for the mockup I took a screenshot on the first page.

That's a qt3 ui file all right.

Maybe the KDE3 .uis were a lot more inclusive?

yep

Just my (and a few others I know) opinion. I know I'll end up putting off actually using KDE4 full time until I can make it look > 95% similar to my KDE3 setup.

I don't know... I think it looks rather decent. See here for various shots of the svn trunk.

 

[Tillin9]

Okay... I think I found the issue. When I was taught, the procedure was:

1) Design all UI elements in designer.
2) Have 5 lines of code that load the resource file for most things.
3) Only use code in the UI for overloading and redefining (for corner cases, or dynamic content, i.e. to make things not possible in designer).
4) Implement signals and slots.

I think Qt4 changed this paradigm to what I consider manual, i.e. make most of the UI elements in code. Hence, when I say manual and you say use KDE4, we're agreeing.

Anyway... thanks for working on porting to cmake. Also this discussion makes me more confident that my previous all designer approach is not going to fly. It's just going to take a little work than I thought since I have to actually write code, compile, test, etc. as opposed to point and click.

As far KDE4, it doesn't really matter what it looks like. If I wasn't so used to Keramik on KDE3, I probably won't mind so much. I'm just unhappy since I feel there always should be a make everything look like the previous release option. Anyway... this isn't the right place for requesting classic KDE4 themes.

 

[Richard42]

Well, to be honest I think the current mupen64plus build system is not too nice It would never ever survive a port to windows for example, and I think OS X is doubtful also.

If you think this is bad you should go back and check out the original Mupen64 makefiles. The build system that we have right now has the advantages of being simple, easy to maintain, and well-supported. Right now we are only targeting the Linux platform, so having a cross-platform make system is not desirable - it only removes the advantages of the existing system without giving anything in return. NMN is working on a Win32 port, but it could take some time. You should coordinate with him on the cmake build system if you are serious about adding this.

 

[Slougi]

If you think this is bad you should go back and check out the original Mupen64 makefiles. The build system that we have right now has the advantages of being simple, easy to maintain, and well-supported. Right now we are only targeting the Linux platform, so having a cross-platform make system is not desirable - it only removes the advantages of the existing system without giving anything in return. NMN is working on a Win32 port, but it could take some time. You should coordinate with him on the cmake build system if you are serious about adding this.

Heh, I already have a working patch that just needs some cleaning up. I also have most of a KDE4 gui, not counting plugins yet...

In any case, switching to cmake should make the win32 actually easier to do.

 

[ebenblues]

Heh, I already have a working patch that just needs some cleaning up. I also have most of a KDE4 gui, not counting plugins yet...

In any case, switching to cmake should make the win32 actually easier to do.

Thanks for the work you're doing. I look forward to seeing the patch. I'm not so much concerned with cross-platform support (although this will become an issue in the future when we do want to port mupen64plus), but I think our current build system is weak when it comes to dependency checking. We've had a few threads where people are running into build or runtime problems due to missing dependencies. Also, if you want to install to a different prefix, you have to specify that prefix both during build and during install which isn't convenient for the user.

When the patch is ready, the best way to submit it is via our issue tracking system:

http://code.google.com/p/mupen64plus/issues/list

I believe you can attach the patch as a file when you create a new issue.

 

[Richard42]

I tried an svn checkout but it seems your repo is unresponsive/broken.

Comcast is having a massive network outage right now affecting 7 states. I can only access about 50% of the websites that I frequent. Oddly enough, emutalk is one that I can access. So unless you're on the correct side of the network breakage, you won't be able to hit my SVN server. I called them and they said that it should be fixed today. I want my $$ back.

 

[Slougi]

It doesn't actually work yet because none of the plugins are ported, but it runs and communicates correctly with the emulator core Built by the cmake build system.

Once the subversion repo is back up I'll clean up what I have and submit patches. I'll probably submit three patches:

1. A preliminary patch that cleans up some things cmake doesn't like
2. The actual cmake stuff
3. The KDE4 interface
4. If I have the time, patches for the plugins

Now, the fourth point is the interesting one. How do you rationally support both toolkits in the same plugin? Maybe a better approach would be that the plugins themselves only use X/GLX/SDL. Separate configurators (either stand-alone binaries or plugins) would do the configuration. That way you leave the door open for separate CLI, GTK, KDE, <insert UI of choice> binaries that share the same plugins.

 

[Richard42]

Once the subversion repo is back up I'll clean up what I have and submit patches. I'll probably submit three patches:

The connectivity problem is resolved now. You should be able to access the svn repository again.

Now, the fourth point is the interesting one. How do you rationally support both toolkits in the same plugin? Maybe a better approach would be that the plugins themselves only use X/GLX/SDL. Separate configurators (either stand-alone binaries or plugins) would do the configuration. That way you leave the door open for separate CLI, GTK, KDE, <insert UI of choice> binaries that share the same plugins.

Plugins for the plugins? That's a good solution but would take a lot of work to build the interfaces and make it run perfectly. If someone wants to work on this, speak up and we'll make a branch and add an issue report to track it.

 

[nmn]

Plugins for the plugins? That's a good solution but would take a lot of work to build the interfaces and make it run perfectly. If someone wants to work on this, speak up and we'll make a branch and add an issue report to track it.

Actually, How about a unified API for configuration GUIs?

 

[Slougi]

Some more progress, the rom browser works now:

What's the preferred way to land patches?

Actually, How about a unified API for configuration GUIs?

Hmm. Do you have something in mind?

 

[Richard42]

What's the preferred way to land patches?

There are a couple of different ways we can handle this depending upon how much further work you anticipate doing for Mupen64Plus. If you have the time and the motivation to continue working with us on this project, you can PM me with your email address and a username/password, and I'll set you up in the SVN server and the Google Code site. But if you're planning to move on to other things, then it would be best to open issue reports for enhancements on the Google Code issue tracker and attach the patches there. Either way, these are pretty major changes (the QT4 gui may be fairly self-contained but replacing the build system is a big change) so they should go into branches until thoroughly tested and verified. Let me know what the base revision was for the patches so that I can name the branches accordingly.

 

[Slougi]

There are a couple of different ways we can handle this depending upon how much further work you anticipate doing for Mupen64Plus. If you have the time and the motivation to continue working with us on this project, you can PM me with your email address and a username/password, and I'll set you up in the SVN server and the Google Code site. But if you're planning to move on to other things, then it would be best to open issue reports for enhancements on the Google Code issue tracker and attach the patches there. Either way, these are pretty major changes (the QT4 gui may be fairly self-contained but replacing the build system is a big change) so they should go into branches until thoroughly tested and verified. Let me know what the base revision was for the patches so that I can name the branches accordingly.

Well, if the KDE4 gui meets with general approval I'm prepared to maintain at least that aspect (along with the cmake stuff). The cmake build system does need some more love, although it was a pretty straight-forward port. glide64 and blight_input don't currently build, but I don't know of any other regressions.

Sending PM.

 

[nmn]

BTW, That KDE GUI is totally pwnsome! I love the filter feature you showcase.

Anyways, by unified API, i'd say like, you could do things like

std::string filters[5] = {"Normal","2x","4x","Hq2x","Hq4x"};

dialog = NewDialog("Some Video Plugin", 200, 500);

tab1 = AddTab("General");
tab2 = AddTab("Misc");
tab3 = AddTab("Another Tab ;)");

AddNewSliderOption(tab1, "Brightness", 0, 100, &brightness);
AddNewListboxOption(tab1, "Texture Enhacement", 5, filters, &filter);
AddNewRadioOption(tab1, "Radio Option 1a", 1, &radiochoice1);
AddNewRadioOption(tab1, "Radio Option 1b", 1, &radiochoice1);
AddNewRadioOption(tab1, "Radio Option 1c", 1, &radiochoice1);
 AddNewRadioOption(tab1, "Radio Option 2a", 1, &radiochoice1);
 AddNewRadioOption(tab1, "Radio Option 2b", 1, &radiochoice1);

AddNewSliderOption(tab2, "Stupidity Value", 0, 100, &stupid);
AddNewListboxOption(tab2, "Running out of Ideas", 5, filters, &filter);
AddNewCheckOption(tab2, "Vsync", &vsync);

 AddNewLabel(tab3, "Its not all that great of an API...");
  AddNewLabel(tab3, "It needs more features and such...");
  AddNewLabel(tab3, "But it wouldn't be too hard to implement would it?");

​

 

[Richard42]

Anyways, by unified API, i'd say like, you could do things like

That idea had occurred to me as well. The problem with it is that it would take a very large amount of work to implement and you still wouldn't be able to have really native-looking GUIs. Unless you made it exremely full-featured, in which case it would take a massive amount of work.

If you really want to have all these different native-looking GUIs, I think it would be cleaner to standardize the config file protocol for Mupen64 and all the plugins, then make the core app and plugins all console-only. Pull out all the GUI code from the emulator and write GUI front-ends for each system. The front-ends could query the emulator for certain things like a game list, and modify the config files for mupen64 and the plugins for configuration. This would be so much cleaner than throwing all of this GUI code into the emulator and plugins where it doesn't belong. Instead of having one huge monolithic application, you'd have 1+N different projects. Many of the cross-platform issues would go away.

 

[nmn]

That idea had occurred to me as well. The problem with it is that it would take a very large amount of work to implement and you still wouldn't be able to have really native-looking GUIs. Unless you made it exremely full-featured, in which case it would take a massive amount of work.

If you really want to have all these different native-looking GUIs, I think it would be cleaner to standardize the config file protocol for Mupen64 and all the plugins, then make the core app and plugins all console-only. Pull out all the GUI code from the emulator and write GUI front-ends for each system. The front-ends could query the emulator for certain things like a game list, and modify the config files for mupen64 and the plugins for configuration. This would be so much cleaner than throwing all of this GUI code into the emulator and plugins where it doesn't belong. Instead of having one huge monolithic application, you'd have 1+N different projects. Many of the cross-platform issues would go away.

Wouldn't that make porting plugins harder? No longer could one use a plugin from other emulators... The unified GUI idea was meant to be a small WxWindows type library. I don't see why It couldn't look native - I mean honestly, Does the current Rice Video GUI look native at all? All this would do is stack widgets the way the GUI library is normally used to stack widgets (In GTK they would be stacked in Vboxes, with equal space, in Qt, they'd be spaced vertically apart from each other...)

 

[Richard42]

Wouldn't that make porting plugins harder? No longer could one use a plugin from other emulators... The unified GUI idea was meant to be a small WxWindows type library. I don't see why It couldn't look native - I mean honestly, Does the current Rice Video GUI look native at all? All this would do is stack widgets the way the GUI library is normally used to stack widgets (In GTK they would be stacked in Vboxes, with equal space, in Qt, they'd be spaced vertically apart from each other...)

The plugins will be hard to port regardless of which direction we go, but the plugin code itself will be easier with my proposal - we only need to standardize the config file format, which may not take any work at all if it's as simple as "key=value". The different GUI projects would have to add their own config interfaces, though, but they could proceed independently of each other as separate projects and the core emulator development and bug fixing wouldn't be slowed down..

Can WxWindows read dialog configurations from text data? If so maybe we should just switch to Wx and dump all the gtk/qt/win32 gui stuff.

Edit: I've been thinking lately that Mupen64Plus looks more and more like a complete package and less like a core + bunch of plugins. We already slightly extended the link-level API and integrated the build and install of the plugins. It seems unlikely that we'll suddenly stumble apon a better audio, video, input, or rsp plugin than what we already have, so I wouldn't be too worried about porting additional plugins. Personally I would rather stick with what we already have (which is pretty good), and work to add features and improve these instead of branching out into more plugins.

 

[Slougi]

Well, the kde gui and cmake work just landed in svn

I don't really like the toolkit wrapper idea for a few reasons:

1. It will be difficult to implement. It might look simple but oh woe the hidden pitfalls...
2. Different UI guidelines on different platforms. If that approach is taken it will make sure that the GUI will almost certainly look out of place wherever you go.
3. Limited API. No way to take advantage of platform-specific things.

Perhaps it would be better to factor out the gui code from the plugins as in the main app and make that a compile time option as well. In general I'd like to see the core become more of a library that doesn't write config files etc. It would instead call into the UI to do that.

 

[Slougi]

Can WxWindows read dialog configurations from text data? If so maybe we should just switch to Wx and dump all the gtk/qt/win32 gui stuff.

Qt at least can do this.

 

[ebenblues]

In general I'd like to see the core become more of a library that doesn't write config files etc. It would instead call into the UI to do that.

We've recently been discussing an approach similar to this. See this thread:

http://www.emutalk.net/showthread.php?t=43763

I'm also in favor of the emulator core becoming a portable api or commandline interface. This abstracts the emulator from the frontend and, if done well, can also abstract the emulator from the platform. As noted in the thread above, mupen64 is already structured in this way, but it's not formalized. One example is the SDL, VCR, lirc calls in r4300/interupt.c. Ideally, calls to those functions should not be hard-coded into the core code, but rather the core api should provide a way for the frontend code to register functions to be called on every VI interrupt. This way, higher level functionality like VCR, shortcut keys, lirc, etc is removed from the core code.

This might just be semantics, but in this model I think of the code that interacts with the core as the frontend, not the UI. To me, the UI is the code that interacts with the user, which is certainly part of the frontend, but the frontend also contains higher level functions such as VCR support, config files support, etc.