On 18 October 2015 at 15:29, Miika Turkia <[email protected]> wrote: > On Sun, Oct 18, 2015 at 3:14 PM, Lubomir I. Ivanov <[email protected]> > wrote: >> On 18 October 2015 at 14:26, probono <[email protected]> wrote: >>> 2015-10-18 12:50 GMT+02:00 Lubomir I. Ivanov <[email protected]>: >>>> 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 -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
