This will fix https://github.com/solvespace/solvespace/issues/1067 by setting
GTK_USE_PORTAL=0 in the Snap package. This will use a file chooser from the
point of view of the application to open and save files, instead of using the
"desktop portal" where the chooser runs outside the snap and the file is
exposed dynamically into the snap at an automatically generated path.
This will allow files used in assemblies to be seen by SolveSpace as being at
their real paths, so the references to them will be saved as proper
relative-path references based on where the files actually are, instead of as
references to where the portal has exposed them.
The downside is that without the portal you can't point the application at
files that *aren't* exposed to the Snap.
The sources array is usually at the end of a module.
Maybe nitpicking, but the module name will be used as a folder name, and camelcase for folder names is less common on Linux.
* CMake: use PROJECT_VERSION instead of solvespace_*_VERSION
In 006539b, solvespace_MAJOR_VERSION etc. were removed.
However, these variables were still referenced in some places.
Solution: Use PROJECT_VERSION instead.
* CMake: re-add link directories for solvespace target
006539b removed the call to link_directories for gtkmm, jsonc & fontconfig.
This leads to linking errors if those libraries are in "non-standard"
paths.
Fix this by introducing a target specific target_link_directories call.
Fixes#1173
* snap: port to core20 & adapt to CMake changes
Moving to core20 was long overdue anyway, and
the recent CMake changes necessitated some fixes.
Also switch to LZO compression for (way) better cold start
performance.
It was added in 3a3a2755b as a potential way to export colorful meshes
to Horizon EDA but ended up being supported only by SolveSpace. Since no
software can consume the exported q3do files the feature is superfluous.
See https://github.com/solvespace/solvespace/issues/795 for details.
Using gnome-3-34 gives us a newer stack in general
and also provides us with a sdk build-snap, so we don't need
to specify as many build-packages and stage-packages.
This makes the snap slimmer and delegates the responsibility
for security updates to the gnome platform snap for even more
packages.
As per https://snapcraft.io/docs/snap-layouts,
bind-mounts significantly increase the startup time of the snap.
Use symlink instead for better performance.
Remove all files from snap that are already included in the base snap
or in any connected content snaps.
The main advantage is the massively reduced snap size:
From ~70 MB down to ~6 MB.