Ryzom

This night I thought about something :)

• Use the client_default.cfg.in to use a token such as <BundlePath> (that's just a proposition, but you can change this name) in PreDataPath and DataPath
• Copy the generated client_default.cfg to Bundle
• In CClientConfig::init, when creating client.cfg, put the real path to client_default.cfg (in Bundle) for RootConfigFilename, if the client.cfg is already created, update the RootConfigFilename variable to client_default.cfg (in Bundle), so when you launch Ryzom, it will always use the right client_default.cfg
• When adding PreDataPath and DataPath to search paths, replace all <BundlePath> by the Bundle real path, so absolute, relative and relative from Bundle paths should be working :)

Seems quite complex.

Another solution:
By default, the code move the working directory to the bundle/Contents/Resources/ where we have the client_default.cfg data/ directory and so on.
So all the code is working without any modification.
Be sure the client.cfg RootConfigFile contains "client_default.cfg" without any path.

And voila, no need of special case like "preDataPath = getAppBundlePath() + "/Contents/Resources/" + preDataPath;" or "defaultConfigFileName = getAppBundlePath() + "/Contents/Resources/" + defaultConfigFileName;"

The goal was to split client.cfg, screenshot etc stuff from data and client_default.cfg. This way, every user on the machine has it's own config and the ryzom_client.app bundle does not need to be writable (in case of non-admin users).

So the working directory is set to ~/Application Support/Ryzom atm.

It's not a problem.

You can set the working dir to bundle/Contents/Resources/ and write client.cfg, screenshot and other user files in your ~/Application Support/Ryzom atm.

Just a quick question out of curiosity... CPack generates .app, .framework, etc. Are you considering letting it build the .app for you? I understand the config file work has to happen outside of it. But it would be nice if we could harness that.

@ace: How could that be done? As I understood the code, lots of stuff is created in / written to working directory. E.g.

init.cpp:742

        // create the save dir.
        if (!CFile::isExists("save")) CFile::createDirectory("save");

        // create the user dir.
        if (!CFile::isExists("user")) CFile::createDirectory("user");

client_cfg.cpp:251

const string ConfigFileName = "client.cfg";

client_cfg.cpp:1892

void CClientConfig::init(const string &configFileName)
{
    // if the users client config does not exist
    if(!CFile::fileExists(configFileName))
    {
        // create the basic .cfg
        FILE *fp = fopen(configFileName.c_str(), "w");

All those parts would need adjustments then, don't they?

@sfb: Even ADD_EXECUTABLE can create .app bundles. To be honest, I never looked into CPack. Should have a look into it to see what is possible using that.

Indeed but the rework is just to append a userDirectory() function that get the ~/.ryzom on linux ~/Application Support/Ryzom on mac.

Ok, so you'd suggest to have the working path where data is (not necessarily writable), and the writable user path somewhere else (platform dependent), so the code handles the prefixes for this. Hm. Well, yes, thats the other way around and makes the custom client_default.cfg unnecessary... Might be a cleaner solution...

I already did that for all debug/log/temporary stuff, it's using getLogDirectory(), which is the one passed to createDebug(logpath); :)

ok, finally we agreed on:

• working path is writable
• working path is per user and platform specific (e.g. ~/.ryzom or ~/Application Support/Ryzom)
• data and client_default.cfg may be read only
• on mac, they are in ryzom_client.app/Contents/Resources/
• client.cfg's path to client_default.cfg must only be "client_default.cfg", even it is not in the working dir but in the app bundle
• client_default.cfg's data path must be only "data" if ryzom_client.app/Contents/Resources/data is meant

Perfect!

I am thinking about moving this functionality to NLMISC::CPath, because if we want to make CConfigFile able to load RootConfigFilename (even if it is just the plain file name) from the app bundle (or in general, the "(write only) resource path"), then NLMISC needs to know about app bundles. So it is not enough to have the app_bundle_utils in ryzom client anymore.

NLMISC::CPath already provides a similar functionality; it is possible to get:

• a temp path using NLMISC::CPath::getTemporaryDirectory()
• the user specific writable path using NLMISC::CPath::getApplicationDirectory() (the name is badly choosen imho)
• the windows system path using NLMISC::CPath::getWindowsDirectory() (which is not useful in this context)

So I though about adding the possibility to get:

• the resource path using NLMISC::CPath::getResourceDirectory() which is
  • SOME_NAME.app/Contents/Resources/ on Mac OS X
  • the path the executable is in on Windows, (e.g. C:/Programs Files/Ryzom/)
  • RYZOM_SHARE_PREFIX on e.g. linux (e.g. /usr/local/share/ryzom/)

And I thought about renaming getApplicationDirectory() to something like getUserDirectory() since getApplicationDirectory() sounds like it is the path containing the executable in my opinion.

Another thing is getLogDirectory() which is defined in nel/misc/debug.h. This functionality could be provided by CPath as well to keep the structure.

I would really like to see the path handling work the same way on all platforms. It does not feel right to just add another #ifdef NL_OS_MAC in the client to make it run. If CPath would return the paths to all necessary directories, this could be achieved quite easily.

And, if this would be implemented across all platforms equally, the windows implementation would gain per user configurations. Isn't that nice? :) But: There should be some way then to automatically migrate the current system wide configuration to the per user directories though.

What do you guys think?