Diag font: use path relative to executable.

[gizahNL]

Fixes diag window not loading when Caspar was not started from the caspar dir (i.e.: under systemd the working dir would be /, and caspar would look for the font in / instead of the installation directory).

[dimitry-ishenko]

FWIW, c++17 has a "built-in" filesystem support in the standard library:

https://en.cppreference.com/w/cpp/filesystem

I don't remember if CCG has switched to c++17 yet, but it would be nice to see boost dependency reduced in favor of the standard library.

[gizahNL]

FWIW, c++17 has a "built-in" filesystem support in the standard library:

https://en.cppreference.com/w/cpp/filesystem

I don't remember if CCG has switched to c++17 yet, but it would be nice to see boost dependency reduced in favor of the standard library.

Would that also contain a portable way to find the path relative to the executable? If so that would indeed be the preferred way.

[dimitry-ishenko]

FWIW, c++17 has a "built-in" filesystem support in the standard library:
https://en.cppreference.com/w/cpp/filesystem
I don't remember if CCG has switched to c++17 yet, but it would be nice to see boost dependency reduced in favor of the standard library.

Would that also contain a portable way to find the path relative to the executable? If so that would indeed be the preferred way.

Something like this should do the trick:

namespace fs = std::filesystem;

auto font_path = fs::path(argv[0]) / ".." / ".." / "LiberationMono-Regular.ttf"
if (!font.loadFromFile(font_path))
    ...

If you don't like .. you can use: fs::path(argv[0]).parenth_path().parent_path() / "LiberationMono-Regular.ttf" instead.

[Julusian]

This wont work on windows, as the font is in the same folder as the executable there

[gizahNL]

@Julusian would putting it in between ifdefs for linux/windows suffice? Together with the changes suggested by @dimitry-ishenko.

[dimitry-ishenko]

@gizahNL you could do this to address @Julusian 's concern:

namespace fs = std::filesystem;
...
auto pgm_dir = fs::path(argv[0]).parent_path();
auto font_name = "LiberationMono-Regular.ttf";
auto font_path = pgm_dir / font_name; // weendoze path
if(!fs::exists(font_path)) font_path = pgm_dir / ".." / font_name; // Linux path
if(!font.loadFromFile(font_path))
    ...

But I've realized you probably don't have access to argv[0] from within the module, so you might still have to use boost 😞

[gizahNL]

@gizahNL you could do this to address @Julusian 's concern:

namespace fs = std::filesystem;
...
auto pgm_dir = fs::path(argv[0]).parent_path();
auto font_name = "LiberationMono-Regular.ttf";
auto font_path = pgm_dir / font_name; // weendoze path
if(!fs::exists(font_path)) font_path = pgm_dir / ".." / font_name; // Linux path
if(!font.loadFromFile(font_path))
    ...

But I've realized you probably don't have access to argv[0] from within the module, so you might still have to use boost disappointed

On linux we can also check where /proc/self/exe links to. I'm not sure if this issue is at all present on Windows, so for me it would be totally fine to #ifdef the logic under __linux

[Julusian]

This may not be a solution for this, but I added a compile flag which resolves this issue for proper debian packaging. It expects the font to be installed through a package in the debian repositories, and allows for loading from that system path.
7366b83

I admit, doing it with a define isnt the best approach, but I wasn't sure how else to do it.
Maybe that would work here too, or the define could be changed to specify the fixed path to load the font from?