Improved relative paths

[Spekular]

Moves the toRelative/toAbsolute functions out of SampleBuffer and allow paths to be relative to locations other than the sample directory. This is a WIP, partially opened so I can get Windows binaries ;)

Essentially just @PhysSong 's solution here.

[Spekular]

Quick testing with the windows build from travis shows that this loads samples from my existing projects just fine. VSTs fail, hence the last two commits. Can't test saving and reloading as LMMS hangs the moment I press File>Save. I think this might be an issue for all master branch versions, will test later. EDIT: Something about lmmsrc.xml was wonky on my desktop. Removing it and redoing my config fixed the hang.

[Spekular]

Alright, new test after the vestige.cpp changes (only testing samples and VST as I don't have any existing projects with sf2 or gig files)

Loading projects on the same machine they were created:

• Loading an old project for the first time: everything loads fine.
• Re-saving an old project, loading the new version: everything loads fine.

Loading projects on a different machine (different username => different paths):

• Loading an old project for the first time: samples work, VSTs break (same as 1.2 behavior)
• Loading a project saved with the new version: everything loads fine.

[Spekular]

Added some more relative locations and did some more testing. Soundfonts appear to work fine (edit: as long as they're in the default [working]/samples/soundfonts). Sample tracks seem to work fine, as well as the "userprojects" base.

Specifically, I tested a sample track with audio loaded from [lmms home]/projects/[project name]/Bounced. It loaded fine on my laptop after I re-saved with the new version on my desktop. (The sample track tooltip does did display userprojects:/[project name]/Bounced which I intend to fix in the next commit I've now fixed).

I'm happy with the functionality of this PR for now unless there are any bugs or other review comments, so perhaps this is more "needs review/needs testing" than "in progress".

One thing that'd be nice in the future is a location relative to the current project file (something like ProjectFileBase with prefix "projectfile:"). This would requires special care when dealing with a project that hasn't been saved yet (or a project being saved to a new location). Ideally, there'd be an additional toShortestRelative called on all the paths in the project after the user selects a save location, but before the file is saved. (See #2982)

[Spekular]

Project File Type	Loading on same PC	Loading on other PC
Created with 1.2.2	Works	Doesn't Work (equivalent to 1.2.2)
Upgraded from 1.2.2	Works	Works
Created with PR	Works	Works

[Spekular]

Ok, even the really minor review comments should be fixed now. Hopefully this won't lead to a random CI failure. Unless there are objections, I'll finally merge this once I have some approvals.

[DomClark]

Looks good to me. A couple of things to consider if you want:

• Add doxygen comments in PathUtil.h? It's easy enough to understand what all the functions do if you look at their implementation, but sometimes you're in the middle of writing/looking at other code and don't want the distraction.
• This PR adds a few bits of commented-out code, which it might be a bit cleaner without - do you want to keep these?

[Spekular]

Add doxygen comments in PathUtil.h?

Great idea. Doxygen seems to support a lot of formats for this, do we have a preferred style? GitHub's search isn't helping me find existing examples 🙃.

This PR adds a few bits of commented-out code, which it might be a bit cleaner without - do you want to keep these?

I'll remove it.

[DomClark]

Do we have a preferred style?

I don't think we have an official one, but @JohannesLorenz has been using the /** and //! styles recently.

[JohannesLorenz]

Seems like we have all kind of styles in the sources:

$ grep '//!' -r include/ | wc -l
235
$ grep '/\*\*' -r include/ | wc -l
67
$ grep '///' -r include/ | wc -l
72

clang-format will not touch these comments, btw.

[Spekular]

I went with //! style doxygen comments. Should we add this to the style page of the wiki?

[PhysSong]

I found an issue with this PR too late. 😅

[PhysSong]

If base is Absolute, baseQDir(base) will point to the working directory. It will result in undefined behaviors.

[Spekular]

Do you think this would fix it?

-QDir baseQDir (const Base base) { return QDir(baseLocation(base)); }
+QDir baseQDir (const Base base)
+{
+    if (base == Base::Absolute){ return QDir::root(); }
+    return QDir(baseLocation(base));
+}

[PhysSong]

Better than before, but that may result in getting foo/bar for /foo/bar which will be interpreted as old-style relative path.