problems with Mac bundle structure & behavior

[GoogleCodeExporter]

The Mac bundle isn't quite right—it looks to my eyes like there are 
configuration files stored inside 
the bundle, which is not correct behavior for a Mac application. Mac bundles 
are considered 
immutable and user data are stored in a folder under `~/Library/Application 
Support`. If these are 
just defaults and not meant to be changed, then forgive me.

Additionally, the plug-ins ought to be compiled as bundles and kept in 
`Contents/Plugins` rather 
than `Contents/MacOS`. Other libraries should probably go in 
`Contents/Frameworks` or be 
statically linked.

Original issue reported on code.google.com by eris.dis...@gmail.com on 6 Mar 2010 at 3:16

[GoogleCodeExporter]

What do you mean by settings? The RiceVideo.ini is only a database for global
ricevideo default settings which aren't changed by the user. The same goes to
Glide64.ini and InputAutoCfg.ini. The mupen64plus.ini is only a database of 
known
rom names. The real settings are stored in mupen64plus.cfg in a user directory 
(sry,
don't have any apple software so Auria has to give more statements about the 
rest).

Original comment by sven@narfation.org on 6 Mar 2010 at 8:15

[GoogleCodeExporter]

I didn't poke around too deep so I assumed they were settings based on the file 
extension—I am used to this 
being the extension for configuration files for oldschool windows apps.

Thanks for your response. I suppose I am nitpicking a little with the rest; my 
incorrect assumption that 
configuration was being stored in the bundle was the main problem.

Original comment by eris.dis...@gmail.com on 6 Mar 2010 at 8:22

[GoogleCodeExporter]

What's in the bundle's Resource directory is what would be in 
/usr/share/mupen64plus
or so on linux; these files are never written to. Files written to are stored in
~/.config/mupen64plus and ~/.local/share/mupen64plus (I'm not sure why they 
aren't in
~/Library/Application Support/, I thought I had changed that). But in any case 
the
bundle is, unless I did a mistake, never written to. So this bug report can be
closed, unless you find that one of the files in the bundle is actually written 
to,
which would surprise me

Original comment by auria...@gmail.com on 7 Mar 2010 at 4:42

[GoogleCodeExporter]

I've tested it a little and I believe the behavior checks out after all; 
application bundle is immutable as expected. 
Next time I'll do a little more research before opening my mouth. :)

Original comment by eris.dis...@gmail.com on 7 Mar 2010 at 4:46

[GoogleCodeExporter]

Original comment by richard...@gmail.com on 29 Dec 2010 at 1:25

• Changed state: Invalid