Nightly Subsurface AppImage for most Linux distributions

[Miika Turkia]

On Sun, Oct 18, 2015 at 7:50 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> On Oct 18, 2015, at 9:09 AM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>
>> On 18 October 2015 at 18:45, Miika Turkia <miika.turkia at gmail.com> wrote:
>>> On Sun, Oct 18, 2015 at 6:35 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>> On 18 October 2015 at 18:21, Dirk Hohndel <dirk at hohndel.org> wrote:
>>>>>
>>>>> So please, someone volunteer to copy the templates to a subdirectory of our
>>>>> system default directory and always look there FIRST, before looking at the
>>>>> system provided templates. And then you can add a "reset" function where you
>>>>> simply delete the user specific copy and magically the shipped template will
>>>>> reappear.
>>>>>
>>>>
>>>> will send a patch later tonight.
>>>
>>> How about saving only the user modified templates to homedir and keep
>>> the shipped templates in the installed or AppImage location? Thus we
>>> could always have our own templates available and users can add to
>>> that.
>>>
>>
>> i will do the following, unless someone objects:
>>
>> - i disable the in-place editing of bundled templates
>> the warning instead of saying (rough text) "you are about to save a
>> bundled template" will now say "this is a bundled template, please
>> export first).
>> - the Import/Export dialog will now open the
>> ~/subsurface/printing_templates by default.
>> - files from both read-only-path/subsurface/printing_templates and
>> ~/subsurface/printing_templates will be used to populate the lists in
>> the Template combo box.
>>
>> this allows us to update the bundled templates while still load the
>> user created/exported/imported templates in ~.
>
> So we are back to "the shipped templates stay immutable" and the user adds
> additional templates. I thought we decided against that. But I see your point
> that with your logic the users will get to benefit from added templates.
>
> In my version (you can edit and save with the existing name) the number of
> templates shown doesn't go up. And I wonder how often and significantly we'll
> change the shipped templates. And in either case, the change doesn't magically
> get merged into the modifications... so I think I like mine better.
>
> The shipped templates stay where they are and don't get overwritten. If the
> user edits one of the templates, then the modified template is written into
> <systemdefaultdir>/pinting_templates/<same template name> by default,
> but the user can opt to pick a different name.
>
> If the user keeps the name, this is the template they see instead of the
> shipped template of that name. So the template loading logic needs to
> be modified to FIRST look at the <systemdefaultdir> location, and then
> at the others if there's no such file there.
>
> Makes sense?

I see the benefits of both paths. And now that I think of it, giving
the user power to create new templates or seemingly overwrite the
stock ones does have its benefits. Having only the needed choices on
the list is better than a too long list...Especially if we have the
option to revert to the shipped version.

miika