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

Fix relative paths to SVG files in embedded projects #4426

Merged
merged 14 commits into from
May 14, 2017

Conversation

wonder-sk
Copy link
Member

[work in progress - need to fix unit tests and few todos]

This PR fixes this bug - http://hub.qgis.org/issues/16355 - relative paths in embedded project were incorrectly resolved as if they were relative paths within the active project.

The solution is to propagate path resolver through renderers, annotations, diagrams etc.

This is necessary in order to be able to correctly translate between absolute and relative paths deeper in the code - e.g. paths to SVG files used in marker or fill symbols.

Until now, relative paths were translated to absolute paths on the fly. This is now changed - paths to files should be always absolute within QGIS objects - and paths only get turned into relative when saving projects. When loading a project, relative paths are translated to absolute paths immediately.

This should lower the overall confusion about relative/absolute paths within QGIS, and also allow having different base directories for relative paths (e.g. QML or QPT files may use relative paths to their directory - rather than to the project directory)

cc @3nids

@nyalldawson
Copy link
Collaborator

Just wondering.. instead of passing the path resolver itself, wouldn't it be more future proof to pass some container class with the resolver just in case we need to pass other stuff in future?

@wonder-sk
Copy link
Member Author

I thought about that - and I am half-minded about that...

Such container class could be handy e.g. for reporting of errors when loading project files...

@nyalldawson
Copy link
Collaborator

I thought about that - and I am half-minded about that...

Can I add my +1 mind to your +0.5 mind? ;)

@3nids
Copy link
Member

3nids commented Apr 27, 2017

for what it's worth, the container idea seems clever to me ;)

let me know when it's ready to test

@@ -1166,7 +1167,7 @@ bool QgsMapLayer::importNamedStyle( QDomDocument &myDocument, QString &myErrorMe
}
#endif

return readSymbology( myRoot, myErrorMessage );
return readSymbology( myRoot, myErrorMessage, QgsPathResolver() ); // TODO: support relative paths?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please! Symbols stored relative to the project file would be very handy, providing a means of encapsulating sharable ZIP archives of projects, like with QConsolidate. (same for writeSymbology TODO below).

This probably means that a standard-named symbols folder within the project folder, e.g. symbols is dynamically searched, if there is a project (or layer) setting to use project-relative symbol paths.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is more for just vector layers, e.g SVG symbols. I just focused on the TODO note and missed that this refers to the base class.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wonder-sk are my comments ^ not in-line with what this work could be extended to do, i.e. should project-relative symbol paths be implemented in another way/place?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dakcarto I am not sure if I understand how did you mean your comments. We already have support for relative paths to SVG symbol within project directory... (just without a special symbols subdir - but of course users could decide to use such convention if they wanted)

That TODO (when implemented) is meant to add support for relative paths for .qml files - until now it was supposed that relative paths to SVG symbols were relative to a system SVG directory or the current project directory - which is wrong - and instead the directory of the .qml file should be used.

This is necessary in order to be able to correctly translate between absolute and relative paths
deeper in the code - e.g. paths to SVG files used in marker or fill symbols.

Until now, relative paths were translated to absolute paths on the fly.
This is now changed - paths to files should be always absolute within QGIS objects - and paths
only get turned into relative when saving projects. When loading a project, relative paths
are translated to absolute paths immediately.

This should lower the overall confusion about relative/absolute paths within QGIS, and also
allow having different base directories for relative paths (e.g. QML or QPT files may use relative paths
to their directory - rather than to the project directory)
This should make the read/write methods more flexible if we need to give them extra context.
This enables correct loading/saving of relative paths of SVG files for background of labels
It is decided on different level whether files are saved with relative paths
and internally now QGIS always uses absolute paths to SVG files.
Loading bug: on the first project load, data-defined properties for diagram layer settings were not read
as the default constructor did not populate the list of data-defined property definitions.
@wonder-sk wonder-sk merged commit 2857ef5 into qgis:master May 14, 2017
@qgib qgib mentioned this pull request May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants