openmw.org

BrotherBrick wrote:After installing the created deb package, the omwlauncher runs but does not show the 'scroll' image in the back unlike when running omwlauncher from the build directory.

Completely forgot to fix this bug.

@lgro: it would be nice to have a function that returns the resources path in the ConfigurationManager.Then I can use it to retrieve the stylesheet.

BrotherBrick wrote:In the 'Data Files' spot in omwlauncher, I no longer see the typically auto-detected Morrowind data (as in from the data directory). Yes the file/directory exists.

I believe this problem is because Files::Collections does not support paths contained in quotes. I got the same problem with my config from the 0.11.1 release.

Update:
My idea was to put the stylesheet in the resources directory when OpenMW is installed. However, we could consider the stylesheet to be a configuration file, and thus install it to the regular configuration paths. That would make retrieving it a lot easier for me.

Hmm, I think it would be good to put resource etc. things into globalDataPath - /usr/share/games.

Ok, I used globalDataPath instead. Someone who knows CMake/CPack should modify the CMakeLists.txt accordingly.

I fixed the stylesheet problem and I changed the way the launcher retrieves the configuration values. It uses the ConfigurationManager now instead of doing things manually. To get it to work I had to set allow_unregistered to true for parse_config_file() in ConfigurationManager::loadConfig(), as I only set the variables I need. I don't know if this is acceptable though, please check it out.

lgromanowski wrote:@BrotherBrick:
I have installed boost-1.48 - maybe this is the problem. Could you check which version of boost do you have?

I use boost-1.46.1.1 because it is the default in Ubuntu 11.10 (latest release).

lgromanowski wrote:Hmm, I think it would be good to put resource etc. things into globalDataPath - /usr/share/games.

Shouldn't there be only directories there, and that all files go into 'resources' which is the point of the directory in the first place?

Zini?

Ok, I used globalDataPath instead. Someone who knows CMake/CPack should modify the CMakeLists.txt accordingly.

I would expect that to break running OpenMW uninstalled. Use the location pointed to by the --resources option please!

But we should eventually run the value of --resources through the token translation and replace it by something like ?global? or ?global? resources for installed OpenMW (for uninstalled we would still use a place in the local directory).

btw. I am still using boost 1.40. Its the default version in the oldest still current desktop Ubuntu LTS version and I think that is a good baseline for standard components like boost. It's okay to require newer versions of less commonly used packages like OGRE or Bullet, but so far our policy has been not to require newer versions of standard components.

The launcher currently looks for the stylesheet in the global data dir first, then it checks the local directory if no stylesheet is found (uninstalled).

Okay for now (0.12.0). But in the long run we should probably do it like I described above.

Windows build is not possible, the function getGlobalDataPath() in windowspath.cpp tries to call a non-existing function getGlobalConfigPath().
I have no idea what it's supposed to return, "Return same path like getGlobalConfigPath" doesn't say much.

That is the installation location.

I've been able to put together something that builds on Windows, unfortunately I'm not able to test it because the path system seems to fails at replacing tokens in quoted strings.