On Sun, Oct 18, 2015 at 7:50 PM, Dirk Hohndel <[email protected]> wrote: > >> On Oct 18, 2015, at 9:09 AM, Lubomir I. Ivanov <[email protected]> wrote: >> >> On 18 October 2015 at 18:45, Miika Turkia <[email protected]> wrote: >>> On Sun, Oct 18, 2015 at 6:35 PM, Lubomir I. Ivanov <[email protected]> >>> wrote: >>>> On 18 October 2015 at 18:21, Dirk Hohndel <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
