Nightly Subsurface AppImage for most Linux distributions

[Lubomir I. Ivanov]

On 18 October 2015 at 15:29, Miika Turkia <miika.turkia at gmail.com> wrote:
> On Sun, Oct 18, 2015 at 3:14 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> 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
>
> I think these can be put within the AppImage just like any other lib.
>
>>>> 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).
>
> Well, even now most of the people run subsurface from a location that
> is not writable by the said user. At least the Ubuntu packaging does
> that. I think we should have all the modifiable stuff in the
> .subsurface directory, or whatever the default log storage location
> happens to be. The shipped templates and all should reside in read
> only area (whether it is dir permission or ro mounted bundle).
>

but we do support in-place editing of the bundled templates. we even
added a special warning for that. :\
so they have to be in a RW location.

> BTW I always thought that OSX uses similar software bundles, at least
> I thought one cannot write to them.

OSX does something very similar to an AppImage, i think.
and i have no idea how they handle the whole huge CAD updater scenario
that i'm proposing...they probably don't handle that very well.

>
>>>> 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.
>
> I just see this so that we should have all the data that is edited
> somewhere under user's home directory, just the way we currently have
> the XML log or git cache. There should not be any need for editing the
> actual shipped software or the related files. Development is totally
> different issue, and generally I see the AppImage used only for
> delivering the software to end users, re-create it from scratch when
> needed with updated content...
>

for RW files, i guess it has to use scripts to deploy said RW files to
a RW location.
but then these files will exist both in the AppImage as R and in the
RW location as RW.

seems a bit odd to me - unless the AppImage itself is a RW FS or if a
--install method is implemented.
there is also the option to download RW files and only store R files
in the AppImage, but the downsides of that are more than the upsides
IMHO - e.g. a mandatory internet connect.

lubomir
--