In general it should not matter where an application is installed but it matters very much if the application needs some additional files. These files have to be installed in locations where the application can find them easily. Unfortunately there are many cases which are handled different on each platform.
There are several different types of application files which are handled differently:
Ordinary data files can be located anywhere so they can't be located by the application directly. Either the user has to locate them himself or the user has to configure their location in the preferences. This means no special platform consideration can be made.
Configuration files are either global for all users or user specific. Global configuration can only be read by the application while user specific can also be written. Both types have there defined place (the user specific of course in the user's space) and should be located automatically by the application. Configuration files are handled nicely by wxConfig on each platform.
Files which extend the functionality (i18n files, help files, icons, etc) belong to the application and should be located automatically by the application itself. Therefore these files have to be stored in a defined place. The best place would be right next to the executable itself but since this isn't possible on all platforms, each solution is described separately below.
Through the nature of the "Filesystem Hierarchy Standard" Linux is the most difficult platform for locating files for an application. At least the "Filesystem Hierarchy Standard" allows installing all files of an application under the "/opt/<appname>" directory. Unfortunately it won't work because under Linux no shell seems to expand the application path and provide it to the application in argv[0]. Hopefully this will change in a not so distant future. One might try to create a symlink in your bin directory which absolute path points to application executable, again no shell seems to expand it either. So on Linux there is no simple solution except to store the application path in the application's preferences.
Within the application directory you are free to locate any file where you like. Usually any language independent files are located just next to the executable in the same directory. Language dependent files are located in the appropriate "/<lang>" directory.
MacOS solves the problem with the application files through the use of bundles. This is very handy for a user since such a bundle only has to be put anywhere on the disk, regardless where. Through the defined structure of a bundle an application can easily find any additional file.
The developer only has to determine where the application bundle is located (where the application executable is located) and where inside the bundles the files are located. The normal path within a bundle is:
Windows has the easiest solution for locating application files, simply copy the full application directory anywhere on the disk. Any language independent file is located just next to the executable in the same directory or maybe in a subdirectory. Language dependent files are located in the appropriate "/<lang>" directory.
The simple application directory might lead to thinking that user configuration and ordinary data files can be store in the same directory. Don't do this, keep you application directory clean.
The developer only has to determine where the application executable is located. No additional subdirectories are needed.
bool App::OnInit () {
...
wxString appPath = g_appDirectory; // gets the configured application directory
if (appPath.IsEmpty()) appPath = wxFileName(argv[0]).GetPath (wxPATH_GET_VOLUME);
wxString appName = wxFileName(argv[0]).GetName();
#ifdef __WXMAC__
appPath += wxFileName::GetPathSeparator() + appName + _T(".app/Contents/SharedSupport"));
#endif
...
}
Note: The application directory (g_appDirectory) can be configured in the preferences, the code can looked up in the demo application.