Menu
What's new
By:
Filters

Qt / KDE GUI Thread

N

nmn

Mupen64Plus Dev.
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.
 
N

nmn

Mupen64Plus Dev.
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.
 
Last edited:
S

Slougi

New member
With cmake one usually has a separate build dir. So you would say something like this in the source dir:
Code: 
$ 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.
 
Last edited:
K

kuwisdelu

New member
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.
 
S

Slougi

New member
kuwisdelu said:
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.
Click to expand...

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.

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

3. Grab the latest svn source code using subversion. For example in a terminal:
Code: 
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 installed. ;)

4. Again, in a terminal do the following:
Code: 
$ 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:
Code: 
$ 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.
 
Last edited:
K

kuwisdelu

New member
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.
 
N

nmn

Mupen64Plus Dev.
Slougi said:
More progress, KDE4 and GTK2 in the same process.
Click to expand...

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.
 
Last edited:
S

Slougi

New member
nmn said:
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.
Click to expand...

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.
 
E

ebenblues

Mupen64Plus Dev.
Slougi said:
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.
Click to expand...
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?
 
S

Slougi

New member
ebenblues said:
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?
Click to expand...

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.
 
N

nmn

Mupen64Plus Dev.
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.
 
R

Richard42

Emulator Developer
ebenblues said:
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?
Click to expand...

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.
 
OP
T

Tillin9

Mupen64Plus Dev.
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:

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.
 
You must log in or register to reply here.

Top