Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relative paths to referenced media #319

Closed
roman380 opened this issue May 21, 2018 · 4 comments
Closed

Relative paths to referenced media #319

roman380 opened this issue May 21, 2018 · 4 comments

Comments

@roman380
Copy link
Collaborator

If files referenced by IFileSourceFilter and IFileSinkFilter interfaces are relative (same directory or a subdirectory) to GRFX/XML file, would we be interested in storing relative path? This would help when the entire containing directory is moved.

@mikecopperwhite
Copy link
Collaborator

Interesting idea:

Would the filename be relative to the GRF or GRFX path? What should happen in an unsaved graph?

One wrinkle:

According to:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd389983(v=vs.85).aspx

For the File Source (Async) filter, pszFileName specifies the absolute path name of a local file. For the File Source (URL) filter, pszFileName specifies the URL of a file to download. For other filter implementations, pszFileName might require a file name or a URL, depending on the filter.

We could try loading as an absolute file or URL first then as a relative file or URL if that fails but it would be a GSN extension feature.

@roman380
Copy link
Collaborator Author

It can be relative to GRFX file, right. After all, it was the original idea that move of GRFX with its dependencies should not break the structure. This certainly assumes GSN itself makes relative from absolute and vice versa on save/load. I actually have a working draft and it seems to be working fine (for GRFX).

@mikecopperwhite
Copy link
Collaborator

Makes sense to make it a GRFX feature. There's no particular reason we couldn't store relative and absolute names under different keys and use whichever works.

roman380 added a commit that referenced this issue May 24, 2018
…oad using relative path; minor code refactoring; implements #319
@roman380
Copy link
Collaborator Author

Good point about saving both. so I added saving both absolute and relative and load tries to load from absolute first (that is, the way it was before) and falls back to relative path only on failure with absolute.

This way we don't need to limit relative path to this or subdirectory, since it's anyway a recovery code path.

cplussharp pushed a commit that referenced this issue Dec 5, 2021
…oad using relative path; minor code refactoring; implements #319
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants