On 19/11/2017 21:13, Lubomir I. Ivanov wrote:
@willemferguson <https://github.com/willemferguson>
even if the new template is an improvement over the old one i do not
question which one is better. we just need to name it differently and
here is why - as a summary of the template installation process:
* the user already has subsurface installed with templates copied to
his user folder
this is done only on the first subsurface run and from that point
on we do not touch the user templates
[1] he/she may or may not had made changes to those templates
* we update the bundled templates with subsurface
* user downloads the latest version of subsurface
* by downloading the latest version of subsurface where we modify
the existing template X, user would not see this new template as
we *do not* overwrite the existing templates which are already in
the user folder because of [1].
this means that the users will not see a *new template* with the same
name, because we won't overwrite his existing one.
like i've said in the other PR/thread, the only reasonable mechanic
for updating user templates without a complicated UI for that, is to
provide a ZIP file at the website with a link |Latest printing
templates|. the user then can decide if he/she wants to accept the
download and install it in his user folder.
we can maintain the contents of the ZIP file in a separate GIT
repository. if new templates, with new names are introduced we can
include them in subsurface, as those will be copied to the user folder
the first time subsurface finds out that the user does not have them.
does that explain the situation?
—
Lubomir,
Effective communication is indeed difficult. What I read in your
previous mail was totally different from what you had intended to
communicate. My humble apologies for being rather reactive than being
more understanding. I will try to read more carefully in future.
There is a principle at stake which is not healthy at all, and this is
the perpetuation of old or faulty print templates. When a new version of
Subsurface is run the first time, all existing (or call them system
templates) templates should be installed in the user area. If anyone
edits an existing template without saving it under a different name,
these edits should not be considered as permanent.
A template could in principle be faulty and one would like to have a way
of recovering from this. The template edit mechanism in Subsurface
allows for exporting a template, but not for saving it under a different
name. What happens if someone edits the html/css/django code and messes
it up by saving a faulty template by hitting the Apply button? The
original One Dive template has now been damaged, saved (and possibly
exported), which leaves the existing One Dive template nonfunctional
without a simple mechanism to get an undamaged version, even if a new
version of Subsurface is installed. I am talking now of the average
non-programmer who does not understand the inside workings of Subsurface
and who has probably installed from the Linux repository or the
Subsurface download site and who has no idea of where in the file
structure the various resources are and does not even know of the
.subsurface directory.
To improve the state of affairs, two changes are necessary:
1) when editing a print template within Subsurface, one should be forced
to save it under a different name. Currently it overwrites the existing
template. The Apply button in the print dialog for editing templates
should therefore rather be Save As..
2) if you feel serious about a .zip file with a print template files,
then the print dialog should have a button "Get latest print templates"
that goes through the appropriate actions.
3) At install or upgrade time, all system print templates are written to
the user area.
I hope my argument sounds reasonable.
Kind regards,
willem
--
This message and attachments are subject to a disclaimer.
Please refer to
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf for full
details.
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
