Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 21:04, Guillaume Munch a écrit :


For instance, \origin is going to cause problems if any collaborator
through a VCS decides to store his own local path (which is a setting
global to lyx!). Should we not set \origin unavailable when
store_user_preferences is false? (I am seriously asking)



There is now a ticket about this, with a patch, at 
. I do not think that it's 
important to have this before the release, but I mention it just in case.

Re: User pref parameters

[Pavel Sanda]

Guillaume Munch wrote:
> I am not convinced by the naming vcs_simplify_format but maybe there are
> other suggestions? What about save_transient_properties or save_state ?

I am fine with save_transient_properties as well. P

Re: User pref parameters

[Georg Baum]

Pavel Sanda wrote:

> Guillaume Munch wrote:
>> I am not convinced by the naming vcs_simplify_format but maybe there are
>> other suggestions? What about save_transient_properties or save_state ?
> 
> I am fine with save_transient_properties as well. P

me too (and I do not like vcs_simplify_format, since this is really not 
limited to using a vcs).


Georg

Re: User pref parameters

[Scott Kostyshak]

On Tue, Jan 12, 2016 at 05:18:40PM +, Guillaume Munch wrote:
> Le 12/01/2016 02:23, Pavel Sanda a écrit :
> >Guillaume Munch wrote:

> Scott, do you sum up all these messages as a "+1", as you say?

After a quick look, I do think there is a +1.

Scott


signature.asc
Description: PGP signature

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 19:36, Georg Baum a écrit :

Pavel Sanda wrote:


Guillaume Munch wrote:

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?


I am fine with save_transient_properties as well. P


me too (and I do not like vcs_simplify_format, since this is really not
limited to using a vcs).





Yet transient is not entirely accurate either.

For instance, \origin is going to cause problems if any collaborator
through a VCS decides to store his own local path (which is a setting
global to lyx!). Should we not set \origin unavailable when
store_user_preferences is false? (I am seriously asking)

Re: User pref parameters

[Guillaume Munch]

Le 12/01/2016 02:23, Pavel Sanda a écrit :

Guillaume Munch wrote:

I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.


Yep, that's basically the same conflict which started the whole issue
("choosing a setting for everybody else"). You know my opinion about the
issue, but since you are the one who implements it and there is indeed
partial overlap with "\save_user_preferences true" go ahead :)

Cosmetic thing - the naming "save_user_preferences" is confusing precisely
because there are diverging opinions what user vs document pref is
so maybe using for file format something like vcs_simplify_format
or similar would be better.




Thanks.

I am not convinced by the naming vcs_simplify_format but maybe there are
other suggestions? What about save_transient_properties or save_state ?
I would rather avoid a name that refers to a particular purpose rather
than the actual effect.


Scott, do you sum up all these messages as a "+1", as you say?

Re: User pref parameters

[Kornel Benko]

Am Montag, 11. Januar 2016 um 11:14:30, schrieb Jean-Marc Lasgouttes 

> Le 11/01/2016 11:07, Pavel Sanda a écrit :
> > Kornel Benko wrote:
> >> This all is getting more and more confusing. Too complicated (at least for 
> >> me)
> >
> > You edit document.
> > You decide to use git.
> > You set up the look/behaviour things your care about ('Is CT ON/OFF')
> > You freeze those settings so working with git is less annoying.
> 
> This is an issue I had too. Freezing settings seems more interesting 
> that setting them to false. It is more work too, maybe too much work 
> actually.
> 
> JMarc

Why on earth should it be in the lyx-file? The above reads as if it were a user 
selection for this file.
No need to save it in the file.
Yes, I understood the problem of a collaborative user opening this file the 
first time.
But he has it too, if the value is default in the lyx file.
And if it is not default, so he has to define it for himself anyway to be on 
the safe side.

'Freeze the behaviour for me (one way or another)' is all one needs IMHO.

Kornel


signature.asc
Description: This is a digitally signed message part.

Re: User pref parameters (was: [patch] Display the correct horizontal alignment in AMS environments)

[Kornel Benko]

Am Montag, 11. Januar 2016 um 01:38:28, schrieb Pavel Sanda 
> Georg Baum wrote:
> > Guillaume Munch wrote:
> > 
> > > I agree that the current situation regarding \output_change and
> > > \tracking_change is bad and should be fixed. I gave what I think is the
> > > proper solution, taking into account the debate that was on the list.
> > > The patch is very simple (see the earlier message:
> > > http://article.gmane.org/gmane.editors.lyx.devel/159493 and:
> > > http://www.lyx.org/trac/ticket/9841). Now what we would need for such a
> > > change is if developers who took part in the discussion looked and say:
> > > yes, this is the proper solution. I do not see this happening right now.
> > 
> > I guess because of the mailing list outage the mail has been forgotten.
> > 
> > I looked at the patches in http://www.lyx.org/trac/ticket/9841, and I think 
> > it is a good implementation of the consensus that has been reached earlier. 
> > You have a +1 from me, but because this has been discussed with some strong 
> > opinions I suggest that there should be more reviews.
> 
>   14  2015-12-20 Guillaume Munch  
>   15  * Format incremented to 504 
>   16New parameter "\store_user_preferences". When set to 
> false, various 
>   17settings are no longer written to the file (only with 
> a default 
>   18value). These include for now \tracking_changes and 
> \output_changes. See 
> 
> Isn't it more reasonable to have this variable to "freeze" the current
> setting (i.e. the setting which is active when we enable freeze) instead
> resetting things to default?
> 
> Pavel

This all is getting more and more confusing. Too complicated (at least for me)

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: User pref parameters (was: [patch] Display the correct horizontal alignment in AMS environments)

[Pavel Sanda]

Kornel Benko wrote:
> This all is getting more and more confusing. Too complicated (at least for me)

You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.

.. and sometimes you remove parts of the emails you do not directly reply to :) 
..
Pavel

Re: User pref parameters

[Jean-Marc Lasgouttes]

Le 11/01/2016 11:07, Pavel Sanda a écrit :

Kornel Benko wrote:

This all is getting more and more confusing. Too complicated (at least for me)


You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.


This is an issue I had too. Freezing settings seems more interesting 
that setting them to false. It is more work too, maybe too much work 
actually.


JMarc

Re: User pref parameters

[Pavel Sanda]

Guillaume Munch wrote:
> I understand this idea of "freezing" the setting, in order to set a
> custom value on opening. The current approach I have in mind is to read
> and save to a per-user-per-document (cursor-location-like) setting when
> save_user_preferences is false, so that the value on opening corresponds
> to the user's previous session. The two approaches are in conflict, so
> one has to choose between the two.

Yep, that's basically the same conflict which started the whole issue
("choosing a setting for everybody else"). You know my opinion about the
issue, but since you are the one who implements it and there is indeed
partial overlap with "\save_user_preferences true" go ahead :)

Cosmetic thing - the naming "save_user_preferences" is confusing precisely
because there are diverging opinions what user vs document pref is
so maybe using for file format something like vcs_simplify_format
or similar would be better.

Pavel

Re: User pref parameters

[Stephan Witt]

Am 11.01.2016 um 12:01 schrieb Kornel Benko :
> 
> Am Montag, 11. Januar 2016 um 11:14:30, schrieb Jean-Marc Lasgouttes 
> 
>> Le 11/01/2016 11:07, Pavel Sanda a écrit :
>>> Kornel Benko wrote:
 This all is getting more and more confusing. Too complicated (at least for 
 me)
>>> 
>>> You edit document.
>>> You decide to use git.
>>> You set up the look/behaviour things your care about ('Is CT ON/OFF')
>>> You freeze those settings so working with git is less annoying.
>> 
>> This is an issue I had too. Freezing settings seems more interesting 
>> that setting them to false. It is more work too, maybe too much work 
>> actually.
>> 
>> JMarc
> 
> Why on earth should it be in the lyx-file?

Since it is logically tied to the file contents, IMHO.
If I want change tracking I want it regardlessly of the
location of the document. It doesn’t matter if I copy it
to another computer or upload it to drop-box or save it
in a git repository.

I know, there are other opinions here. But that’s mine.

Stephan
 
> The above reads as if it were a user selection for this file.
> No need to save it in the file.
> Yes, I understood the problem of a collaborative user opening this file the 
> first time.
> But he has it too, if the value is default in the lyx file.
> And if it is not default, so he has to define it for himself anyway to be on 
> the safe side.
> 
> 'Freeze the behaviour for me (one way or another)' is all one needs IMHO.
> 
>   Kornel

Re: User pref parameters

[Jean-Marc Lasgouttes]

Le 11/01/2016 16:33, Guillaume Munch a écrit :

Thus the per-user approach encompasses a wider set of use-cases,
overlaps less with the current behaviour, and is simpler to explain and
understand. Moreover, storing always the same value "false" is similar
to what is done in LibreOffice's corresponding feature (saving to the
.fodt format).


I kind of forgot about the per-user store. Your proposition of storing 
"false" is OK to me.


JMarc

Re: User pref parameters

[Guillaume Munch]

Le 11/01/2016 10:14, Jean-Marc Lasgouttes a écrit :

Le 11/01/2016 11:07, Pavel Sanda a écrit :

Kornel Benko wrote:

This all is getting more and more confusing. Too complicated (at
least for me)


You edit document.
You decide to use git.
You set up the look/behaviour things your care about ('Is CT ON/OFF')
You freeze those settings so working with git is less annoying.


This is an issue I had too. Freezing settings seems more interesting
that setting them to false. It is more work too, maybe too much work
actually.




Dear Pavel and Jean-Marc,


I understand this idea of "freezing" the setting, in order to set a
custom value on opening. The current approach I have in mind is to read
and save to a per-user-per-document (cursor-location-like) setting when
save_user_preferences is false, so that the value on opening corresponds
to the user's previous session. The two approaches are in conflict, so
one has to choose between the two.

I see several drawbacks to "freezing":

* With "freezing", the user must know what settings are going to be
affected. This means a heavier description in the user interface, and a
feature less easy to understand.

* This is only relevant for scenarios where we want the same setting on
opening for all collaborators (or where one user
knows-better-than-everybody-else). As soon as there is no agreement, we
are back to the situation that we were trying to solve.

* The use-case of "choosing a setting for everybody else" overlaps with
the current behaviour provided by "\save_user_preferences true".

* On the other hand, it does not address the need for having the
settings entirely independent between collaborators.

Thus the per-user approach encompasses a wider set of use-cases,
overlaps less with the current behaviour, and is simpler to explain and
understand. Moreover, storing always the same value "false" is similar
to what is done in LibreOffice's corresponding feature (saving to the
.fodt format).


Guillaume

Re: User pref parameters

[Georg Baum]

Guillaume Munch wrote:

> Thus the per-user approach encompasses a wider set of use-cases,
> overlaps less with the current behaviour, and is simpler to explain and
> understand. Moreover, storing always the same value "false" is similar
> to what is done in LibreOffice's corresponding feature (saving to the
> .fodt format).

I agree. Those who want to set per-document values for all collaborators 
should set save_user_preferences to true. In this case they need to agree on 
the wanted settings anyway, like it is now.


Georg