Configuration/Path Handling/Packaging

Everything about development and the OpenMW source code.
swick
Posts: 96
Joined: 06 Aug 2011, 13:00

Re: Configuration/Path Handling/Packaging

Post by swick » 17 Jan 2012, 21:45

Dont know. I never used a Mac system but if we are lucky we just can copy LinuxPath::getInstallPath to MacOsPath::getInstallPath.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Configuration/Path Handling/Packaging

Post by Zini » 17 Jan 2012, 21:49

Actually, in this case I would consider a common base class for Linux and OS X.

User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: Configuration/Path Handling/Packaging

Post by lgromanowski » 18 Jan 2012, 01:04

Zini wrote:I thought a bit more about the next step and expanded my idea mentioned in the other thread.

So we need to be able to set data paths to specific locations predefined by the system/external programs (example the MW installation directory).

I suggest to add another path expansion step when a data path is passed into the Configuration manager (the actual translation function is probably best implemented in Path).

This expansion step should look for special tokens and replace them.
Ok, I will try to write some example "prototype" today.
Examples:

Global:Data files (This would be expanded to the subdirectory "Data files" in the global location)
MW:Data files (This would expanded to the subdirectory "Data files" in the MW installation directory).

(...)

Actually I think the x:y syntax for tokens is probably not very good. You should choose something that not collides with the existing rules for constructing path strings on all three supported platforms.
Hmm, it could be a bit hard because (if I remember correctly) only Windows have some restrictions for characters in path strings (on Linux all strange characters are escaped), but I will try to find something.
best regards,
Lukasz

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Configuration/Path Handling/Packaging

Post by Zini » 18 Jan 2012, 10:46

Got a pull request regarding FreeBSD support. I closed it and told the author to resubmit it to you. Looks reasonable, as far as I can tell.

corristo
Posts: 493
Joined: 12 Aug 2011, 08:29

Re: Configuration/Path Handling/Packaging

Post by corristo » 18 Jan 2012, 18:09

Hi there.

Regarding Wine & OS X, you generally right, linux approach should work, if one uses system-wide wine installation. I'll call it "case 1".

But in OS X there is common practice to package windows application & wine itself into one application bundle (for example, WineSkin helps to create wine bundles), i.e. for user & OS it looks like just normal application. Let it be "case 2".

I think we can use simple approach for "case 2": find Morrowind.app in /Applications and ~/Applications and get data files from it.

I'm currently messing with http://bugs.openmw.org/issues/162, when I'll finish it, I may think about problem described above.

User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: Configuration/Path Handling/Packaging

Post by lgromanowski » 18 Jan 2012, 22:06

Zini wrote:Got a pull request regarding FreeBSD support. I closed it and told the author to resubmit it to you. Looks reasonable, as far as I can tell.
It's ok, I've merged it.
best regards,
Lukasz

User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: Configuration/Path Handling/Packaging

Post by lgromanowski » 21 Jan 2012, 19:14

Zini wrote:I thought a bit more about the next step and expanded my idea mentioned in the other thread.

So we need to be able to set data paths to specific locations predefined by the system/external programs (example the MW installation directory).

I suggest to add another path expansion step when a data path is passed into the Configuration manager (the actual translation function is probably best implemented in Path).

This expansion step should look for special tokens and replace them.

Examples:

Global:Data files (This would be expanded to the subdirectory "Data files" in the global location)
MW:Data files (This would expanded to the subdirectory "Data files" in the MW installation directory).

The values for the tokens Global, Local and User you can obviously read from the Path class.
The value for the token MW you can read from a registry key on Windows (I think) or by querying WINE for this registry key (on Linux and OS X).

A few things to consider:
- A token might not be available (e.g. MW not installed or WINE not installed). In this case the data path is invalid and should be silently removed from the list by the configuration manager.
- The directory specified by a data path might not exist. This also invalidates the data path. The only special case here I am not sure about is the local data path. The directory might not exist, in which case the editor needs to create it instead of discarding the path. But we can handle this special case later.

Actually I think the x:y syntax for tokens is probably not very good. You should choose something that not collides with the existing rules for constructing path strings on all three supported platforms.
@Zini
I have some small troubles with proper implementation - could you give me some example use cases how would you like to use this token mechanism, please? I.e. is using them in command line --data parameter shall be possible ( --data=?mw:data? ), or just for querying in getDataPath("?mw:data?")?

@Ace (SWE) & swick:
Would you send pull request with installPath changes to Zini, please?
best regards,
Lukasz

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Configuration/Path Handling/Packaging

Post by Zini » 21 Jan 2012, 19:55

Well, command line or not doesn't really matter, since by the time you get those data paths out of boost::program_options, there is no way for you to distinguish between command line and cfg file sources. But to be honest, I can't think of any use in the command line, so if you have found a way to formulate these tokens within a path and it doesn't work with the command line it is probably okay.
getDataPath("?mw:data?")
That looks wrong. While the path expansion is currently only used for data paths, there is no reason to limit it to data paths. A better name would be expandPath or something.

Just so we are clear, this is the sequence:

- boost::program_options collects the data paths from various sources.
- the configuration manager get these paths from program_options, translates them, eliminates invalid ones and then stores them

After that the next task will be to make OpenMW actually use the data paths stored in the configuration manager instead of the wild growth of passing and storing data paths we currently have. I assume this will be tricky part.

User avatar
Zini
Posts: 5537
Joined: 06 Aug 2011, 15:16

Re: Configuration/Path Handling/Packaging

Post by Zini » 23 Jan 2012, 23:39

This is now the only task (or group of task) left for 0.12.0. Once you are finished, we can release.
Since we are extremely late already, I would be okay with only addressing the configuration issues and leave the packaging issues for 0.13.0. This isn't optimal, but we really need to get this release out.

I just noticed, that this issue is not assigned to you, even though it is an essential part of the whole issue complex. Actually without it, the other sub-issues should result in OpenMW failing horribly for most people. Do you want to take it too? Or is anyone else interested? Preferably someone who has already worked with the resources system.

User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: Configuration/Path Handling/Packaging

Post by lgromanowski » 24 Jan 2012, 23:44

Zini wrote:This is now the only task (or group of task) left for 0.12.0. Once you are finished, we can release.
Since we are extremely late already, I would be okay with only addressing the configuration issues and leave the packaging issues for 0.13.0. This isn't optimal, but we really need to get this release out.
It's ok for me, and sorry for delays. If nothing unexpected happen then I will push the code tomorrow.
Zini wrote: I just noticed, that this issue is not assigned to you, even though it is an essential part of the whole issue complex. Actually without it, the other sub-issues should result in OpenMW failing horribly for most people. Do you want to take it too? Or is anyone else interested? Preferably someone who has already worked with the resources system.
If no one will take it, then I can take it too.
best regards,
Lukasz

Post Reply