Le 07/11/2015 21:18, Pavel Sanda a écrit :
Guillaume Munch wrote:
Have a new checkbox in document settings labelled "Open with change
tracking enabled". Then the current state of change tracking is made
independent from this checkbox; only, if the box is checked then it will
do as advertised by the label. Otherwise, the per-user, per-session
setting is restored.
This seems to fit better than the current situation what I understand of
Pavel and other people's use case for change tracking. Indeed, even in
My summary is quite different. The current situation seems to be more in
tune with what most people expect and what other offices are doing.
Hi Pavel,
Thank you for making these suggestions. I see that you suggest small
variations on adding a new setting, so I am happy to see some convergence.
That said I understand your pain and agree that it sucks for version control
usecase. My take on that would be one of those directions:
1. User preference for ignoring CT toggling changes during the session.
The CT on/off status would be saved in the same way as it was opened
no matter whether the user changed it during editing.
So a "Save change tracking within document" per-user checkbox. The
difference with a suggestion à la Vincent are that the current status of
change tracking is saved, and it is per-user instead of per-document.
I had thought about it, and it makes more sense to me as a per-document
setting than as a per-user setting to me. Then, if it's per-document, I
do not see the need to add an additional indirection via the current CT
state, so we can let the checkbox directly determine the state on
opening. This is why I was convinced by the "Open with change tracking
enabled" checkbox.
2. Some form of turn on/off permanently vs intermittently, both in menu
or it could be tristate. (Code-wise it might be similar to 1. I am
thinking more how it appears in GUI to the user.)
Well the idea of a tri-state button was what I elaborated with the "CT
lock" suggestion (up to minor differences). I imagined a "lock" button
next to the current button and activating the lock activates the usual
button at the same time, so in practice it was really a tri-state
setting. But then I needed a way to make the interface worthwhile and
intuitive so I suggested that deactivating the lock shows a confirmation
prompt to the user, but then it was too much "bells and whistles"
according to replies. Logic and file-wise, yes it's very similar to the
previous one and it would reuse \tracking_changes as well (as I had
suggested it, we would also have needed to record who activated the lock
but this was inessential).
3. General preference (not sure if document or user) for ignoring non essential
changes, which disturbs version control flow. Similar to 1. but it
would encompass e.g. CT on/off, output_changes, GUI justification.
I have another candidate here as well - not storing opening/closing insets.
So essentially a single setting for all user-like document settings.
You had convinced me with your "open/closed inset" point that actually
LyX records more than I previously thought the current state of user
preferences inside files, while my point was that it seems to me that
this less LyX's philosophy than e.g. LibreOffice's. I also like the idea
that storing the open/closed state of insets may not always be what we want.
But I thought about it more. If the state of insets is lost, then we
have to revert to a default state where all the insets are either open
or closed. While for some insets I would no mind to lose the state,
losing it for all insets looks like a dataloss to me. So we cannot
afford to store as user settings things that could cause dataloss.
Also it looks technically challenging to me to store the state of insets
as user settings. So I am no longer convinced that not storing
open/closed state of insets is feasible and realistic.
Still, a single "git compatibility mode" per-document setting would
satisfy me equally. But, would it really encompass more than the two
change-tracking settings? (\justification seems a different case to me
as I am still convinced that it should be purely per-user.)
It comes down to whatever is LyX's philosophy: do we want to store user
settings in files? Then let's add a "git mode" per-document setting. Or
do we want user settings never to be stored within files? Then make CT
per-user-per-document, and add a "Open with CT enabled" per-document
setting.
Guillaume
