To set up extension aliases using a config file, an app calls:
osgDB::Registry::instance()->readPluginAliasConfigurationFile(), passing in the file name as the parameter. (Of course this should be done before loading any files whose names depend on the mapping.) osgDB will search for the file using OSG_FILE_PATH.
The file should contain a line for each mapping, with the "map" extension first, followed by a space or tab, then the plugin identifier. For example, a file containing this line:
flt OpenFlight
would map the ".flt" extension to the OpenFlight plugin."
Tweaks by Robert Osfield - Moved methods to FileNameUtils, added unix
implementation of getRealPath add extern and OSGDB_EXPORT to function declarations.
default Registry Options object, but it would be useful to be able to
request loading with a different Options object. The attached files
allow you to do that (based off the OSG 1.2 source).
For example, I'm implementing a loader that requires context information
when it pages in subgraphs, which becomes significantly complicated when
multiple scenegraphs are requesting subgraph loads with different
contexts (the loader needs to know which context to use, and the
Registry Options needs to be carefully managed so the context settings
don't clobber each other, especially in multithreaded situations). Being
able to pass an Options instance along with the Node request resolves
this problem."
Fixed bug osgDB::Registry::Registry::read(const ReadFunctor& readFunctor) relating to
the handling of failed loads with the ReadResult::_message value being lost, this changes
ensure that the original ReadResult from the plugin, with message intact, is returned correctly.
the user can override existing alias'. The change allowed for circular
references, so the createLibraryNameForExtension would get caught in
an endless loop. The following fix will catch circular references."
"My patch is a slight refactoring of the mac specific code in
Registry.cpp and FileUtils.cpp, specifically around the library and
resource file path initilialization methods. This patch cleans up a
lot of the mac specific code by moving repeated code into separate
local functions in FileUtils.cpp that are only compiled on mac builds.
It also adds one function to the API,
appendPlatformSpecificResourceFilePaths in FileUtils. This function
will mirror the already existing
appendPlatformSpecificLibraryFilePaths except for resource file paths.
Currently this function is empty except when built on the mac, in
which case it will add the application bundle's internal Resources
folder and the bundle's parent folder. Previously this code was
implemented as a separate mac specific #ifdef block in Registry.cpp
around the initDataFilePathList method. However, it now is implemented
in appendPlatformSpecificResourceFilePaths in FileUtils.cpp and the
initDataFilePathList method is now the same on all platforms. This
patch should behave the same as before on non-mac platforms.
This patch already includes the fix that Eric mentioned earlier. This
patch is based off of the 0.99 release code. I have tested this patch
using the following testing scheme:
Make a proper bundled application.
While Run from the Finder:
Test that it finds plugins in its internal plugins path.
Test that it finds resources in its internal resources path.
Test that it finds resources in the bundle's parent directory
Test that it finds plugins in the user's Application Support Directory
Test that it finds plugins in the system's Application Support Directory
Test that it finds plugins in the Network Application Support Directory
Check the plugin and resource path lists after they have been
initialized to see if they are in the correct order
While Run from the command line (both from it's parent directory and
from inside the /Contents/MacOS directory) and repeat the above tests.
Check that it also finds plugins and resources within the paths
defined by various environment variables.
Now, Make an application that is NOT bundled/command line only
Test that it does NOT try to look in an internal bundle
plugin/resource directory for plugins or resources.
Test that it finds plugins/resources in the paths defined by the
environment variables.
"
NSLookupSymbolInModule. The former call would lookup the named
symbol NOT in the current dynamic library, but in the entire running
program while the call NSLookupSymbolInModule, takes the handle to
the library the symbol should be found in. This means the current
code will fail if one loads multiple bundles at runtime and attempts
to load the same named symbol from each one."
