Nightly Subsurface AppImage for most Linux distributions

Lubomir I. Ivanov neolit123 at gmail.com
Sun Oct 18 05:14:23 PDT 2015


On 18 October 2015 at 14:26, probono <probono at puredarwin.org> wrote:
> 2015-10-18 12:50 GMT+02:00 Lubomir I. Ivanov <neolit123 at gmail.com>:
>> on Linux the install location of this printing_templates
>> folder should be:
>> /usr/share/subsurface/printing_templates
>
> Added to the AppImage.
>

some grantlee plugins are missing as well, but i don't know where to
put these on Linux. probably Dirk knows.

there should be:
<some-location>/
    grantlee/
        5.0/
            grantlee_defaultfilters.so
            grantlee_defaulttags.so
            grantlee_i18ntags.so
            grantlee_loadertags.so

>> do have to copy them outside of the AppImage
>> manually?
>
> Why would you even want to do that?
>
> Anyhow, this is one way:
> While Subsurface is running, do
> cat /proc/mounts | grep Subsurface | cut -d " " -f 2
> This will show you where the AppImage is FUSE-mounted so that you can
> copy the files from there.
>
> Or, if Subsurface is not running, you can do
> sudo mount Subsurface_4.5.0_x86_64.AppImage /mnt/
> and then copy the files from /mnt/
>

the AppImage is mounted as a read-only filesystem.
we include some HTML which the Subsurfaces enumerates from a folder.
the user can edit in-place the bundled files or even import more files
to the same folder.

but if the AppImage is read-only one cannot add files to the folder
from where these HTML files are read.
for that to work either the AppImage needs to be RW (don't think
that's an option), the AppImage needs to be installed or a RW location
(e.g. $HOME) or the app needs to copy these files to a RW location -
preferably via scripting and not on the source code side.

if AppImage is used on Linux, copying said files to a RW location
would only be needed on Linux as this is not a problem on Windows
(since we install) or OSX (AFAIK).

>> i'm not familiar with how AppImage works, but have you thought about:
>> myImageFile.AppImage -install ~/somewhere
>> in which case the complete AppImage deploys to a folder and running
>> the app can be done via something in the lines of:
>> cd ~/somewhere
>> ./run (or ./AppRun ?)
>
> This is something I try to avoid. The reason is that I don't want to
> encourage people to have to "install" software. Or even unpack.
> Reasons for this are summarized in
> http://portablelinuxapps.org/docs/1.0/AppImageKit.pdf

"The AppImage format has been created with specific objectives in mind"
of course, everything in the list makes perfect sense. here are some
remarks about corner cases that i have, so excuse my chatter.

"Remove the need for installation AppImages contain the app in a
format that allows it to run directly from the archive, without having
to be installed first. This is comparable to a Live CD. Before Live
CDs, operating systems had to be installed first before they could be
used."

"Keep apps compressed all the time"

the concept is great as an optional scenario, but it forces the
applications to do gymnastics if it wishes to maintain a folder where
the user can edit or update bundled files, manually or via the UI.
having an optional install in such a case has benefits.

let's say i have developed a rather big peace of CAD software (e.g.
4GB) which is a small 10MB executable and next to it are many large
files (e.g. 200MB) which have a horrible AppImage compression ratio as
they are already compressed. the main executable loads these files as
libraries (let's say 3D meshes, textures, or schematics). i often make
updates to some of the 200MB files and wish to implement a
download-updates mechanic, which only touches some large library files
and possible the main executable.

if an installation process to a RW location is not implemented in
AppImage i need to either re-package the whole bundle (4GB) for each
iteration or maintain some sort of a separation scheme for the main
executable and the libraries. again, on Windows this won't be a
problem because the download-updates mechanic will just work due the
the RW access of the installation folder.

how would you approach this silly big CAD software example in a
portable OS manner?

lubomir
--


More information about the subsurface mailing list