subject:"Re\: Restart layout update discussion; was\: Re\: \[patch\] final layout patches for branch"


Am 26.01.2013 18:23, schrieb Jürgen Spitzmüller:


I cannot reproduce the failure you get when removing the linebreak. I can
reproduce the failure with a different theme. But I cannot see how the layout
update fixes this. Instead, the error goes away if the address declaration in
the preamble is the same than the one in trunk, i.e.


OK. I will fix this then.

But the theme problem persists. I don't know why but this does not occur with 
the new layout in trunk.

thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 28.01.2013 03:07, schrieb Uwe Stöhr:


OK. I will fix this then.


This cannot be fixed, because in trunk the new default theme is used. in branch I cannot use this 
because the document will then become uncompilable. The linebreak is necessary to get the city in 
its own line. This is a requirement for some job applications. At least that was once reported to me.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
 I don't know why but this does not occur with the new layout in trunk.

Of course it does. See attached document. Or show me how to insert a linebreak 
in the address layout with the casual theme in the new layout that does _not_ 
trigger a error.

Jürgen


modernCV-trunk.lyx
Description: application/lyx

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
 This cannot be fixed, because in trunk the new default theme is used. in
 branch I cannot use this  because the document will then become
 uncompilable. 

No it won't. Attached is a branch version that compiles with the casual theme. 
All I did here is changing the theme and removing the linebreak in the address 
(I also commented out the photo, since I don't attach the graphic).

 The linebreak is necessary to get the city in its own line.
 This is a requirement for some job applications. At least that was once
 reported to me.

Look, the problem is that some modernCV themes (casual, which has the address 
information in the footer) do not support linebreaks in the address field. The 
branch example fails if you switch to this theme, because you have linebreaks 
in the address. If you remove the linebreaks, the errors go away. The trunk 
example, on the other hand, works, since there is _no_ linebreak in the 
address. If you add a linebreak,the errors will be there.

So the problem is in modernCV. Actually, I think the real solution to this 
problem would be adding a \country macro in modernCV. After all, the theme 
determines where the country is placed -- on its own line or in the same line 
after an endash. The linebreak error should of course be fixed nevertheless by 
the modernCV author.

As for the examples, you should document in the preamble that \protect'ed 
linebreaks can be used in the classic layout to put the country on its own 
line, but that such linebreaks will produce errors in the casual layout -- and 
this holds for branch and trunk.

Jürgen


modernCV-branch.lyx
Description: application/lyx

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 26.01.2013 18:23, schrieb Jürgen Spitzmüller:


I cannot reproduce the failure you get when removing the linebreak. I can
reproduce the failure with a different theme. But I cannot see how the layout
update fixes this. Instead, the error goes away if the address declaration in
the preamble is the same than the one in trunk, i.e.


OK. I will fix this then.

But the theme problem persists. I don't know why but this does not occur with 
the new layout in trunk.

thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 28.01.2013 03:07, schrieb Uwe Stöhr:


OK. I will fix this then.


This cannot be fixed, because in trunk the new default theme is used. in branch I cannot use this 
because the document will then become uncompilable. The linebreak is necessary to get the city in 
its own line. This is a requirement for some job applications. At least that was once reported to me.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
> I don't know why but this does not occur with the new layout in trunk.

Of course it does. See attached document. Or show me how to insert a linebreak 
in the address layout with the casual theme in the new layout that does _not_ 
trigger a error.

Jürgen


modernCV-trunk.lyx
Description: application/lyx

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
> This cannot be fixed, because in trunk the new default theme is used. in
> branch I cannot use this  because the document will then become
> uncompilable. 

No it won't. Attached is a branch version that compiles with the casual theme. 
All I did here is changing the theme and removing the linebreak in the address 
(I also commented out the photo, since I don't attach the graphic).

> The linebreak is necessary to get the city in its own line.
> This is a requirement for some job applications. At least that was once
> reported to me.

Look, the problem is that some modernCV themes (casual, which has the address 
information in the footer) do not support linebreaks in the address field. The 
branch example fails if you switch to this theme, because you have linebreaks 
in the address. If you remove the linebreaks, the errors go away. The trunk 
example, on the other hand, works, since there is _no_ linebreak in the 
address. If you add a linebreak,the errors will be there.

So the problem is in modernCV. Actually, I think the real solution to this 
problem would be adding a \country macro in modernCV. After all, the theme 
determines where the country is placed -- on its own line or in the same line 
after an endash. The linebreak error should of course be fixed nevertheless by 
the modernCV author.

As for the examples, you should document in the preamble that \protect'ed 
linebreaks can be used in the classic layout to put the country on its own 
line, but that such linebreaks will produce errors in the casual layout -- and 
this holds for branch and trunk.

Jürgen

modernCV-branch.lyx
Description: application/lyx

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-26 Thread Uwe Stöhr


Am 26.01.2013 05:05, schrieb Uwe Stöhr:


Damn, you are right.


Damn me, of course you were not right. As soon as you e.g. change something in the example file it 
becomes uncompilable. Use for example another theme or remove the linebreak in the address.


I now nevertheless reverted everything and leave the layout broken as it is in 
branch.

regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-26 Thread Jürgen Spitzmüller

Uwe Stöhr wrote:
 As soon as you e.g. change something in the example file it 
 becomes uncompilable. Use for example another theme or remove the linebreak
 in the address.

I cannot reproduce the feilure you get when removing the linebreak. I can 
reproduce the failure with a different theme. But I cannot see how the layout 
update fixes this. Instead, the error goes away if the address declaration in 
the preamble is the same than the one in trunk, i.e.

\address{Teststreet 17}{0 Nicecity -- Switzerland}

instead of

\address{Teststreet 17}{0 Nicecity\protect\\[0.1em] 
Switzerland\protect\\[0.2em]}

If I put in a (protected) linebreak in the address declaration of the trunk 
version, I get exactly the same error.

So I really fail to see how the layout update is relevant here. However, I 
would propose to change the preamble layout definition in branch accordingly.

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-26 Thread Uwe Stöhr


Am 26.01.2013 05:05, schrieb Uwe Stöhr:


Damn, you are right.


Damn me, of course you were not right. As soon as you e.g. change something in the example file it 
becomes uncompilable. Use for example another theme or remove the linebreak in the address.


I now nevertheless reverted everything and leave the layout broken as it is in 
branch.

regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-26 Thread Jürgen Spitzmüller

Uwe Stöhr wrote:
> As soon as you e.g. change something in the example file it 
> becomes uncompilable. Use for example another theme or remove the linebreak
> in the address.

I cannot reproduce the feilure you get when removing the linebreak. I can 
reproduce the failure with a different theme. But I cannot see how the layout 
update fixes this. Instead, the error goes away if the address declaration in 
the preamble is the same than the one in trunk, i.e.

\address{Teststreet 17}{0 Nicecity -- Switzerland}

instead of

\address{Teststreet 17}{0 Nicecity\protect\\[0.1em] 
Switzerland\protect\\[0.2em]}

If I put in a (protected) linebreak in the address declaration of the trunk 
version, I get exactly the same error.

So I really fail to see how the layout update is relevant here. However, I 
would propose to change the preamble layout definition in branch accordingly.

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 21.01.2013 22:15, schrieb Georg Baum:


That is what I always stated, non of my changes (except of that nasty
modernCV beast) break the backward-compatibility in the strict sense but
they introduce new commands and that is what this thread is about.


Yes. In the beginning, I thought that these new commands are urgently
needed, and that you therefore want them in the stable release. Now I
learned that none of the new commands is urgently needed


But this is not correct. For example the new commands for the ACM classes are needed and also the 
new commands in the IEEE class will soon be necessary to be able to submit papers.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 22.01.2013 15:19, schrieb Jürgen Spitzmüller:


You added 14 styles of InPreamble type (CVStyle, CVColor, FirstName,
FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo,
Photo and Quote).

None of these are needed to keep the layout working with recent releases of
moderncv, since all these statements can still be given via the preamble, as
it is the case in current LyX releases.


This is correct. The problem I was facing was that modernCV could not be compiled. I played a long 
time to get it compilable but failed, I therefore started to rewrite the layout bit by bit. I 
therefore of course added new styles. I will have a look what can go and what styles are still 
necessary.



On the contrary, I think such a huge number of new layouts require a file
format change, and lyx2lyx should write those layouts into the preamble on
reversion


As said modernCV was not compilable using recent versions of modernCV. Therefore I cannot tell what 
needs to be reverted to what. It is dependent on the used version of modernCV.



Since the changes are so multitude, this is clearly not something we would
like to do just within a maintenance release cycle.


I fully agree because it is annoying to be forced to update existing files. But I now several times 
tried to get it to work without success.

I will have a final look tomorrow and either find a solution or revert and 
leave it broken.

regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 22.01.2013 15:45, schrieb Jürgen Spitzmüller:


I now also reverted your changes locally, and it turns out that the (old)
moderncv example file still works without any single problem with the old
layout. This is with most recent TL (2012/12/04 v1.2.1 of moderncv.cls).


Damn, you are right. I don't understand this anymore! With 1.2.0 it did definitively not compile. 
Give me a day and I'll fix it and also add some lyx2lyx code for trunk.


thanks for being insisting here and best regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 21.01.2013 22:15, schrieb Georg Baum:


That is what I always stated, non of my changes (except of that nasty
modernCV beast) break the backward-compatibility in the strict sense but
they introduce new commands and that is what this thread is about.


Yes. In the beginning, I thought that these new commands are urgently
needed, and that you therefore want them in the stable release. Now I
learned that none of the new commands is urgently needed


But this is not correct. For example the new commands for the ACM classes are needed and also the 
new commands in the IEEE class will soon be necessary to be able to submit papers.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 22.01.2013 15:19, schrieb Jürgen Spitzmüller:


You added 14 styles of "InPreamble" type (CVStyle, CVColor, FirstName,
FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo,
Photo and Quote).

None of these are needed to keep the layout working with recent releases of
moderncv, since all these statements can still be given via the preamble, as
it is the case in current LyX releases.


This is correct. The problem I was facing was that modernCV could not be compiled. I played a long 
time to get it compilable but failed, I therefore started to rewrite the layout bit by bit. I 
therefore of course added new styles. I will have a look what can go and what styles are still 
necessary.



On the contrary, I think such a huge number of new layouts require a file
format change, and lyx2lyx should write those layouts into the preamble on
reversion


As said modernCV was not compilable using recent versions of modernCV. Therefore I cannot tell what 
needs to be reverted to what. It is dependent on the used version of modernCV.



Since the changes are so multitude, this is clearly not something we would
like to do just within a maintenance release cycle.


I fully agree because it is annoying to be forced to update existing files. But I now several times 
tried to get it to work without success.

I will have a final look tomorrow and either find a solution or revert and 
leave it broken.

regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 22.01.2013 15:45, schrieb Jürgen Spitzmüller:


I now also reverted your changes locally, and it turns out that the (old)
moderncv example file still works without any single problem with the old
layout. This is with most recent TL (2012/12/04 v1.2.1 of moderncv.cls).


Damn, you are right. I don't understand this anymore! With 1.2.0 it did definitively not compile. 
Give me a day and I'll fix it and also add some lyx2lyx code for trunk.


thanks for being insisting here and best regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
  The same holds for moderncv. The author does support backward
  compatibility so I would be interested to see what actually does not work
  anymore.
 
 I had a look today and I cannot fiddle it out. The underlying table
 structure until modernCV 1.0  makes it complicated. With almost every
 release I found bugs and reported them to the modernCV maintainer. But
 during last summer I lost track and cannot tell which version needs what.
 As my spare time is very limited I cannot work further on this.
 But let's live with this limitations. Since modernCV 1.x the things are much
 easier and I think for  the future backward compatibility will be much
 easier.

I had a look for you and checked the changes 
(http://www.lyx.org/trac/changeset/58f6767e2c/lyxgit#file1)

(1)

You added 14 styles of InPreamble type (CVStyle, CVColor, FirstName, 
FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo, 
Photo and Quote).

None of these are needed to keep the layout working with recent releases of 
moderncv, since all these statements can still be given via the preamble, as 
it is the case in current LyX releases.

On the contrary, I think such a huge number of new layouts require a file 
format change, and lyx2lyx should write those layouts into the preamble on 
reversion


(2)

You added 5 required arguments to the style entry. This is a file format 
change in itself, since these argument _must_ be reverted to ERT. The change 
itself is also not urgently needed. We can still use the ERT braces 
workaround, as done before.

Same for DoubleItem.


(3)

The \cvitem command now has a required instead of an optional argument. I 
cannot find a corresponding change in the modernsv changelog, so I suppose the 
syntax was always like this, and this is just an attempt to reduce ERT.

= Not strictly needed for branch


(4)

New styles: ItemWithComment, DoubleListItem, MakeCVtitle, MakeLetterTitle, 
MakeLetterClosing, Recipient, Date, Opening, Closing, Enclosing

These are indeed new commands as of moderncv 1.0, but these are new features, 
and not providing them will not break moderncv support.


The remaining changes are cosmetic.


In sum: As much as these changes enhance the support for moderncv, none of 
them is really needed to keep moderncv working.

Since the changes are so multitude, this is clearly not something we would 
like to do just within a maintenance release cycle. On the contrary, with 
regard to the massive changes I would really argue in this case that we need 
either a new layout or -- even better -- add proper conversion/reversion 
routines, as I've done for beamer.

 If you disagree feel free to modify the layout as you think it should be.

No, this is your responsibility.

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Jürgen Spitzmüller wrote:
 In sum: As much as these changes enhance the support for moderncv, none of 
 them is really needed to keep moderncv working.

I now also reverted your changes locally, and it turns out that the (old) 
moderncv example file still works without any single problem with the old 
layout. This is with most recent TL (2012/12/04 v1.2.1 of moderncv.cls).

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:
> > The same holds for moderncv. The author does support backward
> > compatibility so I would be interested to see what actually does not work
> > anymore.
> 
> I had a look today and I cannot fiddle it out. The underlying table
> structure until modernCV 1.0  makes it complicated. With almost every
> release I found bugs and reported them to the modernCV maintainer. But
> during last summer I lost track and cannot tell which version needs what.
> As my spare time is very limited I cannot work further on this.
> But let's live with this limitations. Since modernCV 1.x the things are much
> easier and I think for  the future backward compatibility will be much
> easier.

I had a look for you and checked the changes 
(http://www.lyx.org/trac/changeset/58f6767e2c/lyxgit#file1)

(1)

You added 14 styles of "InPreamble" type (CVStyle, CVColor, FirstName, 
FamilyName, Title, Address, Mobile, Phone, Fax, Email, Homepage, ExtraInfo, 
Photo and Quote).

None of these are needed to keep the layout working with recent releases of 
moderncv, since all these statements can still be given via the preamble, as 
it is the case in current LyX releases.

On the contrary, I think such a huge number of new layouts require a file 
format change, and lyx2lyx should write those layouts into the preamble on 
reversion

(2)

You added 5 required arguments to the style "entry". This is a file format 
change in itself, since these argument _must_ be reverted to ERT. The change 
itself is also not urgently needed. We can still use the ERT braces 
workaround, as done before.

Same for DoubleItem.

(3)

The \cvitem command now has a required instead of an optional argument. I 
cannot find a corresponding change in the modernsv changelog, so I suppose the 
syntax was always like this, and this is just an attempt to reduce ERT.

=> Not strictly needed for branch

(4)

New styles: ItemWithComment, DoubleListItem, MakeCVtitle, MakeLetterTitle, 
MakeLetterClosing, Recipient, Date, Opening, Closing, Enclosing

These are indeed new commands as of moderncv 1.0, but these are new features, 
and not providing them will not break moderncv support.

The remaining changes are cosmetic.

In sum: As much as these changes enhance the support for moderncv, none of 
them is really needed to keep moderncv working.

Since the changes are so multitude, this is clearly not something we would 
like to do just within a maintenance release cycle. On the contrary, with 
regard to the massive changes I would really argue in this case that we need 
either a new layout or -- even better -- add proper conversion/reversion 
routines, as I've done for beamer.

> If you disagree feel free to modify the layout as you think it should be.

No, this is your responsibility.

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Jürgen Spitzmüller wrote:
> In sum: As much as these changes enhance the support for moderncv, none of 
> them is really needed to keep moderncv working.

I now also reverted your changes locally, and it turns out that the (old) 
moderncv example file still works without any single problem with the old 
layout. This is with most recent TL (2012/12/04 v1.2.1 of moderncv.cls).

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 21/01/13 00:51, Uwe Stöhr a écrit :

Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:


The same holds for moderncv. The author does support backward
compatibility so I would be interested
to see what actually does not work anymore.


I had a look today and I cannot fiddle it out. The underlying table
structure until modernCV 1.0 makes it complicated. With almost every
release I found bugs and reported them to the modernCV maintainer. But
during last summer I lost track and cannot tell which version needs
what.


Thanks for checking that.

JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 21/01/13 00:55, Uwe Stöhr a écrit :

Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:


We also have the right to consider the new commands and the necessity
to support them right _now_.
It may be that they are really required, but I bet that in many cases
they will only correspond to
corner cases.


But only sometimes. That is no acuse for not providing everything that
might be demanded by a journal.


Sure, but it has to be done case-by-case. My point is that the argument 
should not be all layouts should be updated to match the latest version 
strctly. There are cases where the macros are just deprecated and 
should eventually be replaced. I think using the deprecated versions is 
good enough during stable releases.



You still don't understand what I tried to explain so many times. In
case of the journal classes it is not the choice of the user or our
choice. The publisher forces you to do what he wants or you cannot commit.


OK, I was joking (you know me by now; don't you?). But the serious part 
in there is that there is no general rule, every journal is a special case.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:

 Am 15.01.2013 22:24, schrieb Georg Baum:
 
 IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather
 the oppsosite. And I'd really like to see _one_ example of an updated
 journal/conference .cls file that broke an officially supported LyX
 .layout file (and no, unless somebody presents at least one incompatible
 change of the ACM classes that started this thread I won't believe that
 the new versions are backward incompatible: I only saw new commands, not
 changed or deleted old ones).
 
 That is what I always stated, non of my changes (except of that nasty
 modernCV beast) break the backward-compatibility in the strict sense but
 they introduce new commands and that is what this thread is about.

Yes. In the beginning, I thought that these new commands are urgently 
needed, and that you therefore want them in the stable release. Now I 
learned that none of the new commands is urgently needed (maybe except 
modernCV), which I tried to explain above. Therefore it is no problem at all 
to limit the new commands to the 2.1 release IMO.

 I now understood what you all basically want. Although that I am not a fan
 of the versioning, if a majority favors this, we do it. But I want to know
 how _exactly_ the preferred model works. What layout version is rename to
 what?

There were many proposals, I don't have the time right now to make a 
summary. In any case I would change the error message that you get when an 
unknown style is found (it says Parse error, and tells the places where it 
occurs), to a warning explaining that you can safely edit the document, but 
that the printed output will not be correct.


Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Richard Heck wrote:

 It's currently possible to edit such a file without data loss, if I'm
 not mistaken. The unrecognized layouts are treated as Standard, but
 they retain their labels. It is even possible to insert new such layouts
 (or insets) and save the file. So the edit only mode isn't needed, so
 far as I can see.

You re right, I was mistaken by the error message that 2.1 issues on 
opening. IMO an error is too hard (see also my reply to Uwe), but the 2.0.x 
behaviour (no message at all) is not good either.


Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-21 Thread Uwe Stöhr


Am 21.01.2013 09:34, schrieb Jean-Marc Lasgouttes:


But only sometimes. That is no accuse for not providing everything that
might be demanded by a journal.


Sure, but it has to be done case-by-case. My point is that the argument should not 
be all layouts
should be updated to match the latest version strctly.


I fully agree with you. But for the journal classes whose layouts I maintain I had a look in the 
submission guidelines and added the necessary styles to the layouts.
For other classes like e.g. KOMA or memoir, it is of course not necessary to add immediately every 
new style.



There are cases where the macros are just
deprecated and should eventually be replaced. I think using the deprecated 
versions is good enough
during stable releases.


That is not the problem but the new styles that needs to be added to fulfill 
the submission guidelines.


OK, I was joking (you know me by now; don't you?).


Sorry. I'm often very tired when reading my mails in the late evening. In German we have a proverb 
Ironie zieht geschrieben nie! (irony doesn't work if it is written)



But the serious part in there is that there is no
general rule, every journal is a special case.


Yes and I think that every maintainer is responsible to keep his layout up to date to fulfill the 
submission guidelines.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 21/01/13 00:51, Uwe Stöhr a écrit :

Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:


The same holds for moderncv. The author does support backward
compatibility so I would be interested
to see what actually does not work anymore.


I had a look today and I cannot fiddle it out. The underlying table
structure until modernCV 1.0 makes it complicated. With almost every
release I found bugs and reported them to the modernCV maintainer. But
during last summer I lost track and cannot tell which version needs
what.


Thanks for checking that.

JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 21/01/13 00:55, Uwe Stöhr a écrit :

Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:


We also have the right to consider the new commands and the necessity
to support them right _now_.
It may be that they are really required, but I bet that in many cases
they will only correspond to
corner cases.


But only sometimes. That is no acuse for not providing everything that
might be demanded by a journal.


Sure, but it has to be done case-by-case. My point is that the argument 
should not be "all layouts should be updated to match the latest version 
strctly". There are cases where the macros are just deprecated and 
should eventually be replaced. I think using the deprecated versions is 
good enough during stable releases.



You still don't understand what I tried to explain so many times. In
case of the journal classes it is not the choice of the user or our
choice. The publisher forces you to do what he wants or you cannot commit.


OK, I was joking (you know me by now; don't you?). But the serious part 
in there is that there is no general rule, every journal is a special case.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Uwe Stöhr wrote:

> Am 15.01.2013 22:24, schrieb Georg Baum:
> 
>> IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather
>> the oppsosite. And I'd really like to see _one_ example of an updated
>> journal/conference .cls file that broke an officially supported LyX
>> .layout file (and no, unless somebody presents at least one incompatible
>> change of the ACM classes that started this thread I won't believe that
>> the new versions are backward incompatible: I only saw new commands, not
>> changed or deleted old ones).
> 
> That is what I always stated, non of my changes (except of that nasty
> modernCV beast) break the backward-compatibility in the strict sense but
> they introduce new commands and that is what this thread is about.

Yes. In the beginning, I thought that these new commands are urgently 
needed, and that you therefore want them in the stable release. Now I 
learned that none of the new commands is urgently needed (maybe except 
modernCV), which I tried to explain above. Therefore it is no problem at all 
to limit the new commands to the 2.1 release IMO.

> I now understood what you all basically want. Although that I am not a fan
> of the versioning, if a majority favors this, we do it. But I want to know
> how _exactly_ the preferred model works. What layout version is rename to
> what?

There were many proposals, I don't have the time right now to make a 
summary. In any case I would change the error message that you get when an 
unknown style is found (it says "Parse error", and tells the places where it 
occurs), to a warning explaining that you can safely edit the document, but 
that the printed output will not be correct.

Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

Richard Heck wrote:

> It's currently possible to edit such a file without data loss, if I'm
> not mistaken. The unrecognized layouts are treated as "Standard", but
> they retain their labels. It is even possible to insert new such layouts
> (or insets) and save the file. So the "edit only" mode isn't needed, so
> far as I can see.

You re right, I was mistaken by the error message that 2.1 issues on 
opening. IMO an error is too hard (see also my reply to Uwe), but the 2.0.x 
behaviour (no message at all) is not good either.

Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-21 Thread Uwe Stöhr


Am 21.01.2013 09:34, schrieb Jean-Marc Lasgouttes:


But only sometimes. That is no accuse for not providing everything that
might be demanded by a journal.


Sure, but it has to be done case-by-case. My point is that the argument should not 
be "all layouts
should be updated to match the latest version strctly".


I fully agree with you. But for the journal classes whose layouts I maintain I had a look in the 
submission guidelines and added the necessary styles to the layouts.
For other classes like e.g. KOMA or memoir, it is of course not necessary to add immediately every 
new style.



There are cases where the macros are just
deprecated and should eventually be replaced. I think using the deprecated 
versions is good enough
during stable releases.


That is not the problem but the new styles that needs to be added to fulfill 
the submission guidelines.


OK, I was joking (you know me by now; don't you?).


Sorry. I'm often very tired when reading my mails in the late evening. In German we have a proverb 
"Ironie zieht geschrieben nie!" (irony doesn't work if it is written)



But the serious part in there is that there is no
general rule, every journal is a special case.


Yes and I think that every maintainer is responsible to keep his layout up to date to fulfill the 
submission guidelines.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 14.01.2013 11:28, schrieb Enrico Forestieri:


Nothing. If you do nothing, you break nothing.

http://www.lyx.org/trac/ticket/8503#comment:1


Thanks for having a look. There might be a bug in MiKTeX's packaging. But that is not the main 
problem. The problem is once again that there are new styles in the IEEEtran class. It is only a 
matter of time until these are required to fulfill the submission guidelines. So that is why I will 
have to support these styles in the layout and therefore I wold break the backward compatibility as 
already discussed here.


thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 15.01.2013 22:24, schrieb Georg Baum:


IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents at least one incompatible change of
the ACM classes that started this thread I won't believe that the new
versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).


That is what I always stated, non of my changes (except of that nasty modernCV beast) break the 
backward-compatibility in the strict sense but they introduce new commands and that is what this 
thread is about.


I now understood what you all basically want. Although that I am not a fan of the versioning, if a 
majority favors this, we do it. But I want to know how _exactly_ the preferred model works. What 
layout version is rename to what?


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:


The same holds for moderncv. The author does support backward compatibility so 
I would be interested
to see what actually does not work anymore.


I had a look today and I cannot fiddle it out. The underlying table structure until modernCV 1.0 
makes it complicated. With almost every release I found bugs and reported them to the modernCV 
maintainer. But during last summer I lost track and cannot tell which version needs what. As my 
spare time is very limited I cannot work further on this.
But let's live with this limitations. Since modernCV 1.x the things are much easier and I think for 
the future backward compatibility will be much easier.

If you disagree feel free to modify the layout as you think it should be.

thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:


We also have the right to consider the new commands and the necessity to 
support them right _now_.
It may be that they are really required, but I bet that in many cases they will 
only correspond to
corner cases.


But only sometimes. That is no acuse for not providing everything that might be 
demanded by a journal.


I do not think that any Windows user will demand that we switch LyX to use only 
the metro UI because
it is the new norm...


You still don't understand what I tried to explain so many times. In case of the journal classes it 
is not the choice of the user or our choice. The publisher forces you to do what he wants or you 
cannot commit.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 14.01.2013 11:28, schrieb Enrico Forestieri:


Nothing. If you do nothing, you break nothing.

http://www.lyx.org/trac/ticket/8503#comment:1


Thanks for having a look. There might be a bug in MiKTeX's packaging. But that is not the main 
problem. The problem is once again that there are new styles in the IEEEtran class. It is only a 
matter of time until these are required to fulfill the submission guidelines. So that is why I will 
have to support these styles in the layout and therefore I wold break the backward compatibility as 
already discussed here.


thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 15.01.2013 22:24, schrieb Georg Baum:


IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents at least one incompatible change of
the ACM classes that started this thread I won't believe that the new
versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).


That is what I always stated, non of my changes (except of that nasty modernCV beast) break the 
backward-compatibility in the strict sense but they introduce new commands and that is what this 
thread is about.


I now understood what you all basically want. Although that I am not a fan of the versioning, if a 
majority favors this, we do it. But I want to know how _exactly_ the preferred model works. What 
layout version is rename to what?


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 15.01.2013 22:36, schrieb Jean-Marc Lasgouttes:


The same holds for moderncv. The author does support backward compatibility so 
I would be interested
to see what actually does not work anymore.


I had a look today and I cannot fiddle it out. The underlying table structure until modernCV 1.0 
makes it complicated. With almost every release I found bugs and reported them to the modernCV 
maintainer. But during last summer I lost track and cannot tell which version needs what. As my 
spare time is very limited I cannot work further on this.
But let's live with this limitations. Since modernCV 1.x the things are much easier and I think for 
the future backward compatibility will be much easier.

If you disagree feel free to modify the layout as you think it should be.

thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 16.01.2013 10:19, schrieb Jean-Marc Lasgouttes:


We also have the right to consider the new commands and the necessity to 
support them right _now_.
It may be that they are really required, but I bet that in many cases they will 
only correspond to
corner cases.


But only sometimes. That is no acuse for not providing everything that might be 
demanded by a journal.


I do not think that any Windows user will demand that we switch LyX to use only 
the metro UI because
it is the new norm...


You still don't understand what I tried to explain so many times. In case of the journal classes it 
is not the choice of the user or our choice. The publisher forces you to do what he wants or you 
cannot commit.


regards Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-17 Thread Enrico Forestieri

On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:
 On 01/16/2013 03:39 PM, Georg Baum wrote:
 Jean-Marc Lasgouttes wrote:
 
 Le 16/01/2013 08:53, Liviu Andronic a écrit :
 Consider that the updated layout (in 2.0.5) contains _new_ commands
 and that the user creates a document using those new commands that the
 2.0.5 layout supports. What happens if a collaborator opens this
 document in 2.0.3? Will it work, or will opening/compilation break
 down? In other words, is the versioning scheme necessary in such a
 case?
 With the current (non-)ability of LyX to cope with missing styles in a given
 layout: Yes. However, it would be easy to implement an edit-only mode in
 LyX 2.1, that would not allow export (because the information is missing),
 but editing of such a document. Then new styles in a given .layout file
 could be allowed for any 2.1.x release: People could still collaborate using
 different point releases, only if they want to print or view the typeset
 document they would need to install a new layout.
 It's currently possible to edit such a file without data loss, if
 I'm not mistaken. The unrecognized layouts are treated as
 Standard, but they retain their labels. It is even possible to
 insert new such layouts (or insets) and save the file. So the edit
 only mode isn't needed, so far as I can see.
 
 It's worth remembering too that it is *trivial* to install new
 layouts. Someone who opens a file that has a new versioned from
 2.0.8 in some earlier version can easily get that new layout,
 without having to install 2.0.8 itself. Perhaps we should add a
 recipe to the docs and point users there when appropriate.

I have not followed this discussion, so what I say may be nonsense.
However, instead of full versioned layouts, the support for new commands
in more recent classes could be provided by the module mechanism, such
that one could add classname-1.8.module for updating the standard layout
to classname.cls version 1.8. At the next major release, all
classname-1.x.module's will be merged into the standard layout.
The new layout also indicates the obsoleted modules in order to avoid
complaints by lyx about missing modules when loading old documents.

-- 
Enrico

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-17 Thread Richard Heck


On 01/17/2013 01:53 PM, Enrico Forestieri wrote:

On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:

On 01/16/2013 03:39 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

With the current (non-)ability of LyX to cope with missing styles in a given
layout: Yes. However, it would be easy to implement an edit-only mode in
LyX 2.1, that would not allow export (because the information is missing),
but editing of such a document. Then new styles in a given .layout file
could be allowed for any 2.1.x release: People could still collaborate using
different point releases, only if they want to print or view the typeset
document they would need to install a new layout.

It's currently possible to edit such a file without data loss, if
I'm not mistaken. The unrecognized layouts are treated as
Standard, but they retain their labels. It is even possible to
insert new such layouts (or insets) and save the file. So the edit
only mode isn't needed, so far as I can see.

It's worth remembering too that it is *trivial* to install new
layouts. Someone who opens a file that has a new versioned from
2.0.8 in some earlier version can easily get that new layout,
without having to install 2.0.8 itself. Perhaps we should add a
recipe to the docs and point users there when appropriate.

I have not followed this discussion, so what I say may be nonsense.
However, instead of full versioned layouts, the support for new commands
in more recent classes could be provided by the module mechanism, such
that one could add classname-1.8.module for updating the standard layout
to classname.cls version 1.8. At the next major release, all
classname-1.x.module's will be merged into the standard layout.
The new layout also indicates the obsoleted modules in order to avoid
complaints by lyx about missing modules when loading old documents.

That's an amazingly sensible idea. It could even work when more 
extensive changes had been made, by redefining whatever needed redefining.


rh

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-17 Thread Enrico Forestieri

On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:
> On 01/16/2013 03:39 PM, Georg Baum wrote:
> >Jean-Marc Lasgouttes wrote:
> >
> >>Le 16/01/2013 08:53, Liviu Andronic a écrit :
> >>>Consider that the updated layout (in 2.0.5) contains _new_ commands
> >>>and that the user creates a document using those new commands that the
> >>>2.0.5 layout supports. What happens if a collaborator opens this
> >>>document in 2.0.3? Will it work, or will opening/compilation break
> >>>down? In other words, is the versioning scheme necessary in such a
> >>>case?
> >With the current (non-)ability of LyX to cope with missing styles in a given
> >layout: Yes. However, it would be easy to implement an "edit-only" mode in
> >LyX 2.1, that would not allow export (because the information is missing),
> >but editing of such a document. Then new styles in a given .layout file
> >could be allowed for any 2.1.x release: People could still collaborate using
> >different point releases, only if they want to print or view the typeset
> >document they would need to install a new layout.
> It's currently possible to edit such a file without data loss, if
> I'm not mistaken. The unrecognized layouts are treated as
> "Standard", but they retain their labels. It is even possible to
> insert new such layouts (or insets) and save the file. So the "edit
> only" mode isn't needed, so far as I can see.
> 
> It's worth remembering too that it is *trivial* to install new
> layouts. Someone who opens a file that has a new versioned from
> 2.0.8 in some earlier version can easily get that new layout,
> without having to install 2.0.8 itself. Perhaps we should add a
> recipe to the docs and point users there when appropriate.

I have not followed this discussion, so what I say may be nonsense.
However, instead of full versioned layouts, the support for new commands
in more recent classes could be provided by the module mechanism, such
that one could add classname-1.8.module for updating the standard layout
to classname.cls version 1.8. At the next major release, all
classname-1.x.module's will be merged into the standard layout.
The new layout also indicates the obsoleted modules in order to avoid
complaints by lyx about missing modules when loading old documents.

-- 
Enrico

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-17 Thread Richard Heck


On 01/17/2013 01:53 PM, Enrico Forestieri wrote:

On Wed, Jan 16, 2013 at 04:13:31PM -0500, Richard Heck wrote:

On 01/16/2013 03:39 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

With the current (non-)ability of LyX to cope with missing styles in a given
layout: Yes. However, it would be easy to implement an "edit-only" mode in
LyX 2.1, that would not allow export (because the information is missing),
but editing of such a document. Then new styles in a given .layout file
could be allowed for any 2.1.x release: People could still collaborate using
different point releases, only if they want to print or view the typeset
document they would need to install a new layout.

It's currently possible to edit such a file without data loss, if
I'm not mistaken. The unrecognized layouts are treated as
"Standard", but they retain their labels. It is even possible to
insert new such layouts (or insets) and save the file. So the "edit
only" mode isn't needed, so far as I can see.

It's worth remembering too that it is *trivial* to install new
layouts. Someone who opens a file that has a new versioned from
2.0.8 in some earlier version can easily get that new layout,
without having to install 2.0.8 itself. Perhaps we should add a
recipe to the docs and point users there when appropriate.

I have not followed this discussion, so what I say may be nonsense.
However, instead of full versioned layouts, the support for new commands
in more recent classes could be provided by the module mechanism, such
that one could add classname-1.8.module for updating the standard layout
to classname.cls version 1.8. At the next major release, all
classname-1.x.module's will be merged into the standard layout.
The new layout also indicates the obsoleted modules in order to avoid
complaints by lyx about missing modules when loading old documents.

That's an amazingly sensible idea. It could even work when more 
extensive changes had been made, by redefining whatever needed redefining.


rh

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Jean-Marc Lasgouttes


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?


We also have the right to consider the new commands and the necessity to 
support them right _now_. It may be that they are really required, but I 
bet that in many cases they will only correspond to corner cases.


I do not think that any Windows user will demand that we switch LyX to 
use only the metro UI because it is the new norm...


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Scott Kostyshak

On Wed, Jan 16, 2013 at 4:19 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 16/01/2013 08:53, Liviu Andronic a écrit :

 Consider that the updated layout (in 2.0.5) contains _new_ commands
 and that the user creates a document using those new commands that the
 2.0.5 layout supports. What happens if a collaborator opens this
 document in 2.0.3? Will it work, or will opening/compilation break
 down? In other words, is the versioning scheme necessary in such a
 case?


 We also have the right to consider the new commands and the necessity to
 support them right _now_. It may be that they are really required, but I bet
 that in many cases they will only correspond to corner cases.

 I do not think that any Windows user will demand that we switch LyX to use
 only the metro UI because it is the new norm...

If they do maybe they will give £50,000 like for VLC :)
http://www.kickstarter.com/projects/1061646928/vlc-for-the-new-windows-8-user-experience-metro

Scott

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


On 01/16/2013 02:53 AM, Liviu Andronic wrote:

On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:

versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).
Therefore, the best option is IMNSHO to use one of the several suggestions
of versioned layouts, _if_ new layouts in the stable branch are necessary at
all (but I repeat myself).


Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?


If you were to use the original layout, then the new stuff would not be 
recognized, and you would get import errors. How bad this is depends 
upon where the errors are. If you use a versioned layout, then the 
layout would not be found and you get that error and have the option of 
installing the new layout manually.


As I've said, I prefer the latter.

Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Georg Baum

Jean-Marc Lasgouttes wrote:

 Le 16/01/2013 08:53, Liviu Andronic a écrit :
 Consider that the updated layout (in 2.0.5) contains _new_ commands
 and that the user creates a document using those new commands that the
 2.0.5 layout supports. What happens if a collaborator opens this
 document in 2.0.3? Will it work, or will opening/compilation break
 down? In other words, is the versioning scheme necessary in such a
 case?

With the current (non-)ability of LyX to cope with missing styles in a given 
layout: Yes. However, it would be easy to implement an edit-only mode in 
LyX 2.1, that would not allow export (because the information is missing), 
but editing of such a document. Then new styles in a given .layout file 
could be allowed for any 2.1.x release: People could still collaborate using 
different point releases, only if they want to print or view the typeset 
document they would need to install a new layout.
 
 We also have the right to consider the new commands and the necessity to
 support them right _now_. It may be that they are really required, but I
 bet that in many cases they will only correspond to corner cases.

I came to the same conclusion.


Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


On 01/16/2013 03:39 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

With the current (non-)ability of LyX to cope with missing styles in a given
layout: Yes. However, it would be easy to implement an edit-only mode in
LyX 2.1, that would not allow export (because the information is missing),
but editing of such a document. Then new styles in a given .layout file
could be allowed for any 2.1.x release: People could still collaborate using
different point releases, only if they want to print or view the typeset
document they would need to install a new layout.
  
It's currently possible to edit such a file without data loss, if I'm 
not mistaken. The unrecognized layouts are treated as Standard, but 
they retain their labels. It is even possible to insert new such layouts 
(or insets) and save the file. So the edit only mode isn't needed, so 
far as I can see.


It's worth remembering too that it is *trivial* to install new layouts. 
Someone who opens a file that has a new versioned from 2.0.8 in some 
earlier version can easily get that new layout, without having to 
install 2.0.8 itself. Perhaps we should add a recipe to the docs and 
point users there when appropriate.


Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Jean-Marc Lasgouttes


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?


We also have the right to consider the new commands and the necessity to 
support them right _now_. It may be that they are really required, but I 
bet that in many cases they will only correspond to corner cases.


I do not think that any Windows user will demand that we switch LyX to 
use only the metro UI because it is the new norm...


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Scott Kostyshak

On Wed, Jan 16, 2013 at 4:19 AM, Jean-Marc Lasgouttes
 wrote:
> Le 16/01/2013 08:53, Liviu Andronic a écrit :
>
>> Consider that the updated layout (in 2.0.5) contains _new_ commands
>> and that the user creates a document using those new commands that the
>> 2.0.5 layout supports. What happens if a collaborator opens this
>> document in 2.0.3? Will it work, or will opening/compilation break
>> down? In other words, is the versioning scheme necessary in such a
>> case?
>
>
> We also have the right to consider the new commands and the necessity to
> support them right _now_. It may be that they are really required, but I bet
> that in many cases they will only correspond to corner cases.
>
> I do not think that any Windows user will demand that we switch LyX to use
> only the metro UI because it is the new norm...

If they do maybe they will give £50,000 like for VLC :)
http://www.kickstarter.com/projects/1061646928/vlc-for-the-new-windows-8-user-experience-metro

Scott

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


On 01/16/2013 02:53 AM, Liviu Andronic wrote:

On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
 wrote:

versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).
Therefore, the best option is IMNSHO to use one of the several suggestions
of versioned layouts, _if_ new layouts in the stable branch are necessary at
all (but I repeat myself).


Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?


If you were to use the original layout, then the new stuff would not be 
recognized, and you would get import errors. How bad this is depends 
upon where the errors are. If you use a versioned layout, then the 
layout would not be found and you get that error and have the option of 
installing the new layout manually.


As I've said, I prefer the latter.

Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-16 Thread Georg Baum

Jean-Marc Lasgouttes wrote:

> Le 16/01/2013 08:53, Liviu Andronic a écrit :
>> Consider that the updated layout (in 2.0.5) contains _new_ commands
>> and that the user creates a document using those new commands that the
>> 2.0.5 layout supports. What happens if a collaborator opens this
>> document in 2.0.3? Will it work, or will opening/compilation break
>> down? In other words, is the versioning scheme necessary in such a
>> case?

With the current (non-)ability of LyX to cope with missing styles in a given 
layout: Yes. However, it would be easy to implement an "edit-only" mode in 
LyX 2.1, that would not allow export (because the information is missing), 
but editing of such a document. Then new styles in a given .layout file 
could be allowed for any 2.1.x release: People could still collaborate using 
different point releases, only if they want to print or view the typeset 
document they would need to install a new layout.

> We also have the right to consider the new commands and the necessity to
> support them right _now_. It may be that they are really required, but I
> bet that in many cases they will only correspond to corner cases.

I came to the same conclusion.

Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


On 01/16/2013 03:39 PM, Georg Baum wrote:

Jean-Marc Lasgouttes wrote:


Le 16/01/2013 08:53, Liviu Andronic a écrit :

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

With the current (non-)ability of LyX to cope with missing styles in a given
layout: Yes. However, it would be easy to implement an "edit-only" mode in
LyX 2.1, that would not allow export (because the information is missing),
but editing of such a document. Then new styles in a given .layout file
could be allowed for any 2.1.x release: People could still collaborate using
different point releases, only if they want to print or view the typeset
document they would need to install a new layout.
  
It's currently possible to edit such a file without data loss, if I'm 
not mistaken. The unrecognized layouts are treated as "Standard", but 
they retain their labels. It is even possible to insert new such layouts 
(or insets) and save the file. So the "edit only" mode isn't needed, so 
far as I can see.


It's worth remembering too that it is *trivial* to install new layouts. 
Someone who opens a file that has a new versioned from 2.0.8 in some 
earlier version can easily get that new layout, without having to 
install 2.0.8 itself. Perhaps we should add a recipe to the docs and 
point users there when appropriate.


Richard

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Georg Baum

Guenter Milde wrote:

 On 2013-01-14, Enrico Forestieri wrote:
 On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:
 
 But to come to an end, decide once again but please act then
 consistently. I will have to update IEEEtran and I want to know from
 you what I should do now.
 
 Nothing. If you do nothing, you break nothing.
 
 http://www.lyx.org/trac/ticket/8503#comment:1
 
 However, if you do nothing, you also do not fix something broken.

Did you read the link? I believe Enrico wanted to say that nothing is 
broken: Both the current template and layout file work fine with the new 
version. I currently have no installation to test, but I scanned the 
changelog and http://www.michaelshell.org/tex/ieeetran/, and I am pretty 
sure that Enrico is right: The only listed backward incompatible changes 
concern macros that are neither used in the layout file nor in the template.

Therefore the only issue with the current IEEEtran support of LyX is missing 
support for the new macros \IEEEtitleabstractindextext and 
\IEEEdisplaynontitleabstractindextext, but this is nothing new since their 
predessors \IEEEcompsoctitleabstractindextext and 
\IEEEdisplaynotcompsoctitleabstractindextext are not supported either.


BTW, IEEEtran.cls is a very good example, since it is widely used. You can 
easily verify the following facts:


1) Different conferences/journals require different versions of IEEEtran.cls

Examples: Official IEEE transcations use the new version 1.8 mentioned by 
Uwe: 
http://www.ieee.org/publications_standards/publications/authors/author_templates.html
 
https://files.ifi.uzh.ch/icseweb/how-to-submit/index.html required its own 
version 1.7a which is _not_ equal to the version 1.7a from CTAN. 
http://netcod2012.org/doku.php?id=submission recommended (but did not 
require) 1.7a from CTAN.


2) The template is not only used by the IEEE, but also by independent 
conferences

Examples: https://files.ifi.uzh.ch/icseweb/home/index.html. I have also seen 
a local mini conference using it.


3) The IEEEtran.cls author knows that backward compatibility is important 
(see the notes on his website).


IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the 
oppsosite. And I'd really like to see _one_ example of an updated 
journal/conference .cls file that broke an officially supported LyX .layout 
file (and no, unless somebody presents at least one incompatible change of 
the ACM classes that started this thread I won't believe that the new 
versions are backward incompatible: I only saw new commands, not changed or 
deleted old ones).
Therefore, the best option is IMNSHO to use one of the several suggestions 
of versioned layouts, _if_ new layouts in the stable branch are necessary at 
all (but I repeat myself).


Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Jean-Marc Lasgouttes


Le 15/01/2013 22:24, Georg Baum a écrit :

IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents at least one incompatible change of
the ACM classes that started this thread I won't believe that the new
versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).


The same holds for moderncv. The author does support backward 
compatibility so I would be interested to see what actually does not 
work anymore.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Liviu Andronic

On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
georg.b...@post.rwth-aachen.de wrote:
 versions are backward incompatible: I only saw new commands, not changed or
 deleted old ones).

 Therefore, the best option is IMNSHO to use one of the several suggestions
 of versioned layouts, _if_ new layouts in the stable branch are necessary at
 all (but I repeat myself).

Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

Liviu

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Georg Baum

Guenter Milde wrote:

> On 2013-01-14, Enrico Forestieri wrote:
>> On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:
> 
>>> But to come to an end, decide once again but please act then
>>> consistently. I will have to update IEEEtran and I want to know from
>>> you what I should do now.
> 
>> Nothing. If you do nothing, you break nothing.
> 
>> http://www.lyx.org/trac/ticket/8503#comment:1
> 
> However, if you do nothing, you also do not fix something broken.

Did you read the link? I believe Enrico wanted to say that nothing is 
broken: Both the current template and layout file work fine with the new 
version. I currently have no installation to test, but I scanned the 
changelog and http://www.michaelshell.org/tex/ieeetran/, and I am pretty 
sure that Enrico is right: The only listed backward incompatible changes 
concern macros that are neither used in the layout file nor in the template.

Therefore the only issue with the current IEEEtran support of LyX is missing 
support for the new macros \IEEEtitleabstractindextext and 
\IEEEdisplaynontitleabstractindextext, but this is nothing new since their 
predessors \IEEEcompsoctitleabstractindextext and 
\IEEEdisplaynotcompsoctitleabstractindextext are not supported either.

BTW, IEEEtran.cls is a very good example, since it is widely used. You can 
easily verify the following facts:

1) Different conferences/journals require different versions of IEEEtran.cls

Examples: Official IEEE transcations use the new version 1.8 mentioned by 
Uwe: 
http://www.ieee.org/publications_standards/publications/authors/author_templates.html

https://files.ifi.uzh.ch/icseweb/how-to-submit/index.html required its own 
version 1.7a which is _not_ equal to the version 1.7a from CTAN. 
http://netcod2012.org/doku.php?id=submission recommended (but did not 
require) 1.7a from CTAN.

2) The template is not only used by the IEEE, but also by independent 
conferences

Examples: https://files.ifi.uzh.ch/icseweb/home/index.html. I have also seen 
a local mini conference using it.

3) The IEEEtran.cls author knows that backward compatibility is important 
(see the notes on his website).

IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the 
oppsosite. And I'd really like to see _one_ example of an updated 
journal/conference .cls file that broke an officially supported LyX .layout 
file (and no, unless somebody presents at least one incompatible change of 
the ACM classes that started this thread I won't believe that the new 
versions are backward incompatible: I only saw new commands, not changed or 
deleted old ones).
Therefore, the best option is IMNSHO to use one of the several suggestions 
of versioned layouts, _if_ new layouts in the stable branch are necessary at 
all (but I repeat myself).

Georg

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Jean-Marc Lasgouttes


Le 15/01/2013 22:24, Georg Baum a écrit :

IMHO, IEEEtran.cls does not support Uwe's reasoning at all, but rather the
oppsosite. And I'd really like to see _one_ example of an updated
journal/conference .cls file that broke an officially supported LyX .layout
file (and no, unless somebody presents at least one incompatible change of
the ACM classes that started this thread I won't believe that the new
versions are backward incompatible: I only saw new commands, not changed or
deleted old ones).


The same holds for moderncv. The author does support backward 
compatibility so I would be interested to see what actually does not 
work anymore.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-15 Thread Liviu Andronic

On Tue, Jan 15, 2013 at 10:24 PM, Georg Baum
 wrote:
> versions are backward incompatible: I only saw new commands, not changed or
> deleted old ones).

> Therefore, the best option is IMNSHO to use one of the several suggestions
> of versioned layouts, _if_ new layouts in the stable branch are necessary at
> all (but I repeat myself).
>
Consider that the updated layout (in 2.0.5) contains _new_ commands
and that the user creates a document using those new commands that the
2.0.5 layout supports. What happens if a collaborator opens this
document in 2.0.3? Will it work, or will opening/compilation break
down? In other words, is the versioning scheme necessary in such a
case?

Liviu

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-14 Thread Enrico Forestieri

On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:

 But to come to an end, decide once again but please act then
 consistently. I will have to update IEEEtran and I want to know from
 you what I should do now.

Nothing. If you do nothing, you break nothing.

http://www.lyx.org/trac/ticket/8503#comment:1

-- 
Enrico

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

On 2013-01-14, Uwe Stöhr wrote:
 Am 02.01.2013 15:42, schrieb Richard Heck:

 I want:
 - for paper submission classes we can change the layout for every LyX
   release (this might break backward compatibility but for these
   classes you are not allowed to use older class versions)

 - for non-paper classes we can use your proposed layout versioning scheme.

 ---

 But to come to an end, decide once again but please act then
 consistently. I will have to update IEEEtran and I want to know from
 you what I should do now. Just naming the new layout to 
 IEEEtran-1-8.layout and renaming the existing one to
 IEEEtran-1-7.layout? This would also break backward compatibility
 because of the renaming. But if we leave an IEEEtran.layout, people
 will for sure use this outdated version to start writing their paper.
 But this is what I want to avoid.

Suggestion for a consistent policy:

* Provide versioned layouts, when there are incompatible versions of LaTeX
  classes, e.g. 

IEEEtran-1-8.layout, IEEEtran-1-7.layout, ...
  
* check the package version in the (re)configuring step and make the
  generic name an alias to the installed version.

IEEEtran.layout - IEEEtran-1-8.layout

* If a change of the layout file requires also changes in the document,
  store the versioned name in the lyx document.


Reasoning:

+ choosing the generic layout for a document ensures that
  export to LaTeX will create a document that compiles with the
  installed version of the LaTeX distro.  
  
+ The show-up of versioned layouts in the layout combo makes the user aware
  of the version problems.
  
+ For special needs (e.g. create a LaTeX file for someone 
  with another version of the package), it is possible to select a
  specific layout version.

Günter

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-14 Thread Liviu Andronic

Hello Uwe


On Mon, Jan 14, 2013 at 2:33 AM, Uwe Stöhr uwesto...@web.de wrote:
 The Windows installer is your business.

 That is not fair. We can assume that at least 50% of our users use LyX on
 Windows.

This is harsh reasoning. In many cases open-source projects only take
responsibility for providing source-code that compiles and works as
expected on various platforms. Packaging is more treated as a
user-provided contribution (distro package managers for Linux, users
for Windows and Mac). If it weren't for all your efforts, chances are
that we wouldn't have an up-to-date Windows installer. But the project
would definitely continue and new releases trickle in.


 OK for them. Of course everybody can use what he wants but we should provide 
 an up to date LyX. Only this way people who wants or needs to use the latest 
 version can do so. People who wants to stay with e.g. teTeX can do this, but 
 need an appropriate LyX - I would say LyX 1.5.x.

As mentioned earlier several times, updating LaTeX packages on Linux
is only for experts. And even then, they wouldn't necessarily want to
bother with the effort. Cutting off a significant proportion of users
(many academics and hackers seem to be using Ubuntu and other distros,
among other OSes) and developers (off the top of my head, most of our
developers work on Linux or some *nix flavour) seems like a very bad
idea. We wouldn't want JMarc to be unable to use latest LyX (release,
branch or trunk), would we?

I didn't follow all the details, but if the layout naming scheme
allows enough flexibility to provide layout updates during minor
releases, but keeps old documents created within the same major
release cycle to compile (whatever the minor release being used by the
user, 2.0.1 or 2.0.5), then this is definitely the way to go. Even if
it means more workload and a different workflow for the maintainer.

And finally, as was explained on earlier occasions, minor releases
strive to keep a stable file format. This is a long-time LyX policy.
If previously file format changes happened on a minor release, then
that was bad policy policing. And that was inconsistent. The idea is
that a user should be able to interchange 2.0.1, 2.0.3 and 2.0.9
seamlessly, without worrying whether a document will fail to compile
on any of these releases. I think that one issue with our release
cycle is that it is painfully (if understandably) slow. It usually
takes a minimum of 3 months between minor releases, and some two years
between major releases. This would partly explain why some would come
to think of minor releases (e.g., 2.0.5) as major releases (which they
aren't).

Regards
Liviu

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

On 2013-01-14, Enrico Forestieri wrote:
 On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:

 But to come to an end, decide once again but please act then
 consistently. I will have to update IEEEtran and I want to know from
 you what I should do now.

 Nothing. If you do nothing, you break nothing.

 http://www.lyx.org/trac/ticket/8503#comment:1

However, if you do nothing, you also do not fix something broken.

A layout file that does not work with the current version of the related
LaTeX class/package is broken. 

A possible fix would be to indicate the fact by, e.g., a version number
in its name.


I agree that the responsible part is in the first place the LaTeX class
itself - introducing incompatible changes in a LaTeX class without renaming
is asking for trouble.

Günter

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-14 Thread Enrico Forestieri

On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:

> But to come to an end, decide once again but please act then
> consistently. I will have to update IEEEtran and I want to know from
> you what I should do now.

Nothing. If you do nothing, you break nothing.

http://www.lyx.org/trac/ticket/8503#comment:1

-- 
Enrico

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

On 2013-01-14, Uwe Stöhr wrote:
> Am 02.01.2013 15:42, schrieb Richard Heck:

> I want:
> - for paper submission classes we can change the layout for every LyX
>   release (this might break backward compatibility but for these
>   classes you are not allowed to use older class versions)

> - for non-paper classes we can use your proposed layout versioning scheme.

> ---

> But to come to an end, decide once again but please act then
> consistently. I will have to update IEEEtran and I want to know from
> you what I should do now. Just naming the new layout to 
> IEEEtran-1-8.layout and renaming the existing one to
> IEEEtran-1-7.layout? This would also break backward compatibility
> because of the renaming. But if we leave an IEEEtran.layout, people
> will for sure use this outdated version to start writing their paper.
> But this is what I want to avoid.

Suggestion for a consistent policy:

* Provide versioned layouts, when there are incompatible versions of LaTeX
  classes, e.g. 

IEEEtran-1-8.layout, IEEEtran-1-7.layout, ...
  
* check the package version in the (re)configuring step and make the
  "generic" name an alias to the installed version.

IEEEtran.layout -> IEEEtran-1-8.layout

* If a change of the layout file requires also changes in the document,
  store the "versioned" name in the lyx document.


Reasoning:

+ choosing the "generic" layout for a document ensures that
  export to LaTeX will create a document that compiles with the
  installed version of the LaTeX distro.  
  
+ The show-up of versioned layouts in the layout combo makes the user aware
  of the version problems.
  
+ For special needs (e.g. create a LaTeX file for someone 
  with another version of the package), it is possible to select a
  specific layout version.

Günter

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-14 Thread Liviu Andronic

Hello Uwe

On Mon, Jan 14, 2013 at 2:33 AM, Uwe Stöhr  wrote:
>> The Windows installer is your business.
>
> That is not fair. We can assume that at least 50% of our users use LyX on
> Windows.
>
This is harsh reasoning. In many cases open-source projects only take
responsibility for providing source-code that compiles and works as
expected on various platforms. Packaging is more treated as a
user-provided contribution (distro package managers for Linux, users
for Windows and Mac). If it weren't for all your efforts, chances are
that we wouldn't have an up-to-date Windows installer. But the project
would definitely continue and new releases trickle in.

> OK for them. Of course everybody can use what he wants but we should provide 
> an up to date LyX. Only this way people who wants or needs to use the latest 
> version can do so. People who wants to stay with e.g. teTeX can do this, but 
> need an appropriate LyX - I would say LyX 1.5.x.
>
As mentioned earlier several times, updating LaTeX packages on Linux
is only for experts. And even then, they wouldn't necessarily want to
bother with the effort. Cutting off a significant proportion of users
(many academics and hackers seem to be using Ubuntu and other distros,
among other OSes) and developers (off the top of my head, most of our
developers work on Linux or some *nix flavour) seems like a very bad
idea. We wouldn't want JMarc to be unable to use latest LyX (release,
branch or trunk), would we?

I didn't follow all the details, but if the layout naming scheme
allows enough flexibility to provide layout updates during minor
releases, but keeps old documents created within the same major
release cycle to compile (whatever the minor release being used by the
user, 2.0.1 or 2.0.5), then this is definitely the way to go. Even if
it means more workload and a different workflow for the maintainer.

And finally, as was explained on earlier occasions, minor releases
strive to keep a stable file format. This is a long-time LyX policy.
If previously file format changes happened on a minor release, then
that was bad policy policing. And that was inconsistent. The idea is
that a user should be able to interchange 2.0.1, 2.0.3 and 2.0.9
seamlessly, without worrying whether a document will fail to compile
on any of these releases. I think that one issue with our release
cycle is that it is painfully (if understandably) slow. It usually
takes a minimum of 3 months between minor releases, and some two years
between major releases. This would partly explain why some would come
to think of minor releases (e.g., 2.0.5) as major releases (which they
aren't).

Regards
Liviu

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

On 2013-01-14, Enrico Forestieri wrote:
> On Mon, Jan 14, 2013 at 02:33:36AM +0100, Uwe Stöhr wrote:

>> But to come to an end, decide once again but please act then
>> consistently. I will have to update IEEEtran and I want to know from
>> you what I should do now.

> Nothing. If you do nothing, you break nothing.

> http://www.lyx.org/trac/ticket/8503#comment:1

However, if you do nothing, you also do not fix something broken.

A layout file that does not work with the current version of the related
LaTeX class/package is broken. 

A possible fix would be to indicate the fact by, e.g., a version number
in its name.

I agree that the responsible part is in the first place the LaTeX class
itself - introducing incompatible changes in a LaTeX class without renaming
is asking for trouble.

Günter

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-13 Thread Uwe Stöhr

Am 02.01.2013 15:42, schrieb Richard Heck:

I'm sorry, Uwe, but you simply are not listening to what anyone else is saying.
No one is saying we
should not provide updated layout files, force people to enter TeX code, or
whatever. The ONLY issue
is what the names of these new layouts will be. I'll address your concerns
about this issue below.
But it is the only one worth discussing. Explaining why we need to be able to
offer updated layout
files, so people can submit to journals, etc, is not helpful. We agree about
this. It just annoys
people that you can't acknowledge that agreement and keep trying to rehash it.

The problem is that you suddenly changes our policy. Why was it possible to change layouts without
renaming them for years and we did not had any complain? So why should wee change this now and
invent a naming scheme that is not helpful? (I mean paper classes, for others like e.g. memoir a
layout conversioning might be useful.)

Take for example IEEEtran. This class is very widespread in the field of engineering and they now
release a new version. With this version out template is no longer compilable. Moreover to fulfill
the new submission guidelines I would have to add some new styles to the IEEEtran layout. This will
of course break backward compatibility. You say that I should now create a new layout named e.g.
IEEEtran-1-8-layout. But that is not helpful because an author of an IEEE paper has to use the
latest version of IEEEtran in any case. So why should it help him to find in LyX several versions
for IEEEtran? He is then forced to check what the latest version is and this is not easy for someone
who is not familiar with LaTeX. The user who once wrote a paper using IEEEtran 1.7 or older will
have to update to 1.8 to write a new one. If he does this he breaks backward compatibility because
he has to adapt his file anyway. So what has helped him that we provide different layouts? IEEEtran
has become obsolete and nobody can use it anymore and I am opposed to provide obsolete and useless
stuff.
Hmm, OK, it might help him to see that if IEEEtran 1.9 has to be used and we only provide a layout
for 1.8, he cannot use LyX.

As for the rest: Plenty of people use year old versions of Firefox, or
whatever. Python 2 co-exists
with Python 3. The TeXLive version that ships with most Linux distros does not
have a package
manager. And so on, and so forth.

OK for them. Of course everybody can use what he wants but we should provide an up to date LyX. Only
this way people who wants or needs to use the latest version can do so. People who wants to stay
with e.g. teTeX can do this, but need an appropriate LyX - I would say LyX 1.5.x.

(And sorry, but using a year old Firefox is just stupid. The web is full of exploits for bugs in
Firefox.)

Well, in that case, it isn't any more work. If we're doing it anyway, why does
it matter what the
new file is called? The old one gets deprecated, but it stays in the tree,
throughout a given major
release.

That would in principle be fine, but we release only every 2 years a major one. But in this times
there are so many releases, see http://news.gmane.org/gmane.comp.tex.ctan.announce

Well, then you will be frustrated, on either proposal, won't you?

You are confusing. I explained why I am opposed to _this_ proposal. I'm only talking about this and
not about others.

On your proposal, your new layout
will not compile with older versions of the class, which lots of people will
have.

Yes and that is by design because it is a paper class where you are not free to decide which class
version to use. For non-paper classes like e.g. KOMA-script I would support your proposal.

In any event, this is now not a discussion about whether we can or will allow
the shipping of a
certain version of a layout. It is about what is best for users, among choices
all of which have
their downsides. A large majority of developers prefers one of the two
solutions.

Fine, but what about the users? We are not developing LyX for our pleasure but to give users an easy
to use and useful program. The problem with us developers is that we know all the details, what is
happening behind the scenes, how third-party programs act and we know LaTeX, what a LaTeX-package
and a layout it. All this is not known for an average user.
You are a professor and therefore in contact with many students. Give some of your average students
LyX without telling them anything about LaTeX and how LyX internally works. They should just install
it and start writing a short text. Then you will see what I mean. You will be surprised what they
expect and what they do with LyX and that many will be frustrated after an hour of playing with it
and you will fail to explain them why LyX is advantageous compared to e.g. Word. I had these
situations hundreds of times.

I don't understand your argumentation. We always allowed to break compatibility
across minor
versions:

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-13 Thread Uwe Stöhr

Am 02.01.2013 15:42, schrieb Richard Heck:

Take for example IEEEtran. This class is very widespread in the field of engineering and they now
release a new version. With this version out template is no longer compilable. Moreover to fulfill
the new submission guidelines I would have to add some new styles to the IEEEtran layout. This will
of course break backward compatibility. You say that I should now create a new layout named e.g.
"IEEEtran-1-8-layout". But that is not helpful because an author of an IEEE paper has to use the
latest version of IEEEtran in any case. So why should it help him to find in LyX several versions
for IEEEtran? He is then forced to check what the latest version is and this is not easy for someone
who is not familiar with LaTeX. The user who once wrote a paper using IEEEtran 1.7 or older will
have to update to 1.8 to write a new one. If he does this he breaks backward compatibility because
he has to adapt his file anyway. So what has helped him that we provide different layouts? IEEEtran
has become obsolete and nobody can use it anymore and I am opposed to provide obsolete and useless
stuff.
Hmm, OK, it might help him to see that if IEEEtran 1.9 has to be used and we only provide a layout
for 1.8, he cannot use LyX.

(And sorry, but using a year old Firefox is just stupid. The web is full of exploits for bugs in
Firefox.)

That would in principle be fine, but we release only every 2 years a major one. But in this times
there are so many releases, see http://news.gmane.org/gmane.comp.tex.ctan.announce

Well, then you will be frustrated, on either proposal, won't you?

You are confusing. I explained why I am opposed to _this_ proposal. I'm only talking about this and
not about others.

On your proposal, your new layout
will not compile with older versions of the class, which lots of people will
have.

Yes and that is by design because it is a paper class where you are not free to decide which class
version to use. For non-paper classes like e.g. KOMA-script I would support your proposal.

I don't understand your argumentation. We always allowed to break compatibility
across minor

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-02 Thread Jürgen Spitzmüller

Can we please revert the moderncv and achemso changes in branch unless we have 
come to a final conclusion?

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-02 Thread Richard Heck


On 01/01/2013 10:34 PM, Uwe Stöhr wrote:

Am 16.12.2012 19:33, schrieb Richard Heck:


1. backward compatibility


Perhaps I am reading too much into this, but if your main concern is 
the example or template file,
then there is no issue here. I have already said that I have no 
objection to making the example and
template files be up to date, in the sense that they use the updated 
layout. It's just that this

layout will have a new name. So this is not an issue.


I am referring to the fact that we need to keep the layout files up to 
date corresponding do their .cls file. It is in my opinion not 
acceptable that adding a new style to a layout file should not be 
allowed for branch. And that is the most important point for me and 
the reason why I fight!


I'm sorry, Uwe, but you simply are not listening to what anyone else is 
saying. No one is saying we should not provide updated layout files, 
force people to enter TeX code, or whatever. The ONLY issue is what the 
names of these new layouts will be. I'll address your concerns about 
this issue below. But it is the only one worth discussing. Explaining 
why we need to be able to offer updated layout files, so people can 
submit to journals, etc, is not helpful. We agree about this. It just 
annoys people that you can't acknowledge that agreement and keep trying 
to rehash it.





2. scientific document classes


If this is about the template, then again there is no issue here: It 
can use the updated layout. And this will make it easier for 
inexperienced users to choose the right layout, since they will very 
often start with the template.


No, it is about the fact that we must provide an up to date layout 
file for scientific classes that allow to fulfill the submission 
guidelines.


It says, right there is what I wrote: It can use the *updated* layout. 
So, again, there is no issue about this.


As for the rest: Plenty of people use year old versions of Firefox, or 
whatever. Python 2 co-exists with Python 3. The TeXLive version that 
ships with most Linux distros does not have a package manager. And so 
on, and so forth.



4. the proposal with layouts for different document class versions


Let me address the last point first. I do not see why you think 
versioning makes more work. Why would you have to write three 
different layouts? To support every single version of moderncv?


Yes.


We don't do that now, as you said.


You misunderstood me then. We always did so in the past and I want to 
keep this because it has been proven to be useful. Our layouts must be 
up to date to be useful - to fulfill submission guidelines for 
scientific classes and to be able to compile it with the latest .cls 
file version on CTAN, see my argumentation above.


Well, in that case, it isn't any more work. If we're doing it anyway, 
why does it matter what the new file is called? The old one gets 
deprecated, but it stays in the tree, throughout a given major release.


Why would we have to do it then? Are you worried that, if a layout is 
tied to a version thus:

 version=0.15
then somehow it stops working when the version changes?


No. I am against to force users to learn about their package version. 
Getting this is even with TeXLive not that easy. So having many 
layouts for one single class is confusing and complicated too for 
average users.
Before I continue, I should state how I work on LyX: I imagine I would 
sell it. What can I do that more people buy my product? Answering that 
leads automatically to a user-friendly program. I develop LyX that as 
many people as possible use it and not as a tool for experts being who 
know what a LaTeX-package is.
As an average user I expect that I have to choose a document class and 
my document will compile - nothing more!


Well, then you will be frustrated, on either proposal, won't you? On 
your proposal, your new layout will not compile with older versions of 
the class, which lots of people will have. At least on mine, there will 
be a layout that you can use. And please do not tell me again about 
package managers, and how no one uses old versions of the class. We have 
been over that.


In any event, this is now not a discussion about whether we can or will 
allow the shipping of a certain version of a layout. It is about what is 
best for users, among choices all of which have their downsides. A large 
majority of developers prefers one of the two solutions.


Option (1) thus breaks compatibility across minor versions of 2.0.x, 
and that is just
not acceptable, in my opinion and that of most of the other 
developers. That is why I thought I could make a decision when I did: 
Because once it has been decided that we cannot break compatibility 
across minor versions---


I don't understand your argumentation. We always allowed to break 
compatibility across minor versions: Every changed layout in branch 
did this also every new Windows installer feature.



The Windows installer is your business.


2

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-02 Thread Jürgen Spitzmüller

Can we please revert the moderncv and achemso changes in branch unless we have 
come to a final conclusion?

Jürgen

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2013-01-02 Thread Richard Heck


On 01/01/2013 10:34 PM, Uwe Stöhr wrote:

Am 16.12.2012 19:33, schrieb Richard Heck:


1. backward compatibility


Perhaps I am reading too much into this, but if your main concern is 
the example or template file,
then there is no issue here. I have already said that I have no 
objection to making the example and
template files be up to date, in the sense that they use the updated 
layout. It's just that this

layout will have a new name. So this is not an issue.


I am referring to the fact that we need to keep the layout files up to 
date corresponding do their .cls file. It is in my opinion not 
acceptable that adding a new style to a layout file should not be 
allowed for branch. And that is the most important point for me and 
the reason why I fight!


I'm sorry, Uwe, but you simply are not listening to what anyone else is 
saying. No one is saying we should not provide updated layout files, 
force people to enter TeX code, or whatever. The ONLY issue is what the 
names of these new layouts will be. I'll address your concerns about 
this issue below. But it is the only one worth discussing. Explaining 
why we need to be able to offer updated layout files, so people can 
submit to journals, etc, is not helpful. We agree about this. It just 
annoys people that you can't acknowledge that agreement and keep trying 
to rehash it.





2. scientific document classes


If this is about the template, then again there is no issue here: It 
can use the updated layout. And this will make it easier for 
inexperienced users to choose the right layout, since they will very 
often start with the template.


No, it is about the fact that we must provide an up to date layout 
file for scientific classes that allow to fulfill the submission 
guidelines.


It says, right there is what I wrote: It can use the *updated* layout. 
So, again, there is no issue about this.


As for the rest: Plenty of people use year old versions of Firefox, or 
whatever. Python 2 co-exists with Python 3. The TeXLive version that 
ships with most Linux distros does not have a package manager. And so 
on, and so forth.



4. the proposal with layouts for different document class versions


Let me address the last point first. I do not see why you think 
versioning makes more work. Why would you have to write three 
different layouts? To support every single version of moderncv?


Yes.


We don't do that now, as you said.


You misunderstood me then. We always did so in the past and I want to 
keep this because it has been proven to be useful. Our layouts must be 
up to date to be useful - to fulfill submission guidelines for 
scientific classes and to be able to compile it with the latest .cls 
file version on CTAN, see my argumentation above.


Well, in that case, it isn't any more work. If we're doing it anyway, 
why does it matter what the new file is called? The old one gets 
deprecated, but it stays in the tree, throughout a given major release.


Why would we have to do it then? Are you worried that, if a layout is 
tied to a version thus:

 version=0.15
then somehow it stops working when the version changes?


No. I am against to force users to learn about their package version. 
Getting this is even with TeXLive not that easy. So having many 
layouts for one single class is confusing and complicated too for 
average users.
Before I continue, I should state how I work on LyX: I imagine I would 
sell it. What can I do that more people buy my product? Answering that 
leads automatically to a user-friendly program. I develop LyX that as 
many people as possible use it and not as a tool for experts being who 
know what a LaTeX-package is.
As an average user I expect that I have to choose a document class and 
my document will compile - nothing more!


Well, then you will be frustrated, on either proposal, won't you? On 
your proposal, your new layout will not compile with older versions of 
the class, which lots of people will have. At least on mine, there will 
be a layout that you can use. And please do not tell me again about 
package managers, and how no one uses old versions of the class. We have 
been over that.


In any event, this is now not a discussion about whether we can or will 
allow the shipping of a certain version of a layout. It is about what is 
best for users, among choices all of which have their downsides. A large 
majority of developers prefers one of the two solutions.


Option (1) thus breaks compatibility across minor versions of 2.0.x, 
and that is just
not acceptable, in my opinion and that of most of the other 
developers. That is why I thought I could make a decision when I did: 
Because once it has been decided that we cannot break compatibility 
across minor versions---


I don't understand your argumentation. We always allowed to break 
compatibility across minor versions: Every changed layout in branch 
did this also every new Windows installer feature.



The Windows installer is your business.


2

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 16.12.2012 19:33, schrieb Richard Heck:


1. backward compatibility


Perhaps I am reading too much into this, but if your main concern is the 
example or template file,
then there is no issue here. I have already said that I have no objection to 
making the example and
template files be up to date, in the sense that they use the updated layout. 
It's just that this
layout will have a new name. So this is not an issue.


I am referring to the fact that we need to keep the layout files up to date corresponding do their 
.cls file. It is in my opinion not acceptable that adding a new style to a layout file should not be 
allowed for branch. And that is the most important point for me and the reason why I fight!


Our layouts are offers to the users. LyX is only as useful as its layout files are. So if you want 
to use a new feature of your preferred class, your should not be forced to learn tricky TeX-code, 
play with ERT or preamble code. LyX should offer this!!! And waiting 2 years for the next major LyX 
release is in modern times no option.
(I'm still wondering about your (LyX developers) experiences. In my our potential user group 
(students scientific researchers) wants a system that works out of the box will as much as possible 
features. If you tell them they have to enter TeX-code they will immediately go back to Word. Trust 
me - I already introduced LyX to so many people and gave courses. The Windows installer was one 
consequence of it: just click a few times OK and next and you get a fully functional system. The 
other consequences was to write layout file and to offer a thesis template.)



2. scientific document classes


If this is about the template, then again there is no issue here: It can use 
the updated layout. And
this will make it easier for inexperienced users to choose the right layout, 
since they will very
often start with the template.


No, it is about the fact that we must provide an up to date layout file for scientific classes that 
allow to fulfill the submission guidelines. Otherwise the layouts for that document class types are 
quite useless. Imagine how frustrating it is to write a paper but when submitting it, the automated 
submission systems will deny your file not telling you why exactly. Personally I had this case 
twice. It cost me about a day to find out that images were too wide and the image caption was not 
above the image but below (or something similar, can't remember it exactly). I can imagine that an 
average user would the next time not use LyX but directly LaTeX or Word. So if Lyx should be 
attractive to use it for sientific reasearchers, we must assure that the submission guidelines are 
fulfilled or we drop support for these document classes to be consequent.



3. my LaTeX system is too old


Obviously, there are extreme cases we cannot support.


But where do you draw the line what to support and what not? LyX is an offer to the users and as 
such as user I can expect to get a fully featured program.
I already explained why for me discussion about this topic is very, very strange. Let's face the 
reality: every program you can purchase or download offers bugfixes and new features from time to 
time. The time period between releases is usually some months for good reasons because all the time 
bugs occur and have to be fixed. No matter if you have to pay for support or not, only the latest 
version is supported (except of some fundamental programs like an OS). LyX does the same and when we 
get a bug report that LyX 2.0.2 contains a bug, we since ever replied use LyX 2.0.5 where the bug 
is fixed. The same is with all LaTeX-packages, and third-party programs we use.
To be drastic: Would you use a one-year old Firefox or Java or Flash or Python? Of course not 
because the old versions have known vulnerabilities.

That Software needs to be updated from time to time is a matter of course.


But we need to be sensitive to a range of
different platforms and what TeX installations are currently being used on 
them. We should not just
assume that everyone is using the latest and greatest version of every package 
and class, because we
know they are not.


The user is free to use a version he likes, but if it contains a bug and there is a new one out that 
fixes it, it is a matter of course to upgrade to that version.



I will also add that, if our concern is with inexperienced users, then telling them 
Well, you need
to update your europecv package doesn't strike me as very helpful. This is not 
something that even
an average user knows how to do. (And no, not one of my machines uses any kind 
of TeX package manager.)


What is so complicated to use a TeX engine with a package manager? I also use TeXLive and there I 
got to the package manager search for europeCV, click to update it and that's it. I cannot image why 
this is in your opinion too complicated for everybody - this is self-explanatory. What is your TeX 
engine?
However, we cannot be

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 17.12.2012 17:19, schrieb Jean-Marc Lasgouttes:


While looking into moderncv.cls, I saw an interesting line:
   \RequirePackageWithOptions{moderncvcompatibility}

Looking inside this file is indeed interesting:
   % compatibility with version 0.1
   \newcommand*{\cvresume}[2]{\cvlistdoubleitem{#1}{#2}}

   % compatibility with versions = 0.2
   % section, cvline, ... with width argument...
   %\newcommand*{\section}[2][0.825]{%
   %  \closesection{}%
[...]

So, Uwe, are you sure that you the problem you fixed is real? It seems that the 
moderncv author did
his homework and that he takes backward compatibility seriously. Do we really 
need to update the
layout file every release???


Thanks for the pointer, I will have a look.
This is nevertheless independent of the general discussion, see my mail I just 
sent.

Even if there is a way to keep backward compatibility the compatibility between minor LyX versions 
will be broken as soon as I add a layout. And I tried hard to get my document compilable without 
adding new styles to the layout.
I admit that the old modernCV layout was far from being optimal but also the modernCV class itself 
was very fragile until the underlying table structure was removed. Looking back I learned that it 
was not a good idea to write a layout for a document class which just appeared on CTAN. I wrote the 
layout because I needed a CV and modernCV looked the best.


thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 16.12.2012 19:33, schrieb Richard Heck:


1. backward compatibility


Perhaps I am reading too much into this, but if your main concern is the 
example or template file,
then there is no issue here. I have already said that I have no objection to 
making the example and
template files be up to date, in the sense that they use the updated layout. 
It's just that this
layout will have a new name. So this is not an issue.


I am referring to the fact that we need to keep the layout files up to date corresponding do their 
.cls file. It is in my opinion not acceptable that adding a new style to a layout file should not be 
allowed for branch. And that is the most important point for me and the reason why I fight!


Our layouts are offers to the users. LyX is only as useful as its layout files are. So if you want 
to use a new feature of your preferred class, your should not be forced to learn tricky TeX-code, 
play with ERT or preamble code. LyX should offer this!!! And waiting 2 years for the next major LyX 
release is in modern times no option.
(I'm still wondering about your (LyX developers) experiences. In my our potential user group 
(students scientific researchers) wants a system that works out of the box will as much as possible 
features. If you tell them they have to enter TeX-code they will immediately go back to Word. Trust 
me - I already introduced LyX to so many people and gave courses. The Windows installer was one 
consequence of it: just click a few times OK and next and you get a fully functional system. The 
other consequences was to write layout file and to offer a thesis template.)



2. scientific document classes


If this is about the template, then again there is no issue here: It can use 
the updated layout. And
this will make it easier for inexperienced users to choose the right layout, 
since they will very
often start with the template.


No, it is about the fact that we must provide an up to date layout file for scientific classes that 
allow to fulfill the submission guidelines. Otherwise the layouts for that document class types are 
quite useless. Imagine how frustrating it is to write a paper but when submitting it, the automated 
submission systems will deny your file not telling you why exactly. Personally I had this case 
twice. It cost me about a day to find out that images were too wide and the image caption was not 
above the image but below (or something similar, can't remember it exactly). I can imagine that an 
average user would the next time not use LyX but directly LaTeX or Word. So if Lyx should be 
attractive to use it for sientific reasearchers, we must assure that the submission guidelines are 
fulfilled or we drop support for these document classes to be consequent.



3. "my LaTeX system is too old"


Obviously, there are extreme cases we cannot support.


But where do you draw the line what to support and what not? LyX is an offer to the users and as 
such as user I can expect to get a fully featured program.
I already explained why for me discussion about this topic is very, very strange. Let's face the 
reality: every program you can purchase or download offers bugfixes and new features from time to 
time. The time period between releases is usually some months for good reasons because all the time 
bugs occur and have to be fixed. No matter if you have to pay for support or not, only the latest 
version is supported (except of some fundamental programs like an OS). LyX does the same and when we 
get a bug report that LyX 2.0.2 contains a bug, we since ever replied "use LyX 2.0.5" where the bug 
is fixed. The same is with all LaTeX-packages, and third-party programs we use.
To be drastic: Would you use a one-year old Firefox or Java or Flash or Python? Of course not 
because the old versions have known vulnerabilities.

That Software needs to be updated from time to time is a matter of course.


But we need to be sensitive to a range of
different platforms and what TeX installations are currently being used on 
them. We should not just
assume that everyone is using the latest and greatest version of every package 
and class, because we
know they are not.


The user is free to use a version he likes, but if it contains a bug and there is a new one out that 
fixes it, it is a matter of course to upgrade to that version.



I will also add that, if our concern is with inexperienced users, then telling them 
"Well, you need
to update your europecv package" doesn't strike me as very helpful. This is not 
something that even
an average user knows how to do. (And no, not one of my machines uses any kind 
of TeX package manager.)


What is so complicated to use a TeX engine with a package manager? I also use TeXLive and there I 
got to the package manager search for europeCV, click to update it and that's it. I cannot image why 
this is in your opinion too complicated for everybody - this is self-explanatory. What is your TeX 
engine?
However, we cannot be

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Am 17.12.2012 17:19, schrieb Jean-Marc Lasgouttes:


While looking into moderncv.cls, I saw an interesting line:
   \RequirePackageWithOptions{moderncvcompatibility}

Looking inside this file is indeed interesting:
   % compatibility with version 0.1
   \newcommand*{\cvresume}[2]{\cvlistdoubleitem{#1}{#2}}

   % compatibility with versions <= 0.2
   % section, cvline, ... with width argument...
   %\newcommand*{\section}[2][0.825]{%
   %  \closesection{}%
[...]

So, Uwe, are you sure that you the problem you fixed is real? It seems that the 
moderncv author did
his homework and that he takes backward compatibility seriously. Do we really 
need to update the
layout file every release???


Thanks for the pointer, I will have a look.
This is nevertheless independent of the general discussion, see my mail I just 
sent.

Even if there is a way to keep backward compatibility the compatibility between minor LyX versions 
will be broken as soon as I add a layout. And I tried hard to get my document compilable without 
adding new styles to the layout.
I admit that the old modernCV layout was far from being optimal but also the modernCV class itself 
was very fragile until the underlying table structure was removed. Looking back I learned that it 
was not a good idea to write a layout for a document class which just appeared on CTAN. I wrote the 
layout because I needed a CV and modernCV looked the best.


thanks and regards
Uwe

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 16/12/2012 19:33, Richard Heck a écrit :

Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't do that
now, as you said. Why would we have to do it then? Are you worried that,
if a layout is tied to a version thus:
 version=0.15
then somehow it stops working when the version changes? We can mark
layouts as
  version=0.15-
and then if we release a new version after a couple releases, we can
change the old one to:
 version=0.15-0.19
with the new version now being:
 version=0.20-
collaborate with others who are using different versions, too.


Just a technical point: I am not sure that it will be so easy to get the 
file version in configure.py. It is of course doable, but I fear we have 
to resort to hand-written grep patterns for some layouts.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2012-12-17 Thread Richard Heck


On 12/17/2012 04:57 AM, Jean-Marc Lasgouttes wrote:

Le 16/12/2012 19:33, Richard Heck a écrit :

Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't do that
now, as you said. Why would we have to do it then? Are you worried that,
if a layout is tied to a version thus:
 version=0.15
then somehow it stops working when the version changes? We can mark
layouts as
  version=0.15-
and then if we release a new version after a couple releases, we can
change the old one to:
 version=0.15-0.19
with the new version now being:
 version=0.20-
collaborate with others who are using different versions, too.


Just a technical point: I am not sure that it will be so easy to get 
the file version in configure.py. It is of course doable, but I fear 
we have to resort to hand-written grep patterns for some layouts.


How does LaTeX figure out the version, if we include that in 
\usepackage? Or is that the worry, that not all classes do it the same way?


I was kind of thinking that we'd actually make this check in 
chkconfig.ltx. Perhaps using something like:

\usepackage[version]{pkgtotest}
and then see if we actually got it? I guess maybe that's harder (or 
impossible) for classes?


rh

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 17/12/2012 16:32, Richard Heck a écrit :

How does LaTeX figure out the version, if we include that in
\usepackage? Or is that the worry, that not all classes do it the same way?

I was kind of thinking that we'd actually make this check in
chkconfig.ltx. Perhaps using something like:
 \usepackage[version]{pkgtotest}
and then see if we actually got it? I guess maybe that's harder (or
impossible) for classes?


The problem is that we cannot \usepackage 50 different packages in a 
same latex instance without and expect that there will be no conflict. 
It is not doable IMO.


In moderncv, I see:

\ProvidesClass{moderncv}[2008/06/17 v0.7 modern curriculum vitae 
document class]


The version is not relevant, since LaTeX identification is based on 
dates. This date should be easy enough to grep out for most classes, but 
I suspect some cases will require us to do explicit code.


[However, read below]

While looking into moderncv.cls, I saw an interesting line:
  \RequirePackageWithOptions{moderncvcompatibility}

Looking inside this file is indeed interesting:
  % compatibility with version 0.1
  \newcommand*{\cvresume}[2]{\cvlistdoubleitem{#1}{#2}}

  % compatibility with versions = 0.2
  % section, cvline, ... with width argument...
  %\newcommand*{\section}[2][0.825]{%
  %  \closesection{}%
[...]

So, Uwe, are you sure that you the problem you fixed is real? It seems 
that the moderncv author did his homework and that he takes backward 
compatibility seriously. Do we really need to update the layout file 
every release???


I wonder whether the problem we are trying to solve is real.

JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch


Le 16/12/2012 19:33, Richard Heck a écrit :

Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't do that
now, as you said. Why would we have to do it then? Are you worried that,
if a layout is tied to a version thus:
 version=0.15
then somehow it stops working when the version changes? We can mark
layouts as
  version=0.15-
and then if we release a new version after a couple releases, we can
change the old one to:
 version=0.15-0.19
with the new version now being:
 version=0.20-
collaborate with others who are using different versions, too.


Just a technical point: I am not sure that it will be so easy to get the 
file version in configure.py. It is of course doable, but I fear we have 
to resort to hand-written grep patterns for some layouts.


JMarc

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch

2012-12-17 Thread Richard Heck


On 12/17/2012 04:57 AM, Jean-Marc Lasgouttes wrote:

Le 16/12/2012 19:33, Richard Heck a écrit :

Let me address the last point first. I do not see why you think
versioning makes more work. Why would you have to write three different
layouts? To support every single version of moderncv? We don't do that
now, as you said. Why would we have to do it then? Are you worried that,
if a layout is tied to a version thus:
 version=0.15
then somehow it stops working when the version changes? We can mark
layouts as
  version=0.15-
and then if we release a new version after a couple releases, we can
change the old one to:
 version=0.15-0.19
with the new version now being:
 version=0.20-
collaborate with others who are using different versions, too.


Just a technical point: I am not sure that it will be so easy to get 
the file version in configure.py. It is of course doable, but I fear 
we have to resort to hand-written grep patterns for some layouts.


How does LaTeX figure out the version, if we include that in 
\usepackage? Or is that the worry, that not all classes do it the same way?


I was kind of thinking that we'd actually make this check in 
chkconfig.ltx. Perhaps using something like:

\usepackage[version]{pkgtotest}
and then see if we actually got it? I guess maybe that's harder (or 
impossible) for classes?


rh

Re: Restart layout update discussion; was: Re: [patch] final layout patches for branch