Absolute file path vs relative file path

[emmanuel-ruffio]

I'm using Binjr files in a github repository to quickly allow the user to plot csv files.
However I realized all filepaths stored in the *.bjr file are absolute so it is to possible to share the bjr file with someone else. I tried to manually remove the directory in the bjr (xml) file but unfortunately, it does not work. I got a file error when the file is opened.
Is there a workaround to transform absolute path in relative path ?
I think it would be a good idea to use only relative path, and not absolute path (or to allow the use of both based on a user option).

Thanks.

[fthevenet]

I don't think there's a way to have binjr switch to relative file paths in a fully consistent way across all existing plugins without risking to introduce backward incompatible changes, unfortunately.
However, it might be relatively safe to make binjr accept either relative or absolute file path (or even a mix of both) when loading a saved workspace.
This would at least allow it to properly read a .bjr file that was manually altered to make paths relative, as long as they are valid.

[fthevenet]

binjr v3.23 has just been released and should address it not being able to resolve paths to assets that are relative to that of a loaded workspace.
Unfortunately, there currently isn't a way for binjr to rewrite the paths as relatives from within the tool itself, so that means if you want this you will need to edit the .bjr file manually to amend the paths, but at least it should load without any problem. As I hinted at in my previous message, even after spending quite a bit of time on the problem, I could not come up with a satisfying solution that would not break compatibility with existing plugins.

The good news, on the other hand, is that as part of addressing that issue, I finally got round to enhance the CSV plugin with existing functionalities from the log files plugin; namely the ability to load multiple CSV files in a single treeview, from a directory or from an zip file, without need to decompress it first.

I hope you find this useful.

Cheers!