If you have a Mac, please test this:
openmsx-2006-01-29-ppc-bin.dmg

Please note:

• this package contains the openMSX CVS version, but if the way it is packaged is OK, I'll create an official binary of openMSX 0.6.0
  
• only OS X 10.3 and later are supported
  
• only PPC CPUs are supported
  
• the file types "cas", "dsk" and "rom" are registered with the Finder and you can launch them from the Finder; however launching a second file when openMSX is still open does not work

After you tested it, please tell me about it, if it was a success or if it was a failure. If you encounter problems or things that could be done nicer, tell me about them.

Many thanks to BouKiCHi for helping me create this binary package.

Cool, I'll give it a try tonight!

Hmmm... it doesn't find my system ROM files but then again I don't know where it's trying to look for those... only from the share folder within the app package?

It works great on my iMac. Very convenient use of ROM images. Nice hi-res icon as well

jr - probably also from /home/jr/.openMSX/share/systemroms (but mth may correct me if I'm wrong).

manuel: Almost correct, but "~" does not expand to "/home/<username>" on OS X, but to "/Users/<username>" instead.

The best location to put system ROMs is "~/.openMSX/share/systemroms", because then they will also be picked up by newer versions of openMSX. You can just put all the ROM files in the "systemroms" directory without a need for subdirectories or special names, since openMSX will find the right ROMs using their SHA1 checksum.

Thanks to everyone for testing! The only problems I heard were "how to do this?", so I wrote a README file which answers some questions users are likely to have after installing. I think I'll be able to release an official binary of openMSX 0.6.0 in a few of days. If you find any problems in the mean time, tell me and I'll try to fix them.

ok... I'm using a different location because I don't want to store gigs of data under my home dir -- old habit, I guess I should think about changing things. Of course also putting a symlink under ~/.openMSX/share to the correct place would probably do it.

Anyway, it's nice to have a ready made binary for Mac too, although I think I'll keep on using my custom built G5 optimized version for the time being ;-) A native Mac GUI for launching the emu and managing settings would be a nice improvement, I don't like using X. Perhaps I'll done one myself one of these days ;-)

jr - You're of course free to make your own launcher, but even better would be if you could join us in building the next generation of openMSX GUI: the Qt version of Catapult. We are in a (software) design phase right now, see the openmsx-devel mailinglist. Your input is most welcome! So, after the design, we want to implement a GUI in Qt, which should compile without any changes or hassle on Windows, Linux and Mac OS X, all looking quite native.

mth: I was doubting whether to use ~ or not. And I made the wrong decision... Ah well, learned something again.

manuel - a few days ago we had a discussion about the lay-out of Catapult on GNOME/GTK+. Catapult has the skin of X, instead of GNOME. Was it because of the same reason, or is there a way to adapt its skin to let it nicely integrate with GNOME?

[D-Tail] - on my system Catapult just takes over the theme of GNOME. You need wxWidgets libraries that are linked to GTK2 for this, I think. The Debian wxWidgets 2.6 ones apparently are. When I used wxWidgets 2.4, this was not the case.

wxWidgets for Mac also shows a native Mac UI, but it doesn't work correctly. To us it just seemed that wxMac is buggy. I think jr compiled it with the normal X libraries on Mac or so, to get a working but non-native UI. It has nothing to do with your problem.

jr - there is an easy way to recognize it without putting into home,
that's just move share directory in the app to the same directory with the app.
like this,
hoge/openMSX.app/share -> hoge/share

you can do it with either "open app package" in the context menu or mv command in terminal.

Quote:

[D-Tail] - on my system Catapult just takes over the theme of GNOME. You need wxWidgets libraries that are linked to GTK2 for this, I think. The Debian wxWidgets 2.6 ones apparently are. When I used wxWidgets 2.4, this was not the case.

Thanks for the hint manuel, I apt-got the wxWidgets library (libwx2.6-0 or something like that) but should I now recompile openMSX in order for it to work?

manuel - actually I didn't compile Catapult on Mac at all, tried it but as it seems to require some additional libs I gave up. When saying "make" at top level it tells me I have wxWidgets 2.5.3 and libxml2 2.6.16 but no wxWidgets XRC. I guess that's then something not present in the "standard" Mac environment, perhaps it could be installed separately? I don't have X server installed on my Mac at all, because I'm fed up with crappy X GUI apps, every app having its own look & feel (which usually sucks) ;-) Also I didn't look at the Catapult code at all but I guess it shouldn't be very complex or performance critical app so why not implement it in Java? No need to build separate binaries for different systems or need for separate cross-platform GUI libs.

boukichi - that's what I thought but I also didn't want to store all my ROMs within the app package. I like keeping the ROMs and the app separate to avoid accidentally losing all my ROM files if I delete the app. Anyway like pointed out earlier this is not really an issue as the app is also looking under ~/.openMSX/share but I didn't know this at first.

[D-Tail] if you compiled Catapult with the wx 2.4 libs, you should recompile it indeed. You don't need to recompile openMSX.

I recommend to remove wx 2.4 completely; it's obsolete.

jr - wx 2.5 is a development version of wx, not a stable release... Anyway, the XRC part is probably still separated then with 2.5. It is integrated with 2.6. Also, wxWidgets apps do not have the X look and feel. HOwever, Catapult barely works on Mac OS X at all and as I said, it's not something we can easily fix, other than reimplementing it in Qt or... Java, as you suggest. For now we haven't really thought about using Java. I'll ask if people are interested.

About JAVA - please don't. The launcher would consume more CPU processing power than the emulator itself. And I'm dead serious on this one.