[$threadinfo[title]]

[Tillin9]

Okay, for the past couple of weeks I've been playing around with getting a Qt GUI for Mupen64Plus. I put an early screenshot of my mockup here:
http://www.emutalk.net/showthread.php?t=42770&page=7

I ran into a few snags so I thought I'd start a thread to talk about them.

The over arching issue is that we need to decide if this is a Qt GUI or a KDE GUI. Under Linux basically Qt = KDE, but as I've come to learn over the past few weeks this is not the case on other platforms. Trying to make a GUI that links only to the Qt libs is not that easy once the program becomes complex enough. Before mupen I never really had reason to try to make a more complex Qt only app, so this came as a bit of a surprise.

Basically the whole problem comes down to: Why do we want a Qt / KDE GUI?

My personal reason is I like all my applications to have the same look and feel and since I run KDE, and rarely use an app that doesn't have a K in front of it, the gtk based GUI looks very out of place on my desktop next to my various Konsole, Kwrite, Konqueror, and Kpdf windows. Kopete and Ktorrent round out my 6 most used apps. If the other users who want a Qt GUI are all KDE users and want it for the same reason, then I should probably just make it a full blown KDE app and feel free to use whatever K routines. This actually would make things easiest on me. However, I don't want to make a decision which will later become an issue.

Using KDE libs on a non-linux platform is an issue since most Mac / Windows users don't have them installed nor want to have to install additional libraries to use the emulator. Using pure Qt makes things a little harder and never quite gets things perfect in KDE. The most severe manifestation of this problem, thus far, is that Qt doesn't have the KDE::Toolbar class which is what gives nice toolbars. See the screenshot comparing the Kwrite toolbar to the current toolbar in my mockup.

Another issue are the icons. I personally like our new gtk icons. However, KDE has standard icons for the functions they represent. I configured my mockup to use the defaults. This lets the app get skinned properly along with other KDE / Qt apps. Of course my code looks to see if these directories are populated and if not fall back to the current icon set. This again comes down to why we'd want a Qt based app unless we're on a KDE system.

Other GUI issues, not purely limited to a Qt / KDE GUI, such as Accelerators and shotcut keys are also something which we should come to some agreement on. Right now the gtk GUI has no working accelerators, though it does have some indicated.

The only shortcut keys I know of are:
Alt-Enter - Fullscreen

(Note: I looked through the source a few times but can't find where these are declared. Yes, I know I have a severe lack of gtk knowledge.)

[Surkow]

I don't know what you can do best. But most of the time I use the Cleanlooks theme in Gnome for Qt based applications like SMPlayer etc. I have no issues using kde libraries in Gnome at all.

[Richard42]

Other GUI issues, not purely limited to a Qt / KDE GUI, such as Accelerators and shotcut keys are also something which we should come to some agreement on. Right now the gtk GUI has no working accelerators, though it does have some indicated.

The only shortcut keys I know of are:
Alt-Enter - Fullscreen

(Note: I looked through the source a few times but can't find where these are declared. Yes, I know I have a severe lack of gtk knowledge.)

There is a list of key commands in the included README file, and on the Google Code site. But these keys are not handled by the GUI - they are processed in the SDL event loop in the emulator itself. From a usability standpoint, it does not make sense for any core emulator functions other than high-level ones like play, stop, or pause, to be controlled by the GUI. The GUI's purpose should be to present a nice interface for configuration and game selection, but after launching the emulator it should get out of the way.

On the Qt/KDE issue, I would say there's probably no harm in using the KDE libs as long as they're available on Linux systems using Gnome as the desktop environment. We're not targeting Win32 or OSX right now, so it doesn't make sense to leave out desirable features for the sake of a platform that we're not supporting. If someone comes on board and starts working to support to support these platforms then we may revisit this.

[ebenblues]

Basically the whole problem comes down to: Why do we want a Qt / KDE GUI?
I think consistency of look and feel is the main reason why we would want this. It may seem like a minor issue, but with distros like ubuntu and kubuntu starting to gain more "average" desktop users, consistent look and feel becomes very important to providing a polished product. My vote is to use the kde functions. macos users are probably going to want their own look and feel and I think *BSD users have kde as an option.

[phorsyon]

I vote for the KDE GUI. On Linux systems most people use either Gnome or KDE, so supporting these two with native GUIs should be the goal. The libs are available on all major distributions anyway.

A QT GUI can be a good compromise if you want one single GUI for all platforms, but it will look a bit alien everywhere. OSX users can be very picky about an applications look and feel. So waiting for a OSX developer may be a good idea. Same goes for Win32 (I mean the 'waiting' part not the 'care about look and feel' part ;)). There are so many Win32 developers, some day someone will join the project.

[nmn]

Since its so high demand, I will begin work on the Windows port if i get the time.

[MasterPhW]

Since its so high demand, I will begin work on the Windows port if i get the time.
Great! Thank you, I think the windows only users will really appreciate it!

[Clements]

I have no objections to QT myself.

QT is being used to replace the GUIs in VBA-M and ZSNES also.

[nmn]

Qt looks native on all versions of Windows and native enough on Mac OS X. If Mac users get picky about it, flame about it, we could just dump OS X...

[Tillin9]

Wow, thanks for the replies. The overwhelmming response seems to be that the GUI should be KDE. This makes things easier for me, so I'll probably have something people can try very soon.

Note, I'm not really understanding the KDE libs in Gnome comments. Gnome users would probably opt to use the gtk GUI (the idea is now mupen will have both) and under Linux / *NIX the vast majority of users have both KDE and gtk libs installed. The Qt != KDE issue is only really relevant for using Qt in the Mac and Windows ports.

As far as the hot keys, thanks for the pointers. I was looking in the wrong place, so no wonder I didn't see them. Qt's convention is to put the hotkey next to the menu item. I happen to like this since it makes it easy to know what the hotkeys are. For some things, this just means extra text and no code. For others, like the save 'slots', we'd want a Qt signal and slot that updates which one is selected in the GUI even if that slot function doesn't actually toggle the save 'slot' in the emulator. I hope that this is clear.

Besides the main windows, (main, ROM browser, config) I have a few other things on my TODO:

1) Serious makeover for Blight's GUI. I have a friend making a 3D model of an N64 controller in Maya for this one.
2) Make our Rice GUI look the same as the Windows one, i.e. use tabs instead of one big block.

Also, we should come to some consensus on whether it is important to keep the GUI windows smaller than 640x480 so people can run the GUI via TV out. I know some other emulators have a policy on this.

[Surkow]

[...]

Note, I'm not really understanding the KDE libs in Gnome comments. Gnome users would probably opt to use the gtk GUI (the idea is now mupen will have both) and under Linux / *NIX the vast majority of users have both KDE and gtk libs installed. The Qt != KDE issue is only really relevant for using Qt in the Mac and Windows ports.

[...]

If the development is mostly going to focus on a new Qt GUI build I have no issues using it. I currently dislike the GTK GUI because it uses the old GTK file dialog and the SDL based input plugin causes 100% cpu usage (you wanted to create a Qt GUI for it if I remember correctly). Most Gnome users would not appreciate KDE libraries loaded on startup. But I use enough other KDE programs that benefit from it.

[ebenblues]

I currently dislike the GTK GUI because it uses the old GTK file dialog and the SDL based input plugin causes 100% cpu usage.
Thanks for reporting the file dialog issue. After some research, it appears the current gui uses the GtkFileSelection widget which is deprecated and should be replaced by the GtkFileChooserDialog widget. I've added a new issue to the issue tracker to fix this:

http://code.google.com/p/mupen64plus/issues/detail?id=32

There is also an issue opened for the SDL config dialog. I'm going to work on a port of the config dialog to gtk for v1.4 (hopefully), which should fix the 100% CPU issue, but it will still use the same controller pic that's used today. I'm excited to see the 3D controller model Tillin9's talking about. If people seem to agree that it's better than the current picture, we'll port it to the gtk gui as well.

UPDATE: The file dialog fix turned out to be trivial. I just committed it to svn.

[Tillin9]

Okay, so I did some more work and basically determined that if the code is going to be maintainable, a lot more of it needs to be done manually than I first intended. Since there seems to be no easy Qt .ui to code transition and the designer leaves a lot to be desired when doing more than dialogues, I think this is the better path. So, since my experience is primarily on Debian, where do our KDE users have their KDE and Qt includes and libraries?

For me:

KDEINCLUDE = /usr/include/kde
KDELIB S = /usr/lib
QTINCLUDE = /usr/share/qt3/include
QTLIBS = /usr/share/qt3/lib

Doing things manually means we only need the kdelibs and qtlibs to run, and additionally the KDE headers, Qt headers, and Qt MOC to compile. These 4 flags, plus say a OBJ_KDE_GUI and maybe some flag to pick the gtk or KDE GUI (if this wasn't a top level option) would be all the necessary modifications to our build system.

Finally, I noticed that 0-9 is supposed to change the save state. Right now, it doesn't seem to do so, either in the GUI or the emulator. Esc also doesn't quit the emulator, just ends emulation.

[Richard42]

KDEINCLUDE = /usr/include/kde
KDELIB S = /usr/lib
QTINCLUDE = /usr/share/qt3/include
QTLIBS = /usr/share/qt3/lib


You can't hard-code these paths in the makefile. The normal way to do this for the QT libraries is like this:

CFLAGS += `pkg-config --cflags qt-mt`
LDFLAGS += `pkg-config --libs qt-mt`

There should be something similar for the KDE libraries.


Finally, I noticed that 0-9 is supposed to change the save state. Right now, it doesn't seem to do so, either in the GUI or the emulator. Esc also doesn't quit the emulator, just ends emulation.

I'm not sure what you mean about the Escape key. It does shut down the emulator, but not the GUI. Escape is not normally used to quit any GUI application, that's usually Alt-F4 or a message like WM_QUIT from the message loop.

If the 0-9 keys are not selecting the load/save slot then that's a bug that we should add to the issue tracker.

[ebenblues]

the SDL based input plugin causes 100% cpu usage
FYI, I committed a fix to svn (r90) which should greatly decrease the amount of cpu used by the SDL config dialog in blight_input. Hopefully this helps people out until I port the config dialog to gtk.

[Surkow]

Thanks for reporting the file dialog issue. After some research, it appears the current gui uses the GtkFileSelection widget which is deprecated and should be replaced by the GtkFileChooserDialog widget.

[...]

UPDATE: The file dialog fix turned out to be trivial. I just committed it to svn.

Thanks for fixing the dialog.

FYI, I committed a fix to svn (r90) which should greatly decrease the amount of cpu used by the SDL config dialog in blight_input. Hopefully this helps people out until I port the config dialog to gtk.

After compiling the latest svn version I noticed the decreased amount of cpu usage. Sadly enough half of the time it fails to capture my input from my xbox 360 controller (a while back I made a thread about it).

Edit: it seems to work ok now.

[Slougi]

Hi, I'm a KDE developer and use Qt professionally at work.

One piece of advise: use Qt4 and/or KDE4. Qt3 and KDE3 is basically dead code that will get only bug fixes in the future.

Also, _do_ use Qt designer. It is very versatile, learn how to use it. Manually coding the ui is _not_ more maintainable at all.

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

[Slougi]

Also, on no platform is Qt == KDE. The KDE libraries extend Qt with extra functionality. Currently kdelibs itself is portable to windows and mac as well. What problems were you seeing trying to link only to Qt?

[Tillin9]

None of the KDE GUI stuff is in svn. Mainly since I'm still trying to figure out the best way to do this correctly. I thought it would be easy to go from Qt + KDevelop + (KDevelop's autobuild system) to KDE via texteditor which could be merged with mupen's build system. This is not the case. But hey, part of why I'm working on this is also to learn. :)

Its nice to have someone more knowledage here.

My main issue is how do I choose KToolbar instead of QToolbar using designer code without overloading? Also, is there a nice .ui -> code tool (i.e. so I can use the designer to design but then modify the things it doesn't have options for) and so I don't have to use the setUi() stuff? The designer seems to leave a lot of options out. Another issue, which may be a version / not being taught issue., but I can't find anything on how one might go about using icons from files at runtime (needed for the KDE skinable icons with fallback) in the designer. Everything I do just embeds the images which we don't want to do. Even for mupen64plus specific images, the resources should be separate so they can be easily incorporated into other GUIs.

My Qt == KDE on Linux comment was that for most simple things nothing visual is changed and contrary to on Windows and OSX, Qt widgets are native widgets. The same appearance comes up in the example that for a simple KDE app, one uses QListView even though there is a KListView class. I also believe that the KDE themes are passed to the relevant Qt engine so both widgets will always look the same (unless one goes to great lengths to give them different themes - this probably involves using Qt-copy or otherwise having two sets of Qt installed). Hence to make a GUI which looked native, if it was simple enough, we'd only need to add a dependence on Qt. KDE4 probably changes the difficulty of compiling the K libraries on other platforms, but when last I checked it was still very painful. I'd love to hear these problems were fixed and there is a nice .exe or .pkg which installs all the dependencies automatically.

Finally, since you said you were a KDE developer, I have a couple general KDE4 questions as I don't really like it yet. Are there any plans for KDE3 widget and iconset converters? My main issue is I dislike the default themes, they violate my #1 rule of UI design of always keeping things looking the same unless there is very, very good reason to change. I personally feel KDE4 looks like an OSX iconset on Vista. However, I do appreciate the speedup, and a lot of the underlying upgrades so I think its just getting some nice classic themes for stubborn olddies like myself.

F.Y.I. - I was taught Qt3 in school, but have a copy of Molkentin's Book of Qt 4 and for the basic things I'm doing I don't see much of a difference. That is I can replace the qt3 with qt4 above and everything still looks the same (though uses my KDE4 theme).

[Slougi]

None of the KDE GUI stuff is in svn. Mainly since I'm still trying to figure out the best way to do this correctly. I thought it would be easy to go from Qt + KDevelop + (KDevelop's autobuild system) to KDE via texteditor which could be merged with mupen's build system. This is not the case. But hey, part of why I'm working on this is also to learn. :)

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.

Its nice to have someone more knowledage here.

Never said I was knowledgeable ;)

My main issue is how do I choose KToolbar instead of QToolbar using designer code without overloading? Also, is there a nice .ui -> code tool (i.e. so I can use the designer to design but then modify the things it doesn't have options for) and so I don't have to use the setUi() stuff? The designer seems to leave a lot of options out.

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.

Another issue, which may be a version / not being taught issue., but I can't find anything on how one might go about using icons from files at runtime (needed for the KDE skinable icons with fallback) in the designer.

You need to look into the KAction class and KXMLGUI.

http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KXmlGuiWindow
http://techbase.kde.org/index.php?title=Development/Tutorials/Using_KActions

Everything I do just embeds the images which we don't want to do. Even for mupen64plus specific images, the resources should be separate so they can be easily incorporated into other GUIs.

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

My Qt == KDE on Linux comment was that for most simple things nothing visual is changed and contrary to on Windows and OSX, Qt widgets are native widgets. The same appearance comes up in the example that for a simple KDE app, one uses QListView even though there is a KListView class. I also believe that the KDE themes are passed to the relevant Qt engine so both widgets will always look the same (unless one goes to great lengths to give them different themes - this probably involves using Qt-copy or otherwise having two sets of Qt installed).

There are a few theming things not picked up currently by basic Qt apps when compared to KDE (palette changes for instance). qt-copy isn't really relevant to that.

Hence to make a GUI which looked native, if it was simple enough, we'd only need to add a dependence on Qt.

Well, you will get a native look on windows and mac os x since the actual platform specific libraries are used underneat. You should also be very close to KDE modulo some of the KDE specific things.

KDE4 probably changes the difficulty of compiling the K libraries on other platforms, but when last I checked it was still very painful. I'd love to hear these problems were fixed and there is a nice .exe or .pkg which installs all the dependencies automatically.

http://techbase.kde.org/index.php?title=Projects/KDE_on_Windows
http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X


Finally, since you said you were a KDE developer, I have a couple general KDE4 questions as I don't really like it yet. Are there any plans for KDE3 widget and iconset converters?

KDE4 is compatible with the freedesktop.org icon spec that was established during the KDE3 series. I'm not aware of any converters.

Gnome and KDE4 icon themes should now be interchangeable largely.

My main issue is I dislike the default themes, they violate my #1 rule of UI design of always keeping things looking the same unless there is very, very good reason to change. I personally feel KDE4 looks like an OSX iconset on Vista. However, I do appreciate the speedup, and a lot of the underlying upgrades so I think its just getting some nice classic themes for stubborn olddies like myself.

How am I supposed to comment on this? :)

F.Y.I. - I was taught Qt3 in school, but have a copy of Molkentin's Book of Qt 4 and for the basic things I'm doing I don't see much of a difference. That is I can replace the qt3 with qt4 above and everything still looks the same (though uses my KDE4 theme).

Good, then just use Qt4 ;)

[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 (http://slougi.ath.cx/stuff/) 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]

http://slougi.ath.cx/stuff/kde4-mupen64plus.png

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:


A preliminary patch that cleans up some things cmake doesn't like
The actual cmake stuff
The KDE4 interface
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:

http://slougi.ath.cx/stuff/kde4-mupen64plus-2008-04-06-13-59.png

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:

It will be difficult to implement. It might look simple but oh woe the hidden pitfalls...
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.
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.

[nmn]

Maybe we should consider splitting the configuration system into a seperate library though. It would suck if Windows users could not use Jabo's Direct3D plugin. Its nice to try to unify the plugins and such, but you're probably better off creating extensions to the link level API in this case if you want to keep into consideration 3rd party plugins. Yes, we may have breaken the link level compatibility. Is it impossible to fix? Impossible to provide a loader for standard plugin? I think its worth mentioning that unifying the plugin's configuration systems does not necessarily have to be specific to the core, and even if so, we don't necessarily need to completely ruin support for other plugins.

The unified GUI API idea isn't too hard if we abstract at a high enough level and there are many other ways to provide support for multiple GUI libraries, probably better.

[Slougi]

"Emulation started" (http://slougi.ath.cx/stuff/kde4-mupen64plus-2008-04-07.png)

[Surkow]

"Emulation started" (http://slougi.ath.cx/stuff/kde4-mupen64plus-2008-04-07.png)

Wow, it looks very impressive. More developers show up every day.

[Slougi]

It's a me! (http://slougi.ath.cx/stuff/kde4-mupen64plus-2008-04-07-mario.png)

=)

[smcd]

superb slougi! thanks for the contributions everyone :)

[nmn]

AWESOME! I must build this, now!

edit: If anyone else has never used Cmake before, just letting you know to configure via

cmake -DKDE4GUI:int=1 .

to build the KDE4 GUI. Then Make works as per usual. My first time using this and its pretty pleasant when it works.

[Slougi]

With cmake one usually has a separate build dir. So you would say something like this in the source dir:

$ mkdir build
$ cd build
$ cmake .. -DKDE4GUI:bool=TRUE -DCMAKE_INSTALL_PREFIX=/wherever
$ make


When you have a separate build directory you don't "contaminate" your source directories, and removing all build output becomes simple.

Note that I didn't get uninstall support into the build system yet.

[kuwisdelu]

Hey, Mac OS X user here. I've been following the Mupen development for a little while now. Unfortunately, I have not much to contribute dev-wise, as I'm a very novice programmer.

Anyway, despite being a Mac user, I must say I don't care even if I have to run this in X11, I'd very much appreciate a new version of Mupen for OS X. Regardless of the GUI, please don't drop support for us. Mupen is the only open-source N64 emulator for Macs, and it'd be great to have access to the latest version.

Also, though I can't really help with the development, I do have the latest version of XCode and I can probably figure out how to compile an OS X version if necessary. However, if I needed to mess with incompatible libraries or anything like that, it'd likely be a bit above my head.

[Slougi]

Hey, Mac OS X user here. I've been following the Mupen development for a little while now. Unfortunately, I have not much to contribute dev-wise, as I'm a very novice programmer.

Anyway, despite being a Mac user, I must say I don't care even if I have to run this in X11, I'd very much appreciate a new version of Mupen for OS X. Regardless of the GUI, please don't drop support for us. Mupen is the only open-source N64 emulator for Macs, and it'd be great to have access to the latest version.

Also, though I can't really help with the development, I do have the latest version of XCode and I can probably figure out how to compile an OS X version if necessary. However, if I needed to mess with incompatible libraries or anything like that, it'd likely be a bit above my head.

Hi,

It would be much appreciated if you care to test the KDE interface on OS X. If you're willing to do that, this is roughly what you need to do:

1. Install at least kdelibs, kdesupport, qt, soprano and strigi from here (http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X#Installation).

2. Install cmake (the link is on the same page)

3. Grab the latest svn source code using subversion. For example in a terminal:

svn co --username mupen64 --password Dyson5632-kart svn://fascination.homelinux.net:7684/mupen64plus/branches/r0100-mupen64plus-cmake-and-kde4

This will create a folder "r0100-mupen64plus-cmake-and-kde4". Make sure you have subversion (http://subversion.tigris.org/project_packages.html) installed. ;)

4. Again, in a terminal do the following:

$ cd r0100-mupen64plus-cmake-and-kde4
$ mkdir build
$ cd build
$ cmake .. -DKDE4GUI:bool=TRUE


If it builds (doubtful right now, but there shouldn't be all that much to fix...) you can try to install it:

$ make install


If everything worked you can run it by issuing the command "mupen64plus". A real OS X installation package needs a bit more work, unfortunately I have no experience there.

[kuwisdelu]

I'm downloading the KDE files right now. My internet isn't the fastest, so this may take a while. When that's done, I'll try building it.

I don't have a lot of time for the next few weeks, but over the summer I may have time to look into a better OS X installer. If this were all in Cocoa, that would be quite easy, but obviously that won't really work with KDE for cross-platform use. If there is high enough level abstraction from the UI, I may even be able to make a more Mac-like GUI for OS X, but I don't think I'm really that good, yet. Whenever these downloads are done, I'll be happy to at least test the KDE builds, though.

[Slougi]

If you're serious about helping out you can contact the KDE mac people: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X#Development_.28Helping_O ut.29

When I last talked to them they were very helpful.

[Slougi]

More progress, KDE4 and GTK2 in the same process (http://slougi.ath.cx/stuff/kde4-plus-gtk2-mupen64plus-2008-04-14.png).

[nmn]

More progress, KDE4 and GTK2 in the same process (http://slougi.ath.cx/stuff/kde4-plus-gtk2-mupen64plus-2008-04-14.png).

Awesome! Now It's pretty much superior to the Gtk branch (edit: err GUI... not a branch :P). I would backport some features to the Gtk GUI if I hadn't so much work to the Windows Branch. Anyways, thanks for the great work. I just love the speediness, especially with how fast the ROM list loads up - Too bad internally it can still take a while with large ROM directories. That's definitally not the GUI as it was with GTK.

[Slougi]

Awesome! Now It's pretty much superior to the Gtk branch. I would backport some features to the Gtk GUI if I hadn't so much work to the Windows Branch. Anyways, thanks for the great work. I just love the speediness, especially with how fast the ROM list loads up - Too bad internally it can still take a while with large ROM directories. That's definitally not the GUI as it was with GTK.

Thanks =) Always nice to get positive feedback.

Regarding the startup, I plan to implement a cache for rom info. I just need to think a bit about how to design it in a sane way.

[ebenblues]

Regarding the startup, I plan to implement a cache for rom info. I just need to think a bit about how to design it in a sane way.
While we're on this topic, I'd like to make the cached rom info data common and available to other parts of mupen64plus, not just the gui. I could sure use this information in the cheat system. Right now, the cheat system has it's own limited version of rom info (just CRC and name). I would much rather just be able to have a pointer to a rom info struct maintained elsewhere in the system. Thoughts?

[Slougi]

While we're on this topic, I'd like to make the cached rom info data common and available to other parts of mupen64plus, not just the gui. I could sure use this information in the cheat system. Right now, the cheat system has it's own limited version of rom info (just CRC and name). I would much rather just be able to have a pointer to a rom info struct maintained elsewhere in the system. Thoughts?

I think a good starting point is to map out requirements. What I need:


fast lookup
rom metadata
ability to include zipped and gzipped roms in the cache


I don't really care about the rom CRC itself, I need to be able to look at a file and say "yup, saw that one before with info x, y, z". The cheat system will probably care about the CRC of the rom itself, not the file, because it might be compressed.

[nmn]

I'd check the size and checksum of the first 100 or so bytes to ensure the file was the same. Usually it's okay to assume the file is always the same, but sometimes it is not.

Also, you could probably unify or link together the cheat system and the ROM info system without much trouble.

[Richard42]

While we're on this topic, I'd like to make the cached rom info data common and available to other parts of mupen64plus, not just the gui. I could sure use this information in the cheat system. Right now, the cheat system has it's own limited version of rom info (just CRC and name). I would much rather just be able to have a pointer to a rom info struct maintained elsewhere in the system. Thoughts?

The file main/rom.h already has a couple of structures - ROM_SETTINGS and ROM_HEADER. You may want to just aggregate these two, get rid of the stuff that you don't need or is not being used, add the extra stuff that you do need, and go with that.

[Tillin9]

In a strange turn of events, I ended up spending some considerable time updating the Gtk GUI mainly since I can't get my KDE3 theme on the KDE4 GUI but the Qt Gtk Theme engine can. Anyway... I added sorting and filter functions to the Gtk GUI, they're not commited yet since there's still some cleanup to do and Issue 69 seems to take priority for me right now. Anyway... Here's a look:

http://sknauert.web.wesleyan.edu/gtk_gui.png

P.S. The UNCLEAN comment is a reference to the state of Rice after ending emulation, I was messing around trying to find the bug.

[okaygo]

Looks great, makes me want update my theme... I use such a wierd one.