Nightly Subsurface AppImage for most Linux distributions

[Lubomir I. Ivanov]

On 18 October 2015 at 15:51, probono <probono at puredarwin.org> wrote:
> 2015-10-18 14:14 GMT+02:00 Lubomir I. Ivanov <neolit123 at gmail.com>:
>> some grantlee plugins are missing as well, but i don't know where to
>> put these on Linux. probably Dirk knows.
>
> Right now they are in usr/lib/grantlee/5.0/ but I don't know if they
> are picked up from there correctly. How can I know?

1) start Subsurface from the AppImage
2) go to Log -> Add Dive -> Apply...
(to add at least one dive in the logbook)
3) go to File -> Print -> Preview

this should create a print preview.
if it's print preview is blank the console might have said something
in the lines of "Cannot load grantlee <plugin>".
if it prints something and the console is silent the plugins are found.

>
>> the user can edit in-place the bundled files or even import more files
>> to the same folder.
>
> If these files are meant to be editable then the app (or a script
> launching it) could copy them to some location in $HOME.
>
>> 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.
>
> Well, a copy-on-write FUSE filesystem might be a way to achieve this
> while still maintaining the AppImage objectives; it would make the
> AppImage appear r/w when it is in fact r/o. Changed files would go
> somewhere in $HOME but would look to the application as if they were
> edited in the AppImage. Could probably be done, but is there really so
> much need for it?

it will leave it to Dirk (the Subsurface maintainer) to comment more
on this topic as i'm not very familiar with the Linux installation
process and copy-on-write FUSE fs.
on Windows we have the HTML file in a RW location next to the binary,
so that's not even an issue (if we neglect the fact that the HTML
changes apply to all users).
but the software is considered installed (uncompressed from the
deployment package) and it allows easy W modifications, where the only
downside is the uncompressed size.

>
>> 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
>> (...)
>> how would you approach this silly big CAD software example in a
>> portable OS manner?
>
> Use something like zsync to update the AppImage by only downloading
> the parts of it that have changed. Ubuntu uses this for their nightly
> ISO builds. http://zsync.moria.org.uk

i don't think this makes much sense for the Windows installer, so
that's not really a portable solution.
then again, i have no idea how zsync works...

ideally:
- as the author of the huge CAD software i would write a update method
that works on all platforms (e.g. with Qt - HTML download with local
file replacement)
- AppImage would be the way to distribute the package on Linux
- if the user wants to update the CAD software on a regular basis
he/she can do an AppImage --install and delete the original AppImage.
- once the AppImage is installed, it's now part of a RW filesystem and
the above update method works without a problem.
- no third party tools in the process and no browsers...the user just
starts a small "updater" GUI app which downloads the huge CAD software
packages.
- this is how the Android SDK is managed on Windows; not sure about other OSes.

lubomir
--