Re: Why don't we use layout2layout to update local layout?
Am 30.11.2015 um 02:35 schrieb Richard Heck: Note also that the use of higher formats does NOT mean the document cannot be exported. It means one will have to do manual fixup of local layout, to reduce the format number to something appropriate. But people who are messing with local layout will be able to handle this. It's a super-user feature. OK. But we use it in the docs. To solve the situation there, we could instead use the logical markup module and get rid of the LocalLayout. I will do this but cannot figure out how to use this module. regards Uwe
Re: Why don't we use layout2layout to update local layout?
On 11/29/2015 06:29 PM, Uwe Stöhr wrote: > Am 29.11.2015 um 22:13 schrieb Richard Heck: > >> There is no reversion in layout2layout, so this is not possible. That's >> why I suggested issuing a warning. > > That is bad. You see that my argumentation against backward > compatibility is sadly true - it costs us much manpower. > > In fact we need to keep the LocalLayout at version 7 (as it was) > because if we promise backwards compatibility then the user is free to > export e.g. to LyX 1.5.x, right? No, I don't see it that way. The question isn't whether it's OK to use local layout of higher versions. The question is whether we should *routinely* update the format for a new release. If there was some reason to do so---for example, you want to make use of some feature only available with later formats---then that'd be differfent. Note also that the use of higher formats does NOT mean the document cannot be exported. It means one will have to do manual fixup of local layout, to reduce the format number to something appropriate. But people who are messing with local layout will be able to handle this. It's a super-user feature. Still, we probably should issue an appropriate warning when we do the conversion. Richard
Re: [patch] use inkscape for EMF and WMF was: [LyX/master] installer: install Qt plugin DLLs correctly
Am 30.11.2015 um 01:57 schrieb Andrew Parsloe: When I discovered LyX about ten years ago, I saved my Word 95 documents as rtf and used rtf2latex2e to convert them to latex so that they could be imported into LyX. The figures in the Word documents were separated out by rtf2latex2e into wmf files. Interesting. So word is using WMF for RTF. I have to use Word every day and never noticed this. regards Uwe
Re: #9841: Preferences specific to the user and not to the file should not be recorded in the file
Guillaume Munch wrote: > You describe a method for this, above, but to me it sounds like a > cumbersome way to force-record the state of an inset (for instance, it I agree it is cumbersome, my reasoning was that I would rather impose this complexity on user who is using git & CT than complicating anything for user who just uses CT. Pavel
Re: [patch] use inkscape for EMF and WMF was: [LyX/master] installer: install Qt plugin DLLs correctly
On 30/11/2015 11:39 a.m., Uwe Stöhr wrote: Interestingly I could not find a single emf file on my PC. I also never stumbled over this image format at work. I downloaded now one and it appears that no browser can display this file format. So I am wondering what program created emf natively. regards Uwe When I discovered LyX about ten years ago, I saved my Word 95 documents as rtf and used rtf2latex2e to convert them to latex so that they could be imported into LyX. The figures in the Word documents were separated out by rtf2latex2e into wmf files. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Why don't we use layout2layout to update local layout?
Am 29.11.2015 um 22:13 schrieb Richard Heck: There is no reversion in layout2layout, so this is not possible. That's why I suggested issuing a warning. That is bad. You see that my argumentation against backward compatibility is sadly true - it costs us much manpower. In fact we need to keep the LocalLayout at version 7 (as it was) because if we promise backwards compatibility then the user is free to export e.g. to LyX 1.5.x, right? regards Uwe
Re: Font of LyX manuals
Am 26.11.2015 um 09:09 schrieb Guenter Milde:
No. Many users (including myself) don't use a *complete* TeX distribution
That makes me wonder. In the world around me everybody uses just click
and go. Why do you fiddle around to get a TeX subset when there is
TeXLive that you can install with a few clicks? (I have TeXLive as
well). Fiddling costs time and that is what people usually don't have.
But OK, it is as it is.
In this case I vote for the other solution you proposed:
---
b) use a simplified and "Unicode-clean" preamble code:
-\usepackage{ifpdf} % part of the hyperref bundle
-\ifpdf % if pdflatex is used
-
- % set fonts for nicer pdf view
- \IfFileExists{lmodern.sty}{\usepackage{lmodern}}{}
-
-\fi % end if pdflatex is used
+% use Latin Modern fonts if available
+\IfFileExists{lmodern.sty}{
+ \renewcommand{\rmdefault}{lmr}
+ \renewcommand{\sfdefault}{lmss}
+ \renewcommand{\ttdefault}{lmtt}
+}{}
We do not load lmodern.sty, because it also sets the fontencoding to T1
which is done by LyX anyway (with 8-bit TeX) and wrong for compiling
with Unicode fonts (non-TeX fonts).
-1 requires preamble code
+1 safe on any TeX installation.
-
I vote for this for your argument. We already have preamble code so that
it shouldn't matter that we will keep it in a changed form.
IMO, LM should not be required for the "simple" manuals.
What is simple? I would load lmodern if available in general, see above.
if not the default TeX fonts are used.
Since years also the Intro and Tutorial is using Latin Modern. Only
splash does not use it.
However, they use it "optionally" via preamble code. And compiling splash
takes ages because first the bitmap fonts need to be generated.
Interesting; here it is very quick.
I prefer PSNFSS fonts for simple manuals (splash, Intro, Tutorial).
OK.
Please try, e.g., Palatino, Helvetica, Courier and tell about problems.
What do you mean? They all work here.
regards Uwe
Re: [PATCH] Re: Regression in lyx2lyx box alignment
Am 29.11.2015 um 22:26 schrieb Jean-Marc Lasgouttes:
Why would the text in the minipage need different vertical spacing than
the main text? They are of same nature.
Well, the user is free to decide. if he likes it, why not? Note that i
am arguing for a method to set the alignment to ALL box types, also to
parboxes. Since we already provide this feature for makebox I don't see
a reason why we don't allow this for the other box types.
You basically argue that this vertical spacing is never wanted in LaTeX.
This is incorrect. If you use an environment to center things you will
get the space, but in other TeX editors you can decide if you use
\begin{center} or \centering. LyX doesn't give you this choice.
(Attached is an example)
- The box dialog provides an alignment for the whole box content. For
this setting \raggedleft etc. should be used for the WHOLE content of
the box, no matter if there are several paragraphs or not.
- The paragraph alignment is independent of this!!! (see the attached
example)
This separation between box alignment and paragraph alignment does not
exist in LaTeX. This is a creation that you propose.
Yes, because LyX doesn't allow you to choose between e.g. \begin{center}
or \centering.
That is exactly how I once implemented it. If adding BOX_CODE to
noTrivlistCentering does this, then this should be done.
Adding BOX_CODE to noTrivListCentering would make all paragraph
alignment changes use \raggedleft and friends.
Good.
I'd be interested to see what your real world use cases look like. I
tend to use hfills a lot instead of weird alignments. But probably we
don't use boxes in the same settings.
That is the important point. It is not important what we developers
prefer but to give the users the freedom to do what they like if LaTeX
allows this.
regards Uwe
#LyX 2.1 created this file. For more info see http://www.lyx.org/
\lyxformat 474
\begin_document
\begin_header
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman default
\font_sans default
\font_typewriter default
\font_math auto
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header
\begin_body
\begin_layout Standard
hello hello hello hello hello hello hello hello hello hello hello hello
hello hello hello hello hello hello hello hello hello hello hello hello
\end_layout
\begin_layout Standard
\align center
hello
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
hello hello hello hello hello hello hello hello hello hello hello hello
hello hello hello hello hello hello hello hello hello hello hello hello
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
\backslash
centering hello
\end_layout
\end_inset
\end_layout
\end_body
\end_document
Re: using std_regex on Windows leads to 135 compilation errors
Am Sonntag, 29. November 2015 um 23:44:54, schrieb Uwe Stöhr > Am 29.11.2015 um 22:30 schrieb Kornel Benko: > > > The problem may also be usage (respective non-usage) of --std=c++11. > > I already asked, what to do to allow MSVC to use this flag, but got no > > answer. > > ATM the windows compilation is probably without, setting the > > 'LYX_USE_CXX11' to 0 > > > > The changes could be built in > > development/cmake/modules/FindCXX11Compiler.cmake:37 ff > > The actual search is done at > > development/cmake/modules/FindCXX11Compiler.cmake:86 ff > > I would like to test this. Could you please send me a patch to be able > to test? > > thanks and regards > Uwe I have no patches. I described only where probably the code could be inserted. I don't know MSVC. Kornel signature.asc Description: This is a digitally signed message part.
Re: using std_regex on Windows leads to 135 compilation errors
Am 29.11.2015 um 22:30 schrieb Kornel Benko: The problem may also be usage (respective non-usage) of --std=c++11. I already asked, what to do to allow MSVC to use this flag, but got no answer. ATM the windows compilation is probably without, setting the 'LYX_USE_CXX11' to 0 The changes could be built in development/cmake/modules/FindCXX11Compiler.cmake:37 ff The actual search is done at development/cmake/modules/FindCXX11Compiler.cmake:86 ff I would like to test this. Could you please send me a patch to be able to test? thanks and regards Uwe
[patch] use inkscape for EMF and WMF was: [LyX/master] installer: install Qt plugin DLLs correctly
Am 28.11.2015 um 11:15 schrieb Georg Baum:
If there are problems with the installation then please ask on the list for
help and opinions.
I am the only Win developer here. My spare time is limited and the
installer consumes a lot of time.
The installer is there to provide a fully functional LyX, no matter if
installed with admin privileges or not. Metafile2eps was not available
without admin privileges.
Besides this, why should I invest my time to get this program working
while it is not part of LyX and not under development for 7 years now?
If emf conversion is important why is metafile2eps not developed
anymore. If the creator doesn't have time, he could contribute his code
to e.g. ImageMagick that this program is able to convert keeping the
vector information.
But to keeping the vector information is easy: Inkscape
Attached is a patch
To my knowledge, there was no development needed, and it simply works also
for newer windows versions, but Enrico can certainly tell more.
It never "simply" worked. It was not available for those who install LyX
without admin permissions and made troubles when LyX was uninstalled.
Yes, I can decide for myself, this is not the problem. My point is that it
is not up to you alone to decide that windows LyX users are no longer
offered a good quality emf->eps conversion,
With the attached patch this would be offered.
especially since emf is the
standard vector graphics format on windows.
Interestingly I could not find a single emf file on my PC. I also never
stumbled over this image format at work.
I downloaded now one and it appears that no browser can display this
file format. So I am wondering what program created emf natively.
regards Uwe
diff --git
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\con8416.tmp\\configure-7aeab53-left.py"
"b/D:\\LyXGit\\Master\\lib\\configure.py"
index dcf34c9..16c9844 100644
---
"a/C:\\Users\\Usti\\AppData\\Local\\Temp\\TortoiseGit\\con8416.tmp\\configure-7aeab53-left.py"
+++ "b/D:\\LyXGit\\Master\\lib\\configure.py"
@@ -957,11 +957,17 @@ def checkConverterEntries():
\converter tgif png"tgif -print -color -png -o $$d $$i" ""
\converter tgif pdf6 "tgif -print -color -pdf -stdout $$i > $$o"
""'''])
#
-checkProg('a WMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o
$$o $$i'],
+checkProg('a WMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o
$$o $$i', inkscape_name + ' --file=$$i --export-area-drawing --without-gui
--export-eps=$$o'],
rc_entry = [ r'\converter wmfeps"%%" ""'])
#
-checkProg('an EMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o
$$o $$i'],
+checkProg('an EMF -> EPS converter', ['metafile2eps $$i $$o', 'wmf2eps -o
$$o $$i', inkscape_name + ' --file=$$i --export-area-drawing --without-gui
--export-eps=$$o'],
rc_entry = [ r'\converter emfeps"%%" ""'])
+#
+checkProg('a WMF -> PDF converter', [inkscape_name + ' --file=$$i
--export-area-drawing --without-gui --export-pdf=$$o'],
+rc_entry = [ r'\converter wmfpdf6"%%" ""'])
+#
+checkProg('an EMF -> PDF converter', [inkscape_name + ' --file=$$i
--export-area-drawing --without-gui --export-pdf=$$o'],
+rc_entry = [ r'\converter emfpdf6"%%" ""'])
# Only define a converter to pdf6 for graphics
checkProg('an EPS -> PDF converter', ['epstopdf'],
rc_entry = [ r'\converter epspdf6 "epstopdf
--outfile=$$o $$i" ""'])
A margin-al question
Hello, I would like to know if it would be too difficult for you to implement an option that permits us to fix the margin between the text's border and LyX's window border. Currently, there is nearly zero margin, and that is something that slightly annoyed me for many years. I was wondering if the adoption of the new QT would allow for such an option. This is a question comfort rather than usability, but nevertheless... Best regards, Murat -- Prof. Murat Yildizoglu Université Montesquieu Bordeaux IV GREThA (UMR CNRS 5113) Avenue Léon Duguit 33608 Pessac cedex France Bureau : E-331 mail: yildi-at-u-bordeaux4.fr web: yildizoglu.info
Re: using std_regex on Windows leads to 135 compilation errors
Am Sonntag, 29. November 2015 um 21:50:24, schrieb Uwe Stöhr > As suggested in > http://www.lyx.org/trac/ticket/9373 > I tried to compile LyX on Windows with std_regex. When doing this, i get > these error messages (and many more): > The problem may also be usage (respective non-usage) of --std=c++11. I already asked, what to do to allow MSVC to use this flag, but got no answer. ATM the windows compilation is probably without, setting the 'LYX_USE_CXX11' to 0 The changes could be built in development/cmake/modules/FindCXX11Compiler.cmake:37 ff The actual search is done at development/cmake/modules/FindCXX11Compiler.cmake:86 ff Kornel signature.asc Description: This is a digitally signed message part.
Re: [PATCH] Re: Regression in lyx2lyx box alignment
Le 29/11/2015 22:13, Uwe Stöhr a écrit :
Am 27.11.2015 um 11:39 schrieb Jean-Marc Lasgouttes:
Are we sure that minipage always requires centering without extra
spacing? I am really not sure...
I am sure. See the attached file:
Emphasis was on "always" above. If your reasoning is correct, then iot
should hold for the top level text too. Remember that minipage is a
"mini page". For example I tend to use it for things like
Text text text text text text text text text text text text text text
text text text text text text text text text text text text text text
[Mini page 50% width [nice image here]
text text text text text
text text text text text
text text text text text
text text text text text
text text text text text
]
text text text text text text text text text text text text text
text text text text text text text text text text text text text
Why would the text in the minipage need different vertical spacing than
the main text? They are of same nature.
The paragraph separation in this file is the default - indentation not
vertical space.
So users just want to e.g. right-align a paragraph in the box. there is
no reason that vertical space is added. This is definitely not wanted.
You basically argue that this vertical spacing is never wanted in LaTeX.
This is an opinion I respct, but it has far-fetching consequences.
As I already said earlier, magic happens here:
bool noTrivlistCentering(InsetCode code)
{
return code == FLOAT_CODE
|| code == WRAP_CODE
|| code == CELL_CODE;
}
These are the inset codes for which we do not want to use \begin{center}
and friends but the more compact versions. It would not be difficult to
add boxes to the list, but I am not sure that this is a good idea.
I am asking for the LaTeX code that will be created in this case.
because we have to different settings we should not mix up:
- The box dialog provides an alignment for the whole box content. For
this setting \raggedleft etc. should be used for the WHOLE content of
the box, no matter if there are several paragraphs or not.
- The paragraph alignment is independent of this!!! (see the attached
example)
This separation between box alignment and paragraph alignment does not
exist in LaTeX. This is a creation that you propose.
That is exactly how I once implemented it. If adding BOX_CODE to
noTrivlistCentering does this, then this should be done.
Adding BOX_CODE to noTrivListCentering would make all paragraph
alignment changes use \raggedleft and friends.
I'd be interested to see what your real world use cases look like. I
tend to use hfills a lot instead of weird alignments. But probably we
don't use boxes in the same settings.
JMarc
Re: Why don't we use layout2layout to update local layout?
Am Sonntag, 29. November 2015 um 11:10:37, schrieb Richard Heck > On 11/29/2015 09:35 AM, Kornel Benko wrote: > > Am Sonntag, 29. November 2015 um 12:20:27, schrieb Georg Baum > > > >> Richard Heck wrote: > >>> We should presumably make a point of converting this stuff before a > >>> release. I've just done it for 2.2, at least for the English manuals. > >> Well, this has a drawback: If we do this, then all files using local > >> layouts > >> are not longer exportable to version 2.1. This is a pity, since only the > >> layout syntax changed, no new features are used. I would say we should > >> keep > >> at least the 2.1 format, unless a layout needs later features. > > +1 > > Shall I convert it back? > > Richard Unless there comes a better solution (like lyx converting also local layout), I'd say yes. Kornel signature.asc Description: This is a digitally signed message part.
Re: Why don't we use layout2layout to update local layout?
On 11/29/2015 03:33 PM, Uwe Stöhr wrote: > Am 29.11.2015 um 12:20 schrieb Georg Baum: > >> Well, this has a drawback: If we do this, then all files using local >> layouts >> are not longer exportable to version 2.1. > > Oh, that is a big problem in my opinion. I mean we promise backwards > compatibility but also provide in the document settings the button to > convert the LocalLayout to the latest format. But if the user uses > this button, his files are currently not reversable, right? > > To overcome this, layout2layout must be run for LocalLayouts when the > user reverses a document to an older LyX version. d There is no reversion in layout2layout, so this is not possible. That's why I suggested issuing a warning. Richard
Re: [PATCH] Re: Regression in lyx2lyx box alignment
Am 27.11.2015 um 11:39 schrieb Jean-Marc Lasgouttes:
Are we sure that minipage always requires centering without extra
spacing? I am really not sure...
I am sure. See the attached file:
The paragraph separation in this file is the default - indentation not
vertical space.
So users just want to e.g. right-align a paragraph in the box. there is
no reason that vertical space is added. This is definitely not wanted.
As I already said earlier, magic happens here:
bool noTrivlistCentering(InsetCode code)
{
return code == FLOAT_CODE
|| code == WRAP_CODE
|| code == CELL_CODE;
}
These are the inset codes for which we do not want to use \begin{center}
and friends but the more compact versions. It would not be difficult to
add boxes to the list, but I am not sure that this is a good idea.
I am asking for the LaTeX code that will be created in this case.
because we have to different settings we should not mix up:
- The box dialog provides an alignment for the whole box content. For
this setting \raggedleft etc. should be used for the WHOLE content of
the box, no matter if there are several paragraphs or not.
- The paragraph alignment is independent of this!!! (see the attached
example)
That is exactly how I once implemented it. If adding BOX_CODE to
noTrivlistCentering does this, then this should be done.
Georg, do you agree?
many thanks and regards
Uwe
#LyX 2.2 created this file. For more info see http://www.lyx.org/
\lyxformat 503
\begin_document
\begin_header
\origin unavailable
\textclass article
\use_default_options true
\maintain_unincluded_children false
\language english
\language_package default
\inputencoding auto
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\graphics default
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 1
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain
\use_bibtopic false
\use_indices false
\paperorientation portrait
\suppress_date false
\justification true
\use_refstyle 1
\index Index
\shortcut idx
\color #008000
\end_index
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\paragraph_indentation default
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\html_math_output 0
\html_css_as_file 0
\html_be_strict false
\end_header
\begin_body
\begin_layout Standard
Just a minipage with 3 paragraphs:
\end_layout
\begin_layout Standard
\begin_inset Box Boxed
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "30col%"
special "none"
height "1in"
height_special "totalheight"
thickness "0.4pt"
separation "3pt"
shadowsize "4pt"
framecolor "black"
backgroundcolor "none"
status open
\begin_layout Plain Layout
\align left
left
\end_layout
\begin_layout Plain Layout
\align right
right
\end_layout
\begin_layout Plain Layout
\align center
center
\end_layout
\end_inset
\begin_inset Box Boxed
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
use_makebox 0
width "30col%"
special "none"
height "1in"
height_special "totalheight"
thickness "0.4pt"
separation "3pt"
shadowsize "4pt"
framecolor "black"
backgroundcolor "none"
status open
\begin_layout Plain Layout
left
\end_layout
\begin_layout Plain Layout
right
\end_layout
\begin_layout Plain Layout
center
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Now the same, but the WHOLE content is right-aligned:
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
fbox{
\backslash
begin{minipage}[t]{0.3
\backslash
columnwidth}%
\end_layout
\begin_layout Plain Layout
\backslash
raggedleft{%
\end_layout
\begin_layout Plain Layout
left
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
right
\end_layout
\begin_layout Plain Layout
\end_layout
\begin_layout Plain Layout
center
\end_layout
\begin_layout Plain Layout
}
\end_layout
\begin_layout Plain Layout
\backslash
end{minipage}}%
\end_layout
\end_inset
\end_layout
\begin_layout Standard
Now we mix both things: The WHOLE box is right-aligned while the first paragraph
is left aligned.
\end_layout
\begin_layout Standard
\begin_inset ERT
status open
\begin_layout Plain Layout
\backslash
fbox{
\backslash
begin{minipage}[t]{0.3
\backslash
columnwidth}%
\end_layout
\begin_layout Plain Layout
\
using std_regex on Windows leads to 135 compilation errors
As suggested in http://www.lyx.org/trac/ticket/9373 I tried to compile LyX on Windows with std_regex. When doing this, i get these error messages (and many more): --- "D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj" (Standardziel) (23) -> support.lib(debug.obj) : error LNK2019: Verweis auf nicht aufgel÷stes externes Symbol ""private: class boost::basic_regexboost::regex_traits > > & __thiscall boost::basic_regexboost::w32_regex_traits > >::do_as sign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_traits@DV?$w32_regex_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z)" in Funktion ""void __cdecl lyx::Debug::showLevel(class std::basic_ostream > &,enum lyx::Debug::Type)" (?showLevel@Debug@lyx@@YA XAAV?$basic_ostream@DU?$char_traits@D@std@@@std@@W4Type@12@@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] Preamble.obj : error LNK2001: Nicht aufgel÷stes externes Symbol ""private: class boost::basic_regexboost::regex_traits > > & __thiscall boost::basic_regexboost::w32_regex_traits > >::do_assign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_traits@DV?$w32_rege x_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] ExternalTransforms.obj : error LNK2001: Nicht aufgel÷stes externes Symbol ""private: class boost::basic_regexboost::regex_traits > > & __thiscall boost::basic_regext::regex_traits > >::do_assign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_traits@DV ?$w32_regex_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] LayoutFile.obj : error LNK2001: Nicht aufgel÷stes externes Symbol ""private:class boost::basic_regexboost::regex_traits > > & __thiscall boost::basic_regex_traits > >::do_assign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_traits@DV?$w32_re gex_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] support.lib(filetools.obj) : error LNK2001: Nicht aufgel÷stes externes Symbol ""private: class boost::basic_regexboost::regex_traits boost::w32_regex_traits > > & __thiscall boost::basic_regexboost::w32_regex_traits > >::do_assign(char const *,char const *,unsigned int)" (?do_assign@?$basic_regex@DU?$regex_trait s@DV?$w32_regex_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] support.lib(debug.obj) : error LNK2001: Nicht aufgel÷stes externes Symbol ""private: void __thiscall boost::re_detail::perl_matcherstd::_String_const_iterator,class std::allocator >,class std::allocatorboost::sub_matchstd::char_traits,class std::allocator > > >,struct boost::regex_traits > >::construct_init(class boost::basic_regexboost::regex_traits > > const &,enum boost::regex_constants::_match_flags)" (?construct_init@?$perl_matcher@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$alloca tor@D@2@@std@@V?$allocator@U?$sub_match@V?$_String_const_iterator@DU?$char_trai ts@D@std@@V?$allocator@D@2@@std@@@boost@@@2@U?$regex_traits@DV?$w32_regex_trait s@D@boost@@@boost@@@re_detail@boost@@AAEXABV?$basic_regex@DU?$regex_traits@DV?$ w32_regex_traits@D@boost@@@boost@@@3@W4_match_flags@regex_constants@3@@Z)". [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] Preamble.obj : error LNK2019: Verweis auf nicht aufgel÷stes externes Symbol ""private: void __thiscall boost::re_detail::perl_matcherstd::_String_const_iterator,class std::allocator >,class std::allocatorboost::sub_matchstd::char_traits,class std::allocator > > >,struct boost::regex_traits > >::construct_init(class boost::basic_regexboost::regex_traits_traits > > const &,enum boost::regex_constants::_match_flags)" (?construct_init@?$perl_matcher@V?$_String_const_iterator@DU?$char_traits@D@std@@V?$allo cator@D@2@@std@@V?$allocator@U?$sub_match@V?$_String_const_iterator@DU?$char_tr aits@D@std@@V?$allocator@D@2@@std@@@boost@@@2@U?$regex_traits@DV?$w32_regex_tra its@D@boost@@@boost@@@re_detail@boost@@AAEXABV?$basic_regex@DU?$regex_traits@DV ?$w32_regex_traits@D@boost@@@boost@@@3@W4_match_flags@regex_constants@3@@Z)" in Funktion ""public: __thiscall boost::re_detail::perl_matcherstd::_String_const_iterator,class std::allocator>,class std::allocatorstd::_String_const_iterator,class std::allocator > > >,struct boost::regex_traitsboost::w32_regex_traits > >::perl_matcherstd::_String_const_iterator,class std::a llocator >,class std::allocatorstd::_String_const_iterator,class std::allocator> > >,struct boost::regex_traitsboost::w32_regex_traits > >(class std::_String_const_iterator,class std::allocator >,class std::_String_const_iteratorstd::char_traits,class std::allocator >,class boost::match_resultsstd::char_traits,class std::allocator >,class std::allocatorstd::_String_const_iter
Re: Why don't we use layout2layout to update local layout?
Am 29.11.2015 um 12:20 schrieb Georg Baum: Well, this has a drawback: If we do this, then all files using local layouts are not longer exportable to version 2.1. Oh, that is a big problem in my opinion. I mean we promise backwards compatibility but also provide in the document settings the button to convert the LocalLayout to the latest format. But if the user uses this button, his files are currently not reversable, right? To overcome this, layout2layout must be run for LocalLayouts when the user reverses a document to an older LyX version. I would even go so far that we should fix this before the beta release if possible. regards Uwe
Re: [LyX/master] UserGuide.lyx and Math.lyx: update version number
Am 29.11.2015 um 13:01 schrieb Georg Baum: These changes are done by LyX, not lyx2lyx. LyX does this when it opens a file that has been converted by lyx2lyx to version 482 or later before, but was never saved by LyX after that conversion. The reason is that lyx2lx does not have the needed knowledge to do the complete conversion 481->482, so it outputs "\SpecialCharNoPassThru LyX", and LyX changes this either to "\SpecialChar LyX" or "LyX", depending on the context. Thanks for this info. I was wondering about this for a while. I think that we should nevertheless save all files with the current LyX alpha2 because people might wonder why official LyX files are changed while they are e.g. only Save As somewhere. regards Uwe
Re: Fwd: LyX 2.2 alpha1
Le 29/11/2015 21:24, Uwe Stöhr a écrit : In this case I compiled it correctly but put the files from the git master lib folder to the installer instead of the files from the tarball. The lyx.exe and tex2lyx.exe in the installer are the correct ones (see the date when LyX is started). So there is no need to release a new installer. If they do not show the right git commit hash, I would not be sure that they are the right ones. JMarc
Re: Fwd: LyX 2.2 alpha1
Am 29.11.2015 um 05:22 schrieb Richard Heck: Besides this it seems that I built the lyx.exe including this patch. This was not the plan and I hate git for this. It is hard to figure out what branch is now really used. I took Scott's file into my build branch but it seems I compiled git master nevertheless. Are the Windows binaries being built from some git branch and not from the tarball? Or am I misunderstanding something? I build from the tarball. To do so i create a new branch in my git to get all paths correct. In this case I compiled it correctly but put the files from the git master lib folder to the installer instead of the files from the tarball. The lyx.exe and tex2lyx.exe in the installer are the correct ones (see the date when LyX is started). So there is no need to release a new installer. regards Uwe
Re: Tentative schedule for 2.2.0 release
Le 29/11/2015 16:39, Richard Heck a écrit : I'd suggest beta in two weeks if we don't run into any serious problems, then see how that goes. If well, then we can shoot for RC in mid-January. This looks good to me. JMarc
Re: [LyX/master] Convert to 2.2 format and use TeX fonts
Kornel Benko wrote: > Am Sonntag, 29. November 2015 um 13:18:39, schrieb Georg Baum > >> >> Convert to 2.2 format and use TeX fonts >> >> This works around a limitation of the test machinery, which never >> switches TeX fonts on for format that need that, it only switches TeX >> fonts off for formats needing it. > > Which never was allowed to convert. Now it does on each export to pdf* or > dvi*. Thanks! Georg
Re: [LyX/master] Convert to 2.2 format and use TeX fonts
Am Sonntag, 29. November 2015 um 13:18:39, schrieb Georg Baum > commit 63bb24d385980911815f3d840f46eb34180b68fb > Author: Georg Baum > Date: Sun Nov 29 13:16:46 2015 +0100 > > Convert to 2.2 format and use TeX fonts > > This works around a limitation of the test machinery, which never switches > TeX fonts on for format that need that, it only switches TeX fonts off for > formats needing it. Which never was allowed to convert. Now it does on each export to pdf* or dvi*. Kornel signature.asc Description: This is a digitally signed message part.
Re: [patch] improve error output
Abdelrazak Younes wrote:
I Abdel,
I'll do what you suggested, with one exception:
> LYXERR0("FileName::copyTo(): Could not copy file " << *this << " to " <<
> name); sting const error = fromqstr(f.errorString());
> if (!error.empty())
> LYXERR0(": " << error);
This would add an unwanted line break.
Georg
Re: merging of po files done? Send email to translators?
Kornel Benko wrote: > Am Sonntag, 29. November 2015 um 18:27:48, schrieb Georg Baum > >> Merging ../lyx-2.1-git/po/sk.po into po/sk.po: Updated 2 translations. > > This must be wrong. Only one translation is not in master "Verbatim*", but > that is sure not in branch too. > > All other are more uptodate than in branch. Thanks, there was indeed a bug. Now it shows 0 updates for sk.po. Georg
Re: Fwd: LyX 2.2 alpha1
Le 29/11/2015 17:17, Richard Heck a écrit : I use ccache to accelerate the recompilation between checkouts, it works well if you have some spare hard disk space. Never heard of that. I'm not sure I want to use it for all compilations, though. I'd like to be able to use it just for LyX. But that looks difficult. In Debian/Ubuntu, you could do something like: export CXX="ccache g++" before running configure, or: export PATH="/usr/lib/ccache/:$PATH" before compilation. (not tested)
Re: merging of po files done? Send email to translators?
Am Sonntag, 29. November 2015 um 18:27:48, schrieb Georg Baum > Merging ../lyx-2.1-git/po/sk.po into po/sk.po: Updated 2 translations. This must be wrong. Only one translation is not in master "Verbatim*", but that is sure not in branch too. All other are more uptodate than in branch. Kornel signature.asc Description: This is a digitally signed message part.
Re: [patch] improve error output
Hi Georg,
Few nitpicks inline.
On 29/11/2015 18:53, Georg Baum wrote:
The investigation of bug 9139 showed that the error message we give when a
file operation fails is not too clever. The attached patch improves this. It
is still not optimal (since qt has a very limited set of error causes that
are reported), but if we want to get the real error from the OS we have to
implement it in a platform specific way.
In my experience error messages that are as exact as possible help a lot
when investigating bug reports: You need to ask less questions, since the
bug report itself will contain more information.
Fully agreed.
OK to go in?
Georg
diff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index 950..3423972 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -238,10 +238,17 @@ bool FileName::copyTo(FileName const & name, bool
keepsymlink,
return copyTo(target, true);
}
QFile::remove(name.d->fi.absoluteFilePath());
- bool success = QFile::copy(d->fi.absoluteFilePath(),
name.d->fi.absoluteFilePath());
- if (!success)
- LYXERR0("FileName::copyTo(): Could not copy file "
- << *this << " to " << name);
+ QFile f(d->fi.absoluteFilePath());
+ bool const success = f.copy(name.d->fi.absoluteFilePath());
if (f.copy(name.d->fi.absoluteFilePath()))
return true;
+ if (!success) {
remove
+ QString const error(f.errorString());
+ if (error.isEmpty())
+ LYXERR0("FileName::copyTo(): Could not copy file "
+ << *this << " to " << name);
+ else
+ LYXERR0("FileName::copyTo(): Could not copy file "
+ << *this << " to " << name << ": " <<
fromqstr(error));
+ }
LYXERR0("FileName::copyTo(): Could not copy file " << *this << " to " << name);
sting const error = fromqstr(f.errorString());
if (!error.empty())
LYXERR0(": " << error);
return success;
return false;
Same comments for renameTo() and moveTo()
Cheers,
Abdel.
PS: congratz to all for LyX 2.2 alpha delivery, looks very promising!
[patch] improve error output
The investigation of bug 9139 showed that the error message we give when a
file operation fails is not too clever. The attached patch improves this. It
is still not optimal (since qt has a very limited set of error causes that
are reported), but if we want to get the real error from the OS we have to
implement it in a platform specific way.
In my experience error messages that are as exact as possible help a lot
when investigating bug reports: You need to ask less questions, since the
bug report itself will contain more information. OK to go in?
Georgdiff --git a/src/support/FileName.cpp b/src/support/FileName.cpp
index 950..3423972 100644
--- a/src/support/FileName.cpp
+++ b/src/support/FileName.cpp
@@ -238,10 +238,17 @@ bool FileName::copyTo(FileName const & name, bool keepsymlink,
return copyTo(target, true);
}
QFile::remove(name.d->fi.absoluteFilePath());
- bool success = QFile::copy(d->fi.absoluteFilePath(), name.d->fi.absoluteFilePath());
- if (!success)
- LYXERR0("FileName::copyTo(): Could not copy file "
- << *this << " to " << name);
+ QFile f(d->fi.absoluteFilePath());
+ bool const success = f.copy(name.d->fi.absoluteFilePath());
+ if (!success) {
+ QString const error(f.errorString());
+ if (error.isEmpty())
+ LYXERR0("FileName::copyTo(): Could not copy file "
+<< *this << " to " << name);
+ else
+ LYXERR0("FileName::copyTo(): Could not copy file "
+<< *this << " to " << name << ": " << fromqstr(error));
+ }
return success;
}
@@ -249,9 +256,16 @@ bool FileName::copyTo(FileName const & name, bool keepsymlink,
bool FileName::renameTo(FileName const & name) const
{
LYXERR(Debug::FILES, "Renaming " << name << " as " << *this);
- bool success = QFile::rename(d->fi.absoluteFilePath(), name.d->fi.absoluteFilePath());
- if (!success)
- LYXERR0("Could not rename file " << *this << " to " << name);
+ QFile f(d->fi.absoluteFilePath());
+ bool const success = f.rename( name.d->fi.absoluteFilePath());
+ if (!success) {
+ QString const error(f.errorString());
+ if (error.isEmpty())
+ LYXERR0("Could not rename file " << *this << " to " << name);
+ else
+ LYXERR0("Could not rename file " << *this << " to "
+<< name << ": " << fromqstr(error));
+ }
return success;
}
@@ -261,10 +275,16 @@ bool FileName::moveTo(FileName const & name) const
LYXERR(Debug::FILES, "Moving " << name << " to " << *this);
QFile::remove(name.d->fi.absoluteFilePath());
- bool success = QFile::rename(d->fi.absoluteFilePath(),
- name.d->fi.absoluteFilePath());
- if (!success)
- LYXERR0("Could not move file " << *this << " to " << name);
+ QFile f(d->fi.absoluteFilePath());
+ bool const success = f.rename(name.d->fi.absoluteFilePath());
+ if (!success) {
+ QString const error(f.errorString());
+ if (error.isEmpty())
+ LYXERR0("Could not move file " << *this << " to " << name);
+ else
+ LYXERR0("Could not move file " << *this << " to "
+<< name << ": " << fromqstr(error));
+ }
return success;
}
Re: merging of po files done? Send email to translators?
Georg Baum wrote: > I can update the script to produce readable diffs (currently there are > many re-formattings which hide the real changes), then we could actually > use it, but last time I asked I got no feedback, so I did not do it so > far. Actually I just did it: $ python -tt development/tools/mergepo.py ../lyx-2.1-git/po Merging ../lyx-2.1-git/po/pt_PT.po into po/pt_PT.po: Updated 6 translations. Merging ../lyx-2.1-git/po/ja.po into po/ja.po: Updated 9 translations. Merging ../lyx-2.1-git/po/sl.po into po/sl.po: Updated 0 translations. Merging ../lyx-2.1-git/po/bg.po into po/bg.po: Updated 0 translations. Merging ../lyx-2.1-git/po/fr.po into po/fr.po: Updated 14 translations. Merging ../lyx-2.1-git/po/id.po into po/id.po: Updated 0 translations. Merging ../lyx-2.1-git/po/fi.po into po/fi.po: Updated 3 translations. Merging ../lyx-2.1-git/po/ar.po into po/ar.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ia.po into po/ia.po: Updated 21 translations. Merging ../lyx-2.1-git/po/cs.po into po/cs.po: Updated 1 translations. Merging ../lyx-2.1-git/po/zh_CN.po into po/zh_CN.po: Updated 0 translations. Merging ../lyx-2.1-git/po/nl.po into po/nl.po: Updated 0 translations. Merging ../lyx-2.1-git/po/el.po into po/el.po: Updated 4 translations. Merging ../lyx-2.1-git/po/de.po into po/de.po: Updated 4 translations. Merging ../lyx-2.1-git/po/en.po into po/en.po: Updated 0 translations. Merging ../lyx-2.1-git/po/pt_BR.po into po/pt_BR.po: Updated 10 translations. Merging ../lyx-2.1-git/po/wa.po into po/wa.po: Updated 0 translations. Merging ../lyx-2.1-git/po/sr.po into po/sr.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ko.po into po/ko.po: Updated 0 translations. Merging ../lyx-2.1-git/po/hu.po into po/hu.po: Updated 1 translations. Merging ../lyx-2.1-git/po/ro.po into po/ro.po: Updated 2 translations. Merging ../lyx-2.1-git/po/tr.po into po/tr.po: Updated 0 translations. Merging ../lyx-2.1-git/po/uk.po into po/uk.po: Updated 10 translations. Merging ../lyx-2.1-git/po/ru.po into po/ru.po: Updated 6 translations. Merging ../lyx-2.1-git/po/he.po into po/he.po: Updated 110 translations. Merging ../lyx-2.1-git/po/sk.po into po/sk.po: Updated 2 translations. Merging ../lyx-2.1-git/po/da.po into po/da.po: Updated 3 translations. Merging ../lyx-2.1-git/po/nb.po into po/nb.po: Updated 114 translations. Merging ../lyx-2.1-git/po/es.po into po/es.po: Updated 8 translations. Merging ../lyx-2.1-git/po/pl.po into po/pl.po: Updated 222 translations. Merging ../lyx-2.1-git/po/eu.po into po/eu.po: Updated 6 translations. Merging ../lyx-2.1-git/po/gl.po into po/gl.po: Updated 4 translations. Merging ../lyx-2.1-git/po/ca.po into po/ca.po: Updated 2 translations. Merging ../lyx-2.1-git/po/sv.po into po/sv.po: Updated 47 translations. Merging ../lyx-2.1-git/po/nn.po into po/nn.po: Updated 0 translations. Merging ../lyx-2.1-git/po/it.po into po/it.po: Updated 3 translations. Merging ../lyx-2.1-git/po/zh_TW.po into po/zh_TW.po: Updated 0 translations. The diffs are readable now, and you can also update only one language, by giving an additional argument: python -tt development/tools/mergepo.py ../lyx-2.1-git/po fr The numbers above do also include outdated messages, so the actual situation is better, but I included the outdated ones since it does not make sense to have an outdated message without translation: If it is not translated, it cannot be re-used if the message appears again, and it cannot be used as source for fuzzy translations. Georg
Re: Fwd: LyX 2.2 alpha1
On 11/29/2015 11:52 AM, Guillaume Munch wrote:
> Le 29/11/2015 16:20, Richard Heck a écrit :
>> On 11/29/2015 06:51 AM, Georg Baum wrote:
>>> Richard Heck wrote:
>>>
On 11/28/2015 10:17 PM, Uwe Stöhr wrote:
> Besides this it seems that I built the lyx.exe including this patch.
> This was not the plan and I hate git for this. It is hard to figure
> out what branch is now really used. I took Scott's file into my build
> branch but it seems I compiled git master nevertheless.
>>> If you do not pay attention to what the git advocates say ("it is
>>> easy to
>>> switch branches, therefore you should use only one working directory
>>> for
>>> several branches"), and use one separate working directory for
>>> master and
>>> one for stable, then it is easy not to get confused.
>>
>> I do this anyway---one tree for master, one tree for stable---for the
>> simple reason that it saves a lot of compilation time.
>>
>
> I use ccache to accelerate the recompilation between checkouts, it
> works well if you have some spare hard disk space.
Never heard of that. I'm not sure I want to use it for all compilations,
though. I'd like to be able to use it just for LyX. But that looks
difficult.
Richard
Re: [LyX/master] Customization.lyx: update localLayout format
On 11/29/2015 11:26 AM, Kornel Benko wrote: > Am Sonntag, 29. November 2015 um 17:15:19, schrieb Uwe Stöhr > >> commit 7499b14b50bf528547c5585cbb0f7e2de11b8a8a >> > Author: Uwe Stöhr >> Date: Sun Nov 29 17:15:15 2015 +0100 >> >> Customization.lyx: update localLayout format >> >> - Japanese version: also run lyx2lyx >> >> diff --git a/lib/doc/de/Customization.lyx b/lib/doc/de/Customization.lyx > > So, manuals are starting to not be exportable to lyx 2.1 format. Very funny. > I vote for revert, or setting the format to maximal 49. We thought we had consensus on this, but now the vote is turning the other way I'm inclined now to think that you and Georg are right, though I was the one who started this. Richard
Re: Fwd: LyX 2.2 alpha1
Le 29/11/2015 16:20, Richard Heck a écrit :
On 11/29/2015 06:51 AM, Georg Baum wrote:
Richard Heck wrote:
On 11/28/2015 10:17 PM, Uwe Stöhr wrote:
Besides this it seems that I built the lyx.exe including this patch.
This was not the plan and I hate git for this. It is hard to figure
out what branch is now really used. I took Scott's file into my build
branch but it seems I compiled git master nevertheless.
If you do not pay attention to what the git advocates say ("it is easy to
switch branches, therefore you should use only one working directory for
several branches"), and use one separate working directory for master and
one for stable, then it is easy not to get confused.
I do this anyway---one tree for master, one tree for stable---for the
simple reason that it saves a lot of compilation time.
I use ccache to accelerate the recompilation between checkouts, it works
well if you have some spare hard disk space.
Re: [PATCH] Fix #9507 now or after 2.2?
Le 29/11/2015 03:41, Uwe Stöhr a écrit : Am 29.11.2015 um 00:52 schrieb Richard Heck: Does anyone really want #9507 fixed for 2.2.0 or can I retarget to 2.2.1? There do seem to be people who want it fixed, including Uwe, who is one of our most reliable testers, due to his work on the documentation. My suggestion would be that such people apply this patch locally and use it for a while. The patch does what it should but I cannot state about its side effects in terms of speed. Since Guillaume found the speed issue he should test the patch and decide if it can go in or if it should be postponed. I have this test on my to-do list. Guillaume
Re: [LyX/master] Customization.lyx: update localLayout format
Am Sonntag, 29. November 2015 um 17:15:19, schrieb Uwe Stöhr > commit 7499b14b50bf528547c5585cbb0f7e2de11b8a8a > Author: Uwe Stöhr > Date: Sun Nov 29 17:15:15 2015 +0100 > > Customization.lyx: update localLayout format > > - Japanese version: also run lyx2lyx > > diff --git a/lib/doc/de/Customization.lyx b/lib/doc/de/Customization.lyx So, manuals are starting to not be exportable to lyx 2.1 format. Very funny. I vote for revert, or setting the format to maximal 49. Kornel signature.asc Description: This is a digitally signed message part.
Re: Fwd: LyX 2.2 alpha1
On 11/29/2015 06:51 AM, Georg Baum wrote:
> Richard Heck wrote:
>
>> On 11/28/2015 10:17 PM, Uwe Stöhr wrote:
>>
>>> Besides this it seems that I built the lyx.exe including this patch.
>>> This was not the plan and I hate git for this. It is hard to figure
>>> out what branch is now really used. I took Scott's file into my build
>>> branch but it seems I compiled git master nevertheless.
> If you do not pay attention to what the git advocates say ("it is easy to
> switch branches, therefore you should use only one working directory for
> several branches"), and use one separate working directory for master and
> one for stable, then it is easy not to get confused.
I do this anyway---one tree for master, one tree for stable---for the
simple reason that it saves a lot of compilation time.
> If you don't know how to do that, ask, and you'll get help.
>
>> Are the Windows binaries being built from some git branch and not from
>> the tarball? Or am I misunderstanding something?
> I hope not. We discussed very deeply for the 2.1 release that an installer
> that is labelled "2.2.0 alpha2" has to be built from the source tar ball
> "2.2.0 alpha2", and not from a git checkout. This is true BTW for all
> packagers on all operating systems.
Other messages in this thread have made it seem likely that the Windows
alpha2 release was built from git commit hash 5c35ebcd, about six
commits after alpha2. Uwe said something about trying to import the
tarball into the git tree and getting confused:
> Besides this it seems that I built the lyx.exe including [Richard's]
> patch. This was not the plan and I hate git for this. It is hard to
> figure out what branch is now really used. I took Scott's file into my
> build branch but it seems I compiled git master nevertheless.
but I didn't understand what he meant. Obviously, there's something here
that we need to help Uwe figure out.
Richard
Re: Why don't we use layout2layout to update local layout?
On 11/28/2015 11:41 PM, Scott Kostyshak wrote: > On Sat, Nov 28, 2015 at 11:18:50PM -0500, Richard Heck wrote: >>> Today I > found out that the LocalLayout in Additional.lyx was still in >>> the very old format 7. I stumbled over this because in the Spanish >>> version all insets using the LocalLayout code were broken. >> >> We should presumably make a point of converting this stuff before a >> release. I've just done it for 2.2, at least for the English manuals. > > Did you do it manually? Just to confirm, there is no automatic way to do > it, right? No, but it now looks as if the other reasons I was giving not to do it---loss of exportability to 2.1.x---might be reasons not to do it routinely. Richard
Re: Why don't we use layout2layout to update local layout?
On 11/29/2015 09:35 AM, Kornel Benko wrote: > Am Sonntag, 29. November 2015 um 12:20:27, schrieb Georg Baum > >> Richard Heck wrote: >>> We should presumably make a point of converting this stuff before a >>> release. I've just done it for 2.2, at least for the English manuals. >> Well, this has a drawback: If we do this, then all files using local layouts >> are not longer exportable to version 2.1. This is a pity, since only the >> layout syntax changed, no new features are used. I would say we should keep >> at least the 2.1 format, unless a layout needs later features. > +1 Shall I convert it back? Richard
Re: Fwd: LyX 2.2 alpha1
On 11/29/2015 02:45 AM, Andrew Parsloe wrote: > > > On 29/11/2015 5:38 p.m., Scott Kostyshak wrote: >> On Sun, Nov 29, 2015 at 04:17:01AM +0100, Uwe Stöhr wrote: >>> Am 29.11.2015 um 03:00 schrieb Andrew Parsloe: >>> Your alpha2 installer appeared *very* promptly. Did it incorporate the late commit from Richard about updating bind and ui formats? >>> You mean this one?: >>> >>> www.lyx.org/trac/changeset/1bf01a8ad307729fa486563d600ba9d8c2320368/lyxgit >>> >>> >>> This would not explain your problems because we have the script that >>> should >>> convert to the right format. You copied a file in Format 1 into LyX's >>> directory and the question is if LyX is supposed to be able to read it >>> anyway or to convert it automatically. I don't know. So perhaps just >>> file a >>> bug report. >>> >>> Besides this it seems that I built the lyx.exe including this patch. >> Note that we should be able to tell just from the binary. What does >> Help > About say after "Built from git commit hash" ? >> >> Scott > > Built from git commit hash 5c35ebcd. That is several commits after alpha2 and would have included my patch, as well as a couple due to Georg. What I don't understand is why the binary isn't being built from the tarball. Is the reason that the installer code is itself in the git tree but not part of the tarball? Surely there's a way around that. But even if there is some need to build the binary from within the git tree, then the thing to do is checkout the relevant tag: # git checkout 2.2.0alpha2 Then build. Richard
Re: Tentative schedule for 2.2.0 release
On 11/29/2015 01:26 AM, Scott Kostyshak wrote: > On Sat, Nov 28, 2015 at 09:13:46PM -0500, Scott Kostyshak wrote: >> On Wed, Nov 11, 2015 at 07:49:24PM +0100, Jean-Marc Lasgouttes wrote: >>> >>> Le 11 novembre 2015 19:10:05 GMT+01:00, Scott Kostyshak >>> a écrit : What stage(s) would you propose making shorter? >>> All of them ? :) >>> >>> Seriously, we'll see what happens. We should go as fast as possible but not >>> more. >> Does anyone have updated thoughts on the rest of the release schedule? >> >> Hopefully another alpha release will not be needed. If that is the case >> how about the following schedule? >> >> beta: end of December >> RC: beginning of February >> final: end of February > An alternative would be to do a beta soon and the RC in January. > This would have the disadvantage of not getting much feedback from > alpha2 testers, but would have the advantage of shortening the final > release a bit and lengthening the beta testing period a bit (which is > nice because we will probably get more testers for beta). I'd suggest beta in two weeks if we don't run into any serious problems, then see how that goes. If well, then we can shoot for RC in mid-January. Richard
Re: LyX 2.2 alpha1
Am 29.11.2015 um 12:51 schrieb Georg Baum :
> Richard Heck wrote:
>
>> On 11/28/2015 10:17 PM, Uwe Stöhr wrote:
>>
>>> Besides this it seems that I built the lyx.exe including this patch.
>>> This was not the plan and I hate git for this. It is hard to figure
>>> out what branch is now really used. I took Scott's file into my build
>>> branch but it seems I compiled git master nevertheless.
>
> If you do not pay attention to what the git advocates say ("it is easy to
> switch branches, therefore you should use only one working directory for
> several branches"), and use one separate working directory for master and
> one for stable, then it is easy not to get confused. If you don't know how
> to do that, ask, and you'll get help.
>
>> Are the Windows binaries being built from some git branch and not from
>> the tarball? Or am I misunderstanding something?
>
> I hope not. We discussed very deeply for the 2.1 release that an installer
> that is labelled "2.2.0 alpha2" has to be built from the source tar ball
> "2.2.0 alpha2", and not from a git checkout. This is true BTW for all
> packagers on all operating systems.
Yes, I agree and I'm aware of it. On Mac this is the case.
Stephan
Re: [LyX/master] Add test for language nesting regression
Am Sonntag, 29. November 2015 um 16:01:38, schrieb Kornel Benko > Am Sonntag, 29. November 2015 um 15:56:58, schrieb Kornel Benko > > > > Nevertheless it would be nice if the test machinery could be updated to > > > support the other direction as well, I guess we will have test in the > > > future > > > that need this. > > > > > > > Will do. I never expected this case. > > Hm, inspecting the code, we do it already. > > Seems, I have more to investigate ... > This one was easy. The scripts would have converted if called. But for this output formats they was net enabled. Commit af18890 Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add test for language nesting regression
Am Sonntag, 29. November 2015 um 15:56:58, schrieb Kornel Benko > > Nevertheless it would be nice if the test machinery could be updated to > > support the other direction as well, I guess we will have test in the > > future > > that need this. > > > > Will do. I never expected this case. Hm, inspecting the code, we do it already. Seems, I have more to investigate ... Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add test for language nesting regression
Am Sonntag, 29. November 2015 um 13:10:56, schrieb Georg Baum > Georg Baum wrote: > > > commit 2f3f82e75be5e862e1628af46212a9b26fd2da52 > > Author: Georg Baum > > Date: Sun Nov 29 11:52:34 2015 +0100 > > > > Add test for language nesting regression > > > > The new test shows a language nesting regression: With LyX 2.1 it > > exports fine in all formats, with 2.2 it fails for dvi, pdf2 and pdf3. > > Actually this is wrong: It is a limitation in the test machinery. It does > only convert from \use_non_tex_fonts false to \use_non_tex_fonts true, and > never the other way round. As a workaround, I'll convert the file now to 2.2 > format and set \use_non_tex_fonts false, since I verified manually that > exporting with 2.2 works for all formats. > > Nevertheless it would be nice if the test machinery could be updated to > support the other direction as well, I guess we will have test in the future > that need this. > Will do. I never expected this case. > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: Why don't we use layout2layout to update local layout?
Am Sonntag, 29. November 2015 um 12:20:27, schrieb Georg Baum > Richard Heck wrote: > > > We should presumably make a point of converting this stuff before a > > release. I've just done it for 2.2, at least for the English manuals. > > Well, this has a drawback: If we do this, then all files using local layouts > are not longer exportable to version 2.1. This is a pity, since only the > layout syntax changed, no new features are used. I would say we should keep > at least the 2.1 format, unless a layout needs later features. +1 > What do we > gain by having all layouts in current format? > > Georg > Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add the first dedicated export test
Am Sonntag, 29. November 2015 um 13:19:18, schrieb Guenter Milde > On 2015-11-29, Georg Baum wrote: > > Scott Kostyshak wrote: > > >> On Sat, Nov 28, 2015 at 08:00:06PM +0100, Georg Baum wrote: > > >>> BTW, lyx2lyx/export/languagenesting1 fails, because the file is already > >>> in target format. This should nto cause a test failure IMHO. > > >> I have not checked but I think this is because of 4c16c615. I believe > >> the lyx2lyx tests check that lyx2lyx gives no warnings or errors. > > > I think so as well. The actual conversion succeeds (because of 221932f), but > > a warning is printed, and this probably causes ctest to mark the test as > > failed. Do we really need that warning? I'd suggest to simply remove it, if > > lyx2lyx is asked to convert a file to the format it already has, then it can > > simply do nothing and the desired result is achieved. > > Ctest can be told to pass for given output, > so we could teach it to accept > the warning... What else should ctest ignore? And it is (in this case) interpreted by our script. ctest is not to blame here. (I am) Adapted at 2b9a9d9 > Günter Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Add the first dedicated export test
On 2015-11-29, Georg Baum wrote: > Scott Kostyshak wrote: >> On Sat, Nov 28, 2015 at 08:00:06PM +0100, Georg Baum wrote: >>> BTW, lyx2lyx/export/languagenesting1 fails, because the file is already >>> in target format. This should nto cause a test failure IMHO. >> I have not checked but I think this is because of 4c16c615. I believe >> the lyx2lyx tests check that lyx2lyx gives no warnings or errors. > I think so as well. The actual conversion succeeds (because of 221932f), but > a warning is printed, and this probably causes ctest to mark the test as > failed. Do we really need that warning? I'd suggest to simply remove it, if > lyx2lyx is asked to convert a file to the format it already has, then it can > simply do nothing and the desired result is achieved. Ctest can be told to pass for given output, so we could teach it to accept the warning... Günter
Re: [LyX/master] Add test for language nesting regression
On 2015-11-29, Georg Baum wrote: >> commit 2f3f82e75be5e862e1628af46212a9b26fd2da52 >> Author: Georg Baum >> Date: Sun Nov 29 11:52:34 2015 +0100 >> Add test for language nesting regression >> The new test shows a language nesting regression: With LyX 2.1 it >> exports fine in all formats, with 2.2 it fails for dvi, pdf2 and pdf3. > Actually this is wrong: It is a limitation in the test machinery. It does > only convert from \use_non_tex_fonts false to \use_non_tex_fonts true, and > never the other way round. As a workaround, I'll convert the file now to 2.2 > format and set \use_non_tex_fonts false, since I verified manually that > exporting with 2.2 works for all formats. > Nevertheless it would be nice if the test machinery could be updated to > support the other direction as well, I guess we will have test in the future > that need this. We could also use one of the following conventions, * special export test documents (the ones in autotests/export) only use the default export format and do not change the use_non_tex_fonts setting. +1 no need to ignore/invert tests -1 you need separate test sample documents for different exports. * don't export documents with \use_non_tex_fonts true with 8-bit TeX +1 no need to ignore/invert tests if the document is intended for Unicode fonts. +1 one document for all exports possible with \use_non_tex_fonts false -1 the test machinery needs to check the setting. Günter
Re: merging of po files done? Send email to translators?
Scott Kostyshak wrote: > Is the merging complete? If so, should I send an email to the > translators? Does the timing of this email depend on the timing of our > scheduled beta release? It is not complete: $ python -tt development/tools/mergepo.py ../lyx-2.1-git/po Merging ../lyx-2.1-git/po/pt_PT.po into po/pt_PT.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ja.po into po/ja.po: Updated 8 translations. Merging ../lyx-2.1-git/po/sl.po into po/sl.po: Updated 0 translations. Merging ../lyx-2.1-git/po/bg.po into po/bg.po: Updated 0 translations. Merging ../lyx-2.1-git/po/fr.po into po/fr.po: Updated 5 translations. Merging ../lyx-2.1-git/po/id.po into po/id.po: Updated 0 translations. Merging ../lyx-2.1-git/po/fi.po into po/fi.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ar.po into po/ar.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ia.po into po/ia.po: Updated 17 translations. Merging ../lyx-2.1-git/po/cs.po into po/cs.po: Updated 0 translations. Merging ../lyx-2.1-git/po/zh_CN.po into po/zh_CN.po: Updated 0 translations. Merging ../lyx-2.1-git/po/nl.po into po/nl.po: Updated 0 translations. Merging ../lyx-2.1-git/po/el.po into po/el.po: Updated 0 translations. Merging ../lyx-2.1-git/po/de.po into po/de.po: Updated 0 translations. Merging ../lyx-2.1-git/po/en.po into po/en.po: Updated 0 translations. Merging ../lyx-2.1-git/po/pt_BR.po into po/pt_BR.po: Updated 5 translations. Merging ../lyx-2.1-git/po/wa.po into po/wa.po: Updated 0 translations. Merging ../lyx-2.1-git/po/sr.po into po/sr.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ko.po into po/ko.po: Updated 0 translations. Merging ../lyx-2.1-git/po/hu.po into po/hu.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ro.po into po/ro.po: Updated 0 translations. Merging ../lyx-2.1-git/po/tr.po into po/tr.po: Updated 0 translations. Merging ../lyx-2.1-git/po/uk.po into po/uk.po: Updated 3 translations. Merging ../lyx-2.1-git/po/ru.po into po/ru.po: Updated 0 translations. Merging ../lyx-2.1-git/po/he.po into po/he.po: Updated 115 translations. Merging ../lyx-2.1-git/po/sk.po into po/sk.po: Updated 0 translations. Merging ../lyx-2.1-git/po/da.po into po/da.po: Updated 0 translations. Merging ../lyx-2.1-git/po/nb.po into po/nb.po: Updated 116 translations. Merging ../lyx-2.1-git/po/es.po into po/es.po: Updated 3 translations. Merging ../lyx-2.1-git/po/pl.po into po/pl.po: Updated 247 translations. Merging ../lyx-2.1-git/po/eu.po into po/eu.po: Updated 0 translations. Merging ../lyx-2.1-git/po/gl.po into po/gl.po: Updated 0 translations. Merging ../lyx-2.1-git/po/ca.po into po/ca.po: Updated 0 translations. Merging ../lyx-2.1-git/po/sv.po into po/sv.po: Updated 45 translations. Merging ../lyx-2.1-git/po/nn.po into po/nn.po: Updated 0 translations. Merging ../lyx-2.1-git/po/it.po into po/it.po: Updated 0 translations. Merging ../lyx-2.1-git/po/zh_TW.po into po/zh_TW.po: Updated 0 translations. These are only the translations that exist in 2.1, but do not exist in 2.2. Note that messages that do not exist in 2.2 anymore are not included. There might also be translations which are updated in 2.1, but outdated in 2.2. I can update the script to produce readable diffs (currently there are many re-formattings which hide the real changes), then we could actually use it, but last time I asked I got no feedback, so I did not do it so far. Georg
Re: [LyX/master] Add test for language nesting regression
Georg Baum wrote: > commit 2f3f82e75be5e862e1628af46212a9b26fd2da52 > Author: Georg Baum > Date: Sun Nov 29 11:52:34 2015 +0100 > > Add test for language nesting regression > > The new test shows a language nesting regression: With LyX 2.1 it > exports fine in all formats, with 2.2 it fails for dvi, pdf2 and pdf3. Actually this is wrong: It is a limitation in the test machinery. It does only convert from \use_non_tex_fonts false to \use_non_tex_fonts true, and never the other way round. As a workaround, I'll convert the file now to 2.2 format and set \use_non_tex_fonts false, since I verified manually that exporting with 2.2 works for all formats. Nevertheless it would be nice if the test machinery could be updated to support the other direction as well, I guess we will have test in the future that need this. Georg
Re: [LyX/master] UserGuide.lyx and Math.lyx: update version number
Uwe Stöhr wrote: > Am 28.11.2015 um 06:06 schrieb Scott Kostyshak: > >>> The reason is that Scott did only change yesterday the file format >>> number but did not run lyx2lyx. However, it only happens once here. I hope that nobody ever does this for official documents. >> I don't understand. Why do you think I did not run lyx2lyx? > > I assume this because otherwise in > > http://www.lyx.org/trac/changeset/b264176041696489d577ecf7df9bfcf109d31922/lyxgit#file2 > > there should not be these changes in the Spanish version: > > - correo de Documentación de \SpecialCharNoPassThru LyX > + correo de Documentación de \SpecialChar LyX > > This change is done by lyx2lyx but it seems that lyx2lyx was not run on > all files or that there is a mistake in the script you run. These changes are done by LyX, not lyx2lyx. LyX does this when it opens a file that has been converted by lyx2lyx to version 482 or later before, but was never saved by LyX after that conversion. The reason is that lyx2lx does not have the needed knowledge to do the complete conversion 481->482, so it outputs "\SpecialCharNoPassThru LyX", and LyX changes this either to "\SpecialChar LyX" or "LyX", depending on the context. Georg
Re: Fwd: LyX 2.2 alpha1
Richard Heck wrote:
> On 11/28/2015 10:17 PM, Uwe Stöhr wrote:
>
>> Besides this it seems that I built the lyx.exe including this patch.
>> This was not the plan and I hate git for this. It is hard to figure
>> out what branch is now really used. I took Scott's file into my build
>> branch but it seems I compiled git master nevertheless.
If you do not pay attention to what the git advocates say ("it is easy to
switch branches, therefore you should use only one working directory for
several branches"), and use one separate working directory for master and
one for stable, then it is easy not to get confused. If you don't know how
to do that, ask, and you'll get help.
> Are the Windows binaries being built from some git branch and not from
> the tarball? Or am I misunderstanding something?
I hope not. We discussed very deeply for the 2.1 release that an installer
that is labelled "2.2.0 alpha2" has to be built from the source tar ball
"2.2.0 alpha2", and not from a git checkout. This is true BTW for all
packagers on all operating systems.
Georg
Re: merging of po files done? Send email to translators?
Scott Kostyshak wrote: > Uwe has taken care of the merging of the po files (36d7b40c) from branch > to master. Thank you for doing this, Uwe. This is an area I know nothing > about and was worried I would mess something up when doing the merge. > > Is the merging complete? If so, should I send an email to the > translators? Does the timing of this email depend on the timing of our > scheduled beta release? I wanted to check with my automatic merge script, but it refuses to load the files. The reason is that they have mixed line endings now: Some lines use windows line endings (CRLF), others use unix line endings (LF). The reason for this is probably a bug in the windows version of poedit we can not do much about. I'd like to force native line endings for all .po files in git. This means that a checkout on a windows machine will produce files with CRLF, and a checkout on a linux machine will produce files with LF (this is already the case for .cpp and .h files with git default settings). This can be done by adding the attached file to the top level directory, and then fix all currently broken line endings as described in https://help.github.com/articles/dealing-with-line-endings/. After that we never will have mixed line endings anymore. OK to proceed? Georg# Set the default behavior, in case people don't have core.autocrlf set. * text=auto # Explicitly declare text files you want to always be normalized and converted # to native line endings on checkout. *.po text
Re: Why don't we use layout2layout to update local layout?
Richard Heck wrote: > We should presumably make a point of converting this stuff before a > release. I've just done it for 2.2, at least for the English manuals. Well, this has a drawback: If we do this, then all files using local layouts are not longer exportable to version 2.1. This is a pity, since only the layout syntax changed, no new features are used. I would say we should keep at least the 2.1 format, unless a layout needs later features. What do we gain by having all layouts in current format? Georg
Re: [LyX/master] Add the first dedicated export test
Scott Kostyshak wrote: > On Sat, Nov 28, 2015 at 08:00:06PM +0100, Georg Baum wrote: > >> BTW, lyx2lyx/export/languagenesting1 fails, because the file is already >> in target format. This should nto cause a test failure IMHO. > > I have not checked but I think this is because of 4c16c615. I believe > the lyx2lyx tests check that lyx2lyx gives no warnings or errors. I think so as well. The actual conversion succeeds (because of 221932f), but a warning is printed, and this probably causes ctest to mark the test as failed. Do we really need that warning? I'd suggest to simply remove it, if lyx2lyx is asked to convert a file to the format it already has, then it can simply do nothing and the desired result is achieved. Georg
#9711: crash when "Close All" because closing_ is false
I have investigated #9711 and am hoping that a fix is not too far away. Can someone familiar with our closing_ GuiView member take a look at what it should be in the context for this bug? Scott signature.asc Description: PGP signature
#9806: Are the icons in our manuals too small now?
Regarding #9806, LyX 2.2 produces smaller icons. Uwe is concerned that the smaller icons are not readable. This concerns our manuals when exported to PDF. Anyone who is interested can take a look at the before/after PDFs that Uwe has posted (and I can reproduce) here: http://www.lyx.org/trac/ticket/9806#comment:4 Are the small icons too small? Scott signature.asc Description: PGP signature
Re: Fwd: LyX 2.2 alpha1
On 28/11/2015 11:25 p.m., Georg Baum wrote: Andrew Parsloe wrote: I tried installing alpha2 over my alpha1 installation. It installed but LyX would not launch (stopped at about 6800 KB in Task Manager and just sat there). After a certain amount of tinkering (uninstalling, renaming my user LyX2.2 folder etc.) I found the problem was the personalised version of stdtoolbars.inc that I had in my user LyX2.2/ui directory (I needed to change Format 1 to Format 3). It might be better to advise uninstalling alpha1 *and* preferences (or renaming the alpha1 LyX2.2 folder) so that LyX will launch after installation. If your file was really written in format 1, then this is a bug which should be fixed. Please report it in trac and add the file. We introduced format numbers in preferences files to support exactly this use case: Reusing old user preferences with a newer version. Georg Ticket #9878. Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
