The official "ZDoom on Mac OS X" thread.

[k0da]

When I played around with CMake on OS X I found it a bit sub-standard compared to Windows. The documentation wasn't very helpful and creating a "complex" application bundle seemed to involve lots of hackery.

[randi]

ZDoom builds and runs on PowerPC Macs but still needs to be Mac-ified. Not sure about maps with ACS. Hopefully they're fine.

[Gez]

still needs to be Mac-ified

What does this involve?

[Rachael]

As far as I know, alerting ZDoom of where to look for configs, putting it in a zdoom.app folder, adding icons and settings, etc.

Pretty much all the same stuff ZDoom had to go through on its addition to the Linux platform - it needs to be platform friendly and there's standards (like with Linux, almost everything is loaded from a dotted home folder, i.e. ~/.zdoom, not sure with Mac, but many things on Mac nowdays work the same way).

[randi]

Things that immediately come to bind: Build a bundle. Make a working Universal Binary. Look for files in standard Mac places. Can I get savegames to be treated similarly to PNGs in Finder through the use of type codes on HFS+ volumes? The assembly code should be re-enabled on Intel Macs, too. In other words, pretty much what SoulPriestess already listed. Other things to do are make a working Xcode project, since the one CMake generates fails. The big one will be to scrap the use of SDL on the Mac end and use native Mac routines. SDL makes sense on Linux where there are so many competing "standards" that it's convenient to let another library take care of the work. Like Windows, the Mac does not have this situation, so it ought to be possible to be a better "Mac citizen" if we use Mac functions directly.

For file organization, preferences are already stored in ~/Library/Preferences/zdoom.ini. IWADs should be searched for in (~)/Library/Application Support/ZDoom and the application bundle itself. Autosaves ought to go to ~/Library/Application Support/ZDoom as well. Manual saves and screenshots are something I'm undecided on. Apple's guidelines suggest these should go in some place like ~/Documents/ZDoom, but they also say that programs should not create anything in ~/Documents without user instruction. Does automatically creating a ZDoom folder fall under that? Should I use standard Mac file dialogs and let the user place these files anywhere they want on the filesystem instead of assuming some specific location for them?

At least the standard ZDoom source code is in a workable state on Macs now, even if it's not very Mac-like, since a few days ago, it didn't work on Macs at all.

[Gez]

Should I use standard Mac file dialogs and let the user place these files anywhere they want on the filesystem instead of assuming some specific location for them?

About as much as you should use the standard Windows file dialogs... It would be more Mac, yes, but less Doom. If people don't like the default locations they have cvars for adjusting that anyway. I suppose you could ask Mac users what they'd prefer. If I were one, I'd want the default directory for saves and screenshots to be at the same place as the ini and autosaves.

[Graf Zahl]

What's the point of spreading these files all over the place?

I like how it is in Windows: All in one place with no need to search the HD for ZDoom related content...

[esselfortium]

I've heard it argued that it's more appropriate to the OS file organization conventions for Doom ports to keep their data (iwads and whatnot) in /Users/esselfortium/Library/Application Support/ZDoom/ or whatever, to keep the Applications folder from getting cluttered, but in my experience games usually just don't work that way. I'd much rather have Doom ports keep their data in the folder with them, whether that be /Applications/Doom/ or wherever else they decide to put their executable, like they're expected to on any other OS. The official classic Mac port of Doom back in the 90s was organized this way, the Quake series are organized this way, Doom 3 is organized this way, etc.

I suppose I could see maybe putting savegames in the user's Library somewhere to avoid clutter, and possibly zdoom.ini in Preferences, but making the user find (or, if it doesn't exist yet, create) an Application Support folder and put IWADs in there to be able to use the game is extremely unintuitive. Programs that place stuff in Application Support folders put it there themselves, whether it's installed there on the app's first launch or whether it's put there when the user downloads and installs addons for the program (this is usually just done by double-clicking the downloaded addon to have the program open it and install it where it needs to be).

While it's not a major problem for users who know where to look, a new user is about as likely to guess their IWADs need to go into Application Support as a Windows user would be to expect their IWADs to go into the AppData folder. (i.e. not at all)

[Gez]

"[wiki]Compile ZDoom on Mac OS X[/wiki]" will need to be updated.

[randi]

Programs that place stuff in Application Support folders put it there themselves, whether it's installed there on the app's first launch or whether it's put there when the user downloads and installs addons for the program

I agree. Application Support is supposed to be for application-generated data and not touched by the user. Strictly-speaking, IWADs should be going into ZDoom.app/Contents/Resources, since they're required for operation. However, we're in the position where we're providing something that doesn't come with all the resources it needs to operate. Putting them in Application Support (which I'm pretty sure already exists on a bare installation of Mac OS X) allows them to be shared by multiple instances of the application without installing them inside each one.

(Searching in the application directory is still going to happen, too, though in this case everything would probably be relative to the bundle directory rather than the executable directory. Application Support would just be an alternate place for people who want to stick ZDoom in their Applications folder and keep it clean.)

[Application Support] Contains application-specific data and support files such as third-party plug-ins, helper applications, templates, and extra resources that are used by the application but not required for it to operate. This directory should never contain any kind of user data. By convention, all of these items should be put in a subdirectory named after the application. For example, third-party resources for the application MyApp would go in Application Support/MyApp/. Note that required resources should go inside the application bundle itself.

[Blzut3]

What's the point of spreading these files all over the place?

I like how it is in Windows: All in one place with no need to search the HD for ZDoom related content...

Although at first glance I really don't like how Mac OS X scatters the files, the file spreading works well on Linux. Take Skulltag for example, I currently have the latest development version and 97d5 installed. Both of these can use the same config file without me copying it or creating a symbolic link to the config. It also allows programs to easily make config files for each user. Instead of ./zdoom-<username>.ini the program only needs to know ~/.zdoom/zdoom.ini.

Spreading the iwads out is also logical since then you can use the same set of iwads for all ports. Screenshots are probably not placed in the application directory since chances are the directory in which the application is in is not writeable.

[Graf Zahl]

What's the point of spreading these files all over the place?

I like how it is in Windows: All in one place with no need to search the HD for ZDoom related content...

Although at first glance I really don't like how Mac OS X scatters the files, the file spreading works well on Linux. Take Skulltag for example, I currently have the latest development version and 97d5 installed. Both of these can use the same config file without me copying it or creating a symbolic link to the config.

Scary stuff. I very much appreciate (G)ZDoom *not doing this on Windows. I got at least different 10 versions floating around (for testing various stuff), partially with incompatible configs and having them all mess around with the same config I use for actually playing would be something I'd consider really inconvenient.

It also allows programs to easily make config files for each user. Instead of ./zdoom-<username>.ini the program only needs to know ~/.zdoom/zdoom.ini.

That's fine and what's the AppData folder in Windows is there for. If ZDoom was concerned about proper system guidelines it should probably do that, too but honestly - I actually like having the config file nearby so that I can edit it by hand if needed instead of going on a wild hunt in the depths of the directory structure.

What bothers me when reading Randy's posts is that all the data appears to be spread out non-intuitively across the HD. If you ask me every program should restrict itself to one (and really just one) directory in a well defined place - nothing more, nothing less - and if it needs external data that cannot be stored there or in the bin directory needs an explicit link to it, e.g. for shared IWADs. Most Windows programs that need IWADs actually ask for their location if they can't find any, BTW.

(Here's an idea for ZDoom: Have the IWAD selection box contain an 'add IWAD' button! That would finally solve the problem of many people wishing to add custom IWADs to that list!)

Spreading the iwads out is also logical since then you can use the same set of iwads for all ports. Screenshots are probably not placed in the application directory since chances are the directory in which the application is in is not writeable.

I don't have them in my ZDoom directory either but in a shared folder somewhere else that is actually been used by all source ports I have installed. But this is global and not something owned in any way by ZDoom. If you ask me they have no place in a ZDoom specific data directory. So any auto-link to a 'ZDoom/App support' folder makes no sense IMO.

[randi]

ZDoom on Mac is going to be exactly like ZDoom on Linux when it comes to standard file paths, except it will use Mac guidelines for locating things instead of the Linux ones.

[k0da]

What Randy has described makes the most sense. Storing everything alongside the application is going to cause a lot of headaches for non-admin users, since they can't write to the application folder.

Randy: Are you going to provide some mechanism in the IWAD selection box for passing command-line parameters? Application bundles can't directly accept command-line parameters. Instead you have to pass them to the executable within the bundle through the terminal which is a bit messy. A lot of OS X source-ports for Doom and Quake provide a launcher for command-line options and loading modifications. In fact Neil Stevens had one working with his abandoned ZDoom Mac port source he sent me.

[randi]

I have to get a an IWAD selector box first. Cocoa seems really overwhelming.