Re: Issues to discuss for 2.2.0rc1
Scott Kostyshak wrote: > > Headers of .po files usually contains the last translator, > > This is what Kornel's script takes care of automatically. I just send bunch of direct emails for the translators. Lets see. P
Re: possible tag and tar of 2.2.0rc1 on Tuesday
Le 01/04/2016 04:43, Scott Kostyshak a écrit : 1. At #10019 Guillaume fixed some ui regressions. The patch seems short and logical and Stephan has tested it with success on Mac. I would still like to see if someone can test it on Windows before it is included. If anyone with Qt knowledge can take a look at the patch, that would also be nice. I think normally I would not want any .ui changes in at this point (for the reasons I listed on that ticket), but since they are fixing regressions it would be nice to have. If someone thinks this is important and we do not get a Windows user to test, we could potentially put the patch in and make sure some of our Windows rc1 testers test specifically this dialog. To be more precise, the reason why Scott wants platform-specific tests is because .ui changes have introduced in the past bugs showing with certain configurations only. The reason why this patch is important is that it solves the precise kind of issue that Scott fears it might introduce, whereby the dimensions of the new UI introduced with 2.0 do not take into account the localisation and platform-specific themes. Therefore, by not having feedback on win or a separate +1, the team would be publishing a UI change which is known to be buggy, just to avoid bugs which we do not know they exist.
Re: Replacement of "long table" by "multi-pages table" in the manuals
On Fri, Apr 01, 2016 at 04:20:56PM -0700, Pavel Sanda wrote: > > I was not aware of any changelogs translators use, I believe that CT was > used to signalize new things in manuals. Yes but after we send the manuals out and are waiting for them to be translated we don't want to change them in our repos before we get them back because once we get the translated ones back we will overwrite the ones in our repos. This way we don't modify our manuals until they come back and then we process the change log. That is what I understand, at least. Scott signature.asc Description: PGP signature
Re: Replacement of "long table" by "multi-pages table" in the manuals
Scott Kostyshak wrote: > > >>I was asking about the other manuals, actually. > > > > > >They are at lib/doc/attic/Changelog-* > > > > I see. Why is that in attic? It does not make any sense to me, attic/ if for > > obsolete stuff IMO. > > This location was not intuitive to me either. Perhaps it was chosen > because that way it will not ship with LyX? Kind of. These are files which no normal user should ever see and we know it is so obsolete that it deserves deletion, but it might be of interest for developer/translator who appears in future and wants to give new shape or get inspiration. I was not aware of any changelogs translators use, I believe that CT was used to signalize new things in manuals. Pavel
Re: Issues to discuss for 2.2.0rc1
On Fri, Apr 01, 2016 at 04:00:20PM -0700, Pavel Sanda wrote: > Georg Baum wrote: > > Where can I get a > > current list of the email addresses of the translators? > > Headers of .po files usually contains the last translator, This is what Kornel's script takes care of automatically. Scott > git log should help in case the mail is missing. > I would CC lyx doc list as well. signature.asc Description: PGP signature
Re: Issues to discuss for 2.2.0rc1
Georg Baum wrote: > Where can I get a > current list of the email addresses of the translators? Headers of .po files usually contains the last translator, git log should help in case the mail is missing. I would CC lyx doc list as well. Pavel
Re: Proposal for a guide on updating layouts
On 04/01/2016 01:29 PM, Jean-Marc Lasgouttes wrote: > Le 01/04/2016 18:15, Richard Heck a écrit : >> I do not know how to do the LaTeX part, but I am assuming someone else >> will. Once we have that, the idea would be to have a layout tag like: >> >> IfVersion whatever.cls >= 0.9 >> >> EndIfVersion > > Version testing is done via date in latex. So I would do > > IfNewer > ... > EndIf OK, that seems reasonable. > I can indeed do the LaTeX part. Thanks in advance. Where should we put this information so LyX can find it? Into textclass.lst? Richard
Re: Proposal for a guide on updating layouts
On 2016-03-25, Scott Kostyshak wrote: > Dear all, > This email is my attempt to respond to what I think is a great idea [1] from > Uwe: > "So why can't there be a step by step rule in our development.lyx that > everybody can understand? That would be the decision." I tried to start a chapter about new and updated layouts in Development.lyx. Of course, this is a biased view based on my experiences and ideas, so please correct and amend before this can be the base for a consensus. Patch below, OK to commit? Günter diff --git a/lib/doc/Development.lyx b/lib/doc/Development.lyx index 11711a2..f5a4168 100644 --- a/lib/doc/Development.lyx +++ b/lib/doc/Development.lyx @@ -271,6 +271,45 @@ style in any layout file or module shipped with \SpecialChar LyX future. \end_layout +\begin_deeper +\begin_layout Standard +From http://permalink.gmane.org/gmane.editors.lyx.devel/161202 +\end_layout + +\begin_layout Description +Pro "new layout files are a file format change": +\end_layout + +\begin_layout Itemize +All documents produced by 2.2.x can always be edited and exported even if + x is different. + This is important for people using different machines, or echanging work + wth colleagues. +\end_layout + +\begin_layout Description +Con "new layout files are a file format change": +\end_layout + +\begin_layout Itemize +No new LaTeX classes can't be supported in a stable version. +\end_layout + +\begin_layout Itemize +We have the same situation already with custom layout files: If a document + using a custom layout file is interchanged, the layout file needs to be + interchanged as well. + If that is not done, then we have a fallback implemented so that such documents + can still be edited, but not exported, and the user gets a warning. + +\end_layout + +\begin_layout Itemize +lyx2lyx cannot do anything useful on backward conversion, and the forward + conversion would be a noop +\end_layout + +\end_deeper \begin_layout Description Automatically \begin_inset space ~ @@ -978,6 +1017,419 @@ lyx2lyx version. \end_layout +\begin_layout Section +New layouts +\end_layout + +\begin_layout Standard +\begin_inset Note Greyedout +status open + +\begin_layout Description +Note: This section is currently only a proposal under discussion. + Please correct/amend as suited. + Remove this note once a consensus is found. +\end_layout + +\begin_layout Plain Layout +Summary of a recent discussion in lyx-devel by GM. +\end_layout + +\begin_layout Plain Layout +See the thread +\begin_inset Quotes eld +\end_inset + +Proposal for a guide on updating layouts +\begin_inset Quotes erd +\end_inset + + for details and background +\end_layout + +\begin_layout Plain Layout +http://permalink.gmane.org/gmane.editors.lyx.devel/161126 +\end_layout + +\end_inset + + +\end_layout + +\begin_layout Standard +Adding a new layout to the LyX library makes this an +\begin_inset Quotes eld +\end_inset + +officially supported +\begin_inset Quotes erd +\end_inset + + layout. +\end_layout + +\begin_layout Itemize +You should be committed to update and fix the layout if necessary. +\end_layout + +\begin_layout Itemize +Experimental and rarely used layouts should rather stay in the LyX wiki + (as user-contributed). +\end_layout + +\begin_layout Itemize +It may be good to propose the new layout on lyx-devel and ask for opinions + before actually comitting. +\end_layout + +\begin_layout Itemize +Adding a new layout currently requires a file format change, but this may + change eventually. + See +\begin_inset CommandInset ref +LatexCommand ref +reference "sec:When-is-an" + +\end_inset + + +\end_layout + +\begin_layout Standard +Steps: +\end_layout + +\begin_layout Itemize +Put your layout file in +\begin_inset Flex Code +status collapsed + +\begin_layout Plain Layout +lib/layouts/ +\end_layout + +\end_inset + + and add it to Git. +\end_layout + +\begin_layout Itemize +Add an entry in +\begin_inset Flex Code +status collapsed + +\begin_layout Plain Layout +lib/Makefile.am +\end_layout + +\end_inset + +, so that the new layout actually gets installed. +\end_layout + +\begin_layout Itemize +Add an entry in +\begin_inset Flex Code +status collapsed + +\begin_layout Plain Layout +lib/doc/LaTeXConfig.lyx +\end_layout + +\end_inset + + containing in particular a line like +\end_layout + +\begin_deeper +\begin_layout Quote +Found: [InsetInfo] +\end_layout + +\begin_layout Standard +\paragraph_spacing single +where [InsetInfo] is obtained by entering in the minibuffer (Alt+X) +\begin_inset Flex Code +status collapsed + +\begin_layout Plain Layout +\paragraph_spacing single +info-insert textclass +\end_layout + +\end_inset + +. + This inset will automatically display a boxed +\begin_inset Quotes eld +\end_inset + +yes +\begin_inset Quotes erd +\end_inset + + or +\begin_inset Quotes eld +\end_inset + +no +\begin_inset Quotes erd +\end_inset + + depending on the availability of the package. +\end_layout + +\end_deeper +\begin_layout Itemize
Re: possible tag and tar of 2.2.0rc1 on Tuesday
Scott Kostyshak wrote: > 2. There is a mysterious crash with the MSVC2015 > http://www.lyx.org/trac/ticket/10009 which does not happen with a merged > build. Since we do not understand why a merged build "fixes" the crash we > do not know what other problems might be created by the same cause. Note that Peter made some further tests and found out that the merged build does not fix the crash, but only hides it: http://www.lyx.org/trac/ticket/10009 > Where should we provide the unofficial installers (i.e. where should > they be stored)? I would put them at the same location as the official ones, but put something like unofficial or experimental in the file name, and explain in a README file that it is onls for curious people or those who have some problems with the other versions. > 2. Enrico has provided a patch regarding separators here: > https://www.mail-archive.com/search?l=mid=20160313003332.GA8700%40giove > It is a file format change, I think it would be nice to include because > otherwise users will have to get used to new behavior in 2.2.0 and then > get used to changed behavior again in 2.3.0. I do not understand the > issue though since I rarely use separators. I did not really follow the separator discussions, but the argument Enrico made that the current behaviour would be partly reverted is a very strong one in favour of the patch. It would be really nice if someone more familiar with this stuff could give a +1. Georg
Re: layouts and file format changes (was: possible tag and tar of 2.2.0rc1 on Tuesday)
On Fri, Apr 01, 2016 at 08:39:14AM +, Guenter Milde wrote: > Dear all, > > > On 2016-04-01, Scott Kostyshak wrote: > > > Günter has proposed layout patches to respond to changes in updated > > LaTeX class files at the following two threads: > > (acmsiggraph) > > https://www.mail-archive.com/search?l=mid=ndgr7a%24kuf%241%40ger.gmane.org > > (aastex6) > > https://www.mail-archive.com/search?l=mid=ndj02g%244ht%241%40ger.gmane.org > > For these patches to go in, we would need a consensus on the decision: > > New layouts and layouts with new styles/insets: > > *do* require a file format change (status quo, see Development.lyx) > > or > > do *not* require a file format change if no lyx2lyx action is required. > > > For the pros and cons see the recent thread on a policy for layout > updates. For consequences, see the alternatives below. From what I understand, you, Richard, and Georg are the ones who have participated the most in the layout discussion and you are mostly in agreement with each other, so I'm fine with whatever you all decide as far as 2.2.0. Thanks for your help on this complicated issue, Scott signature.asc Description: PGP signature
Re: patch for aastex6
On Fri, Apr 01, 2016 at 12:08:59PM -0400, Richard Heck wrote: > On 03/31/2016 03:45 PM, Georg Baum wrote: > > Guenter Milde wrote: > > > >> For a safe "last minute commit", it would be good if somone could check > >> the code itself, and the notes in the updated template and example file > >> and then give an explicit +1 or not. > > I did not test anything, but I looked at the code and the notes. They are > > all OK. The following is missing: > > > > - An entry in lib/Makefile.am, so that lib/layouts/aastex6.layout actually > > gets installed > > - An entry in lib/doc/LaTeXConfig.lyx for aastex6.cls > > - A final decision whether new layout files require a file format change or > > not. So far it looks like we agree that no file format change is needed, > > but > > to be correct I'd like to see that documented in Development.lyx before we > > add new layout files without lyx2lyx. > > Yes, I believe that is our decision. But it should be documented, as you > say. Documentation first would be nice. Scott signature.asc Description: PGP signature
Re: patch for aastex6
Guenter Milde wrote: > On 2016-03-31, Georg Baum wrote: >> Guenter Milde wrote: > >>> For a safe "last minute commit", it would be good if somone could check >>> the code itself, and the notes in the updated template and example file >>> and then give an explicit +1 or not. > >> I did not test anything, but I looked at the code and the notes. They are >> all OK. The following is missing: > >> - An entry in lib/Makefile.am, so that lib/layouts/aastex6.layout >> actually gets installed > > This is easy: > > diff --git a/lib/Makefile.am b/lib/Makefile.am > index 80463f4..cdad5cd 100644 > --- a/lib/Makefile.am > +++ b/lib/Makefile.am > @@ -1966,6 +1966,7 @@ dist_layouts_DATA =\ > layouts/aapaper.inc \ > layouts/aapaper.layout \ > layouts/aastex.layout \ > + layouts/aastex6.layout \ > layouts/achemso.layout \ > layouts/acm-sigs.layout \ > layouts/acm-sigs-alt.layout \ > >> - An entry in lib/doc/LaTeXConfig.lyx for aastex6.cls > > This is tricky, because LaTeXConfig.lyx is a generated file. The addition > needs to be done at some other place. It used to be generated, it is not generated anymore. You can simply edit it in LyX. > (Both requirements should be documented in Development.lyx) I'll add a note about LaTeXConfig.lyx. I don't think we should start with Makefile.am, if we do this we'll have to write a lot of stuff, e.g. what to do when adding a new .cpp file etc. >> - A final decision whether new layout files require a file format change >> or not. So far it looks like we agree that no file format change is >> needed, but to be correct I'd like to see that documented in >> Development.lyx before we add new layout files without lyx2lyx. > > > Yes. Currently there is the passus: > > 2.2 When is an update of the .lyx file format number needed? > > ... > > New style in any layout file or module shipped with LyX, or new shipped > layout file or module. These requirements are currently under discussion > and might change in the future. > > So what would be the procedure to get this rule lifted (rsp. replaced by a > less restrictive procedure for adding/updating modules)? I'll send a suggestion as well (tomorrow). IMO the procedure for changing existing layout files or modules is fine and should be kept: We have a mechanism to do changes in branch in a safe way, and in contrast to adding a new document class we can do meaningful stuff in lyx2lyx when adding/removing a new new style in an exiting layout file or module. Georg
Re: possible tag and tar of 2.2.0rc1 on Tuesday
On Fri, Apr 01, 2016 at 12:02:39PM +0200, Helge Hafting wrote: > > > Den 01. april 2016 04:43, skrev Scott Kostyshak: > > > >The disadvantages of using Qt 5.6.0 instead of 5.5.1 are the following: > > > >1. Although Uwe tested and it works for him, no one else has tested. We would > >thus lose all Windows-specific testing effort of the beta testers. > > > I have also used lyx-2.2dev with qt 5.6.0 since qt 5.6 was released for arch > linux. (64-bit) > Initially, I used it for my translation effort - but I have not seen any new > problems so > I also uses this version for work now. > > I have not made a special effort to _test_, other than looking at a lot of > dialogs to check the > translated strings. writing stuff with with 'KOMA article' and 'beamer' > presentations has been fine so far. > Scrolling through the user guide also works well. I use lyx on 2 machines. It is good to hear that things work well. I also use LyX with 5.6.0 on Ubuntu and have been using it since 5.6.0alpha1 and everything works well. This isn't so important though because we do not release binary installers for Linux so we don't have to pick a version of Qt to ship with. Qt has many platform-specific issues so our testing doesn't necessarily translate to testing 5.6.0 on Windows, although it a better signal than nothing. What I didn't fully grasp until it was explained to me is that even more important than testing Qt 5.6.0 is testing a binary built from a new compiler version. Scott signature.asc Description: PGP signature
Re: Proposal for a guide on updating layouts
Le 01/04/2016 18:15, Richard Heck a écrit : I do not know how to do the LaTeX part, but I am assuming someone else will. Once we have that, the idea would be to have a layout tag like: IfVersion whatever.cls >= 0.9 EndIfVersion Version testing is done via date in latex. So I would do IfNewer ... EndIf I can indeed do the LaTeX part. JMarc
Re: Proposal for a guide on updating layouts
On 03/31/2016 05:35 PM, Scott Kostyshak wrote: > On Tue, Mar 29, 2016 at 12:53:15PM -0400, Richard Heck wrote: > >>> How about a "LyX layout repository" with supported¹ layouts at an >>> "official" URL (something like www.lyx.org/ressources/layouts/ or >>> similar, maybe with subdirs for major LyX versions, ...) as a first step? >> Yes, this is exactly what I had in mind, and I've been thinking about >> how best to do it. We do not want to have to manage that directory >> manually. The files are in the git repo, so we just have to figure out >> how to access them. Some trickery using modrewrite might work. Or some >> PHP code. > Regarding version detection, do you have an idea for the implementation? (if > you want, you can make a trac ticket regarding versioning and we can move the > discussion there) I do not know how to do the LaTeX part, but I am assuming someone else will. Once we have that, the idea would be to have a layout tag like: IfVersion whatever.cls >= 0.9 EndIfVersion possibly with some "else" stuff in there, too. On the other hand, Georg has suggested some reservations about how extensively we'd want to use this, and those need to be thought through. Richard
Re: patch for aastex6
On 03/31/2016 03:45 PM, Georg Baum wrote: > Guenter Milde wrote: > >> For a safe "last minute commit", it would be good if somone could check >> the code itself, and the notes in the updated template and example file >> and then give an explicit +1 or not. > I did not test anything, but I looked at the code and the notes. They are > all OK. The following is missing: > > - An entry in lib/Makefile.am, so that lib/layouts/aastex6.layout actually > gets installed > - An entry in lib/doc/LaTeXConfig.lyx for aastex6.cls > - A final decision whether new layout files require a file format change or > not. So far it looks like we agree that no file format change is needed, but > to be correct I'd like to see that documented in Development.lyx before we > add new layout files without lyx2lyx. Yes, I believe that is our decision. But it should be documented, as you say. Richard
Re: patch for acmsiggraph
On 03/31/2016 02:27 PM, Georg Baum wrote: > Guenter Milde wrote: > >> Thinking about it while writing aastex6.layout, there is a major >> disadvantage of the "old loads new" approach: >> >> * aastex6.layout inputs aastex.layout and currently only changes the name >> and referenced LaTeX class file. >> >> I future, it should also support commands new in aastex v. 6. >> >> Adding new styles to aastex6.layout is simple and does not require any >> changes to the old aastex.layout. >> >> OTOH, if the old aastex.layout would input the new aastex6.layout, any >> adding of a new style there would require a new "NoStyle" in the old >> layout. >> >> >> Generally, as the old layout is stable but the new a "moving target", the >> method "new loads old" is preferable, as this allows to keep "old" at the >> proven status. (This is als important, because we usually do not test with >> obsolete LaTeX classes/packages.) > Very good point. For me personally this is the killer argument for always > doing "new loads old". Fine by me, then. Richard
Re: Proposal for a guide on updating layouts
Den 28. mars 2016 12:50, skrev Georg Baum: It all boils down to the question: Is the addition of a new .layout file a file format change or not? It does not make sense to treat new layouts differently in stable and master, so either it is a file format change in master (and can't be put directly into the stable version), or it is not, and then it can simply be added both to master and stable. The same question is valid BTW for new modules. Currently we are a bit inconsistent here: New modules are not treated as file format changes, but new layouts are. IMO, we should make a list of pros and cons for "new layout files are a file format change", and the same for modules. I guess that a decision will not be difficult once we have such an explicit list. Below you can find the pros and cons I am currently aware of: Pro "new layout files are a file format change": - All documents produced by 2.2.x can always be edited and exported even if x is different. This is important for people using different machines, or echanging work wth I am very happy that a new LyX does not break existing documents. Such compatibility is important for me as a user. When a new minor release is out, I can "just use it", trusting it to be ok. (Usually, a new major release is ok too.) I do not see a problem with adding new features (such as a new layout or a new latex class or a new inset or a new font) as long as it is _strictly new_, that is, no change to existing stuff. The only difference then, is that the "new lyx" can do something the "old lyx" could not. Anything the "old lyx" did is still supported - without change. But I see the potential for problems when users with different LyX versions collaborate, wonder if that happens a lot. Might be a problem with new features in general, but not with "new layouts": A new layout (without other upgrades) is particularly harmless - even a collaborator clinging to an older LyX of the same major version can open such a document if I give him the layout file. Which I can do, due to the nice licence. Even if he can't modify his LyX installation, he can use the new layout as a local layout. Given "no file format change", the new layout file is necessarily supported by the older lyx too, so no problems with new layouts. Therefore, I think new layouts are ok at any time - as long as the existing ones aren't modified. Helge Hafting
Re: Proposal for a guide on updating layouts
Am Freitag, 1. April 2016, 10:49:42 schrieb Jean-Marc Lasgouttes: > Le 31/03/2016 23:35, Scott Kostyshak a écrit : > > On Tue, Mar 29, 2016 at 12:53:15PM -0400, Richard Heck wrote: > >>> How about a "LyX layout repository" with supported¹ layouts at an > >>> "official" URL (something like www.lyx.org/ressources/layouts/ or > >>> similar, maybe with subdirs for major LyX versions, ...) as a first > >>> step? > >> > >> Yes, this is exactly what I had in mind, and I've been thinking about > >> how best to do it. We do not want to have to manage that directory > >> manually. The files are in the git repo, so we just have to figure out > >> how to access them. Some trickery using modrewrite might work. Or some > >> PHP code. > > > > Regarding version detection, do you have an idea for the implementation? > > (if you want, you can make a trac ticket regarding versioning and we can > > move the discussion there) > > Here is raw sketch of a possible scheme: > > Create a tree of layouts like > www.lyx.org/ressources/layouts/2.2.1/ > www.lyx.org/ressources/layouts/2.2.2/ > ... > > This tree could be a checkout of a special git tree. > > Each directory will contain the layouts available at current time for > the given version. This means that when we release, say, 2.2.3, we will > run a script that adds the new files to the 2.2.2, 2.2.1 and 2.2.0 > directories. In this way, each directory is self contained. > > Each directory will contain a contents.txt directory, containing lines like > thank you, that goes very much in the direction i had in mind in an earlier post. we could borrow from R repos here, which are very similar to debian repos -- a scheme with a lot of experience. they make a destinction between binary and source packages: bin/ windows/ contrib/ 3.0/ myPackage1_0.1-1.zip yourPackage_2.2-3.zip ... PACKAGES PACKAGES.gz 3.1/ myPackage1_0.1-1.zip yourPackage_2.2-3.zip ... PACKAGES PACKAGES.gz .../ src/ contrib/ myPackage1_0.1-1.tar.gz yourPackage_2.2-3.tar.gz ... PACKAGES PACKAGES.gz the client fetches PACKAGES (or the identical .gz compressed file), which is similar to "contents.txt" as you proposed. as long as this only deals with plain text layout files, one wouldn't need the binary branch. instead, all relevant information could be found in the PACKAGES/contents.txt file. it could look something like this: Package: apa6 Type: Layout Category: Articles Label: American Psychological Association (APA), v. 6 Depends: apa6,apacite.sty,endfloat.sty,endnotes.sty,flushend.sty,txfonts.sty Format: 49 MD5sum: f8c4c8727ddc6602cccb54d179704a82 Package: scrreprt Type: Layout Category: Reports Label: KOMA-Script Report Format: 49 MD5sum: f303b11685174ee0875e2df98b716301 Package: tcolorbox Type: Module Label: Fancy Colored Boxes Description: Adds custom insets that support colored boxes via the tcolorbox package. See the tcolorbox documentation for details. Depends: tcolorbox.sty Format: 48 MD5sum: db072df89a8a6d7cc27ea9e08b242a5f which is all information that could be automatically extracted from the layout files themselves. LyX version dependencies and version numbers for each layout file could be added. i don't know if this would solve all problems, or wheter adding a version string to each layout file would be an improvement or introduce too much complexity. just a suggestion. viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part.
Re: possible tag and tar of 2.2.0rc1 on Tuesday
Den 01. april 2016 04:43, skrev Scott Kostyshak: The disadvantages of using Qt 5.6.0 instead of 5.5.1 are the following: 1. Although Uwe tested and it works for him, no one else has tested. We would thus lose all Windows-specific testing effort of the beta testers. I have also used lyx-2.2dev with qt 5.6.0 since qt 5.6 was released for arch linux. (64-bit) Initially, I used it for my translation effort - but I have not seen any new problems so I also uses this version for work now. I have not made a special effort to _test_, other than looking at a lot of dialogs to check the translated strings. writing stuff with with 'KOMA article' and 'beamer' presentations has been fine so far. Scrolling through the user guide also works well. I use lyx on 2 machines. Helge Hafting
Re: Proposal for a guide on updating layouts
Le 31/03/2016 23:35, Scott Kostyshak a écrit : On Tue, Mar 29, 2016 at 12:53:15PM -0400, Richard Heck wrote: How about a "LyX layout repository" with supported¹ layouts at an "official" URL (something like www.lyx.org/ressources/layouts/ or similar, maybe with subdirs for major LyX versions, ...) as a first step? Yes, this is exactly what I had in mind, and I've been thinking about how best to do it. We do not want to have to manage that directory manually. The files are in the git repo, so we just have to figure out how to access them. Some trickery using modrewrite might work. Or some PHP code. Regarding version detection, do you have an idea for the implementation? (if you want, you can make a trac ticket regarding versioning and we can move the discussion there) Here is raw sketch of a possible scheme: Create a tree of layouts like www.lyx.org/ressources/layouts/2.2.1/ www.lyx.org/ressources/layouts/2.2.2/ ... This tree could be a checkout of a special git tree. Each directory will contain the layouts available at current time for the given version. This means that when we release, say, 2.2.3, we will run a script that adds the new files to the 2.2.2, 2.2.1 and 2.2.0 directories. In this way, each directory is self contained. Each directory will contain a contents.txt directory, containing lines like The LyX version will then be able to fetch this list and decide which files needs to be downloaded (probably because it has its own copy of the "current" contents.txt file). I guess it would not be terribly difficult to create a python script that populates the directories for the different versions. Of course, there may be situations where we do not want some version to update to a given layout file (because it triggers a bug, for example). Therefore we need a scheme here a script generates a lis of files that can be later modified by hand. I think it is safer to have separate directories for each version rather than a single layout directory and version-specific contents files that point to this common pool. JMarc
layouts and file format changes (was: possible tag and tar of 2.2.0rc1 on Tuesday)
Dear all, On 2016-04-01, Scott Kostyshak wrote: > Günter has proposed layout patches to respond to changes in updated > LaTeX class files at the following two threads: > (acmsiggraph) > https://www.mail-archive.com/search?l=mid=ndgr7a%24kuf%241%40ger.gmane.org > (aastex6) > https://www.mail-archive.com/search?l=mid=ndj02g%244ht%241%40ger.gmane.org For these patches to go in, we would need a consensus on the decision: New layouts and layouts with new styles/insets: *do* require a file format change (status quo, see Development.lyx) or do *not* require a file format change if no lyx2lyx action is required. For the pros and cons see the recent thread on a policy for layout updates. For consequences, see the alternatives below. Possible scenarios: 1. We decide (and note in Development.lyx), that new and updated layouts do *not* require a file format change. a) before Monday: -> the patches can go in rc1 (after a +1 for the acmsiggraph one) +1 better testing of new layouts before shipment of 2.2 -1 time pressure b) after rc1: -> patches can still go into 2.2.0 if Scott approves. -> patches can go into 2.2.x (as no file format change is required) 2. We decide, that new and updated layouts *do* require a file format change. -> I could commit the patches but would need a volunteer to do the file format update (currently I don't have the time to learn and perform this action). a) before Monday: -> patches can still go into 2.2.0 if Scott approves. b) after rc1: -1 new layouts will have to wait for 2.3 Case 2b is "mitigated", if we decide on an official repository (download URL) of new and update layouts for individuall installation. Then, users depending on the new layouts can still use a stable LyX. Günter
Re: Replacement of "long table" by "multi-pages table" in the manuals
Le 31/03/2016 21:18, Scott Kostyshak a écrit : Shall I update docs and layouts or will you do it before release? Yes please do it. The reason why I think it is preferable for you to do it is in the Development manual: "Update LyX's .lyx documentation files to the new format. The developer who makes the change knows best what changes to expect when inspecting the resulting diff. You are right. I did that. JMarc
