Re: Should we release 2.2.0 with Qt 5.5.1?
Am 06.12.2015 um 21:58 schrieb Kornel Benko : > Am Sonntag, 6. Dezember 2015 um 21:45:23, schrieb Stephan Witt > >> Am 06.12.2015 um 21:00 schrieb Scott Kostyshak : >> >>> On Sun, Dec 06, 2015 at 12:13:04PM +0100, Kornel Benko wrote: Am Sonntag, 6. Dezember 2015 um 05:12:30, schrieb Uwe Stöhr > Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > >> We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a >> couple of things have changed since that conversation began that make me >> think we should release with 5.5.1: >> >> 1. 5.5.1 has been released. > > Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > 2013 (32bit). > >> 2. 5.6.0beta1 has been delayed five times so far [2]. Supposedly, it >> will be released "as soon as possible" [3] but even if it is released >> soon, we cannot be sure the final 5.6 will be released by the time we >> want to release 2.2.0. > > I don't see a bug in Qt 5.5.1 that hinders us from using it for a final > release. I cannot reproduce bug #9731 with Qt 5.5.1. > > regards Uwe What about http://www.lyx.org/trac/ticket/9683 On Ubuntu-linux I see it with QT 5.5, but not with QT 5.4 >>> >>> From what I understand [1], Uwe can reproduce #9227 but not #9683. It >>> would be interesting to know if this affects Mac. >>> >>> Scott >>> >>> [1] http://www.lyx.org/trac/ticket/9683#comment:12 >> >> I'm not sure I understand the issue with #9683. The mentioned short cut >> doesn't exist on Mac. > > This is not important. _Any_ shortcut in sub-dialogs does not work for me. > >> If I try Command-Control-O (dialog-show toc) it >> works with Qt 5.4.2 and with 5.5.1. But what I can reproduce is bug #9889. >> With Qt 5.4.2 the Advanced-Find-and-Replace dialog is resizable with 5.5.1 >> it isn't. > > Open Advanced-Find-and-Replace dialog and try some shortcuts there. Does it > work for you? Yes, I tried it with dialog-show toc (Command-Control-O). Command-O (file open dialog) works too. Stephan > >> Since it is way too small on first open it is unusable. So this >> is a show stopper for 5.5.1. > > +1 > >> Stephan > > Kornel
Re: merging of po files done? Send email to translators?
On Sun, Dec 06, 2015 at 09:22:45AM -0500, Richard Heck wrote: > On 12/06/2015 05:50 AM, Georg Baum wrote: > > Scott Kostyshak wrote: > > > >> On Thu, Dec 03, 2015 at 09:36:17PM +0100, Georg Baum wrote: > >> > >>> I could not find any wrong looking translations by a quick glance at the > >>> resulting diff, so I would recommend to run this command and commit the > >>> result as a first step. > >> If you think you should commit, please do. > > Done. > > > >> It would be nice to say in Development.lyx exactly which commands the > >> translators should run and which commands developers are responsible for > >> running (and when in the development process we should run them). > > There is already a section about translation in Additional.lyx. > > It's in the Customization manual. > > > I believe it > > would be better not to spread the documentation for translators over > > different documents. I agree that having this in Development.lyx make > > sense, > > so what about moving all the translation information to Development.lyx, > > and > > keeping only a hint in Additional.lyx? > > I think that makes a lot of sense. +1 > I would also suggest that we add this file to the Help menu. It wouldn't > be a terrible thing for people to be able to discover it. I don't have a strong opinion on this. Should we put it in the bottom or "hide" it in the "Specific Manuals" submenu? It is specific in the sense that it is only for developers, but I don't know if that is too much of a stretch. Scott signature.asc Description: PGP signature
Re: We now include both png and svgz?
On Sun, Dec 06, 2015 at 03:08:47PM +0100, Enrico Forestieri wrote: > On Sun, Dec 06, 2015 at 11:52:14AM +0100, Georg Baum wrote: > > > Jean-Marc Lasgouttes wrote: > > > > > Le 06/12/15 00:02, Scott Kostyshak a écrit : > > >> There was an issue on Windows that came from not including a .dll. Now > > >> that the issue has been fixed, we should decide if we would like to > > >> consider removing the .pngs. If we would like to remove the .pngs for > > >> 2.2.0 I think we should definitely do this for beta1. Conversely, if we > > >> remove the .pngs for beta, I think it would still be OK to add them back > > >> for the final release if we discover problems, as JMarc proposed [1]. > > > > > > I think we should remove them. > > > > Me too. As I wrote in the bug report, the current state does not make > > sense. > > If we do not remove the .pngs for some reason, then we need to change the > > search algorithm to use .png them if loading .svg fails. > > The attached script and patch get rid of the unneeded pngs. From what I understand, there is support for the change. I think Georg's main concern was that on some systems it might not work, but Enrico seems confident that it will work even on less commonly used systems and even for 4.8.x. Enrico, I would say commit. Thanks for the patch. Scott signature.asc Description: PGP signature
Loading open files from last session
Under Tools > Preferences > Look & Feel > Document Handling, the first check box of the initial three, "Restore windows layouts and geometries", doesn't work as far as split view windows are concerned. (surely included under "layouts and geometries"?). This is true of 2.2 alpha2 and 2.1.4 on Windows 7. A current project requires about 8 documents open at once, split into two groups, one viewed in the left pane, the other the right. When launched LyX opens all the documents (the third check box is set) and remembers cursor positions (the second check box is set) but doesn't split the view (the first check box is set but ineffective). Andrew --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Should we release 2.2.0 with Qt 5.5.1?
Am 06.12.2015 um 12:32 schrieb Georg Baum: Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC 2013 (32bit). Did you recompile the dependencies iconv, hunspell and zlib with MSVC 2013? Of course not. I don't know how to do this and who did this in the past. If you did not, we cannot use the result: Even if it seems to work at first glance, mixing code compiled with different MSVC versions can lead to subtle crashes at runtime. See also this thread: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189076.html So since I cannot compile iconv and friends with MSVC 2013, I cannot release a LyX 2.2 version? For now I only found one crash bug: http://www.lyx.org/trac/ticket/9892 nothing more. Do you think that it is caused by iconv and friends? My spare time is now running out. I will be completely off from December 12 until January 6. lets see then what the status is. Maybe Vincent could help us here. regards Uwe
Re: Latest changes in manuals
Am 06.12.2015 um 13:52 schrieb Georg Baum: http://www.lyx.org/trac/changeset/d879599cec4902a1a3ea7aa7a8d7d24815701036/lyxgit or http://www.lyx.org/trac/changeset/42536a561606290ebdb90c46badbb451487f5293/lyxgit None of these did change a path. they did: -\origin /systemlyxdir/doc/ +\origin unavailable - Do not change the paths in general if the files can be found using the relative paths. Has the additional benefit that this is also the wanted behaviour if I copy a whole directory of LyX files (including referenced graphics) to a new location. Disadvantage would be that the machinery does now depend on the presence of external files, and it is not guaranteed that the file that is found is the correct one. I would prefer that but don#t know enough about the background of such a change. That is not true. I know why this doesn't work. That is why the installer exists: you need to specify the PATH variable linking to Perl (e.g for texindy), Python (for our scripts), ImageMagick which needs also Ghostscript, rsvg and/or Inkscape. If this is the only issue then you can run LyX from within MSVC easily: You can specify environment variables for debugging in MSVC, so you can set the correct PATH once in MSVC and then save a lot of time by not requiring installation for each tiny source change. I don't know by heart how to do it, but I can look it up if you want. Well, nobody can tell me how to do this. regards Uwe
Re: CMake problem when compiling with Qt 5.5 and MSVC 2013
Peter, could you perhaps help me here? thanks and regards Uwe Am 06.12.2015 um 22:19 schrieb Kornel Benko: Am Sonntag, 6. Dezember 2015 um 22:07:17, schrieb Uwe Stöhr When I compile LyX 2.2git with Qt5.5 and MSVC 2013 in install mode this command is executed: msbuild INSTALL.vcxproj /p:Configuration=Release But this leads now to these errors: "D:\LyXGit\Master\compile-2013\INSTALL.vcxproj" (Standardziel) (1) -> (PostBuildEvent Ziel) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: Der Befehl "setlocal\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmErrorLevel\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: exit /b %1\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmDone\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :VCEnd" wurde mit dem Code 1 beendet. [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] Kornel, maybe you have an idea what is going on because with MSVC 2010 no error occurs. I know nothing about MSVC. But Peter does. We have one conditional statements in CMakeLists.txt depending on MSVC12. But nothing to MSVC13. For MSVC12 it is because of linking parameter "/vd2", which I think may not apply here. Sorry.
Re: CMake problem when compiling with Qt 5.5 and MSVC 2013
Am Sonntag, 6. Dezember 2015 um 22:07:17, schrieb Uwe Stöhr > When I compile LyX 2.2git with Qt5.5 and MSVC 2013 in install mode this > command is executed: > > msbuild INSTALL.vcxproj /p:Configuration=Release > > But this leads now to these errors: > > "D:\LyXGit\Master\compile-2013\INSTALL.vcxproj" (Standardziel) (1) -> > (PostBuildEvent Ziel) -> >C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: Der Befehl "setlocal\r > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" > -DBUILD_TYPE=Release -P cmake_install.cmake\r > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: if %errorlevel% neq 0 goto :cmEnd\r > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: :cmEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone\r > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: :cmErrorLevel\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: exit /b %1\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: :cmDone\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: if %errorlevel% neq 0 goto :VCEnd\r > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > C:\Program Files > (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): > error > MSB3073: :VCEnd" wurde mit dem Code 1 beendet. > [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] > > > Kornel, maybe you have an idea what is going on because with MSVC 2010 > no error occurs. I know nothing about MSVC. But Peter does. We have one conditional statements in CMakeLists.txt depending on MSVC12. But nothing to MSVC13. For MSVC12 it is because of linking parameter "/vd2", which I think may not apply here. Sorry. > thanks and regards > Uwe signature.asc Description: This is a digitally signed message part.
CMake problem when compiling with Qt 5.5 and MSVC 2013
When I compile LyX 2.2git with Qt5.5 and MSVC 2013 in install mode this command is executed: msbuild INSTALL.vcxproj /p:Configuration=Release But this leads now to these errors: "D:\LyXGit\Master\compile-2013\INSTALL.vcxproj" (Standardziel) (1) -> (PostBuildEvent Ziel) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: Der Befehl "setlocal\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: "C:\Program Files (x86)\CMake\bin\cmake.exe" -DBUILD_TYPE=Release -P cmake_install.cmake\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmErrorLevel\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: exit /b %1\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmDone\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd\r [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :VCEnd" wurde mit dem Code 1 beendet. [D:\LyXGit\Master\compile-2013\INSTALL.vcxproj] Kornel, maybe you have an idea what is going on because with MSVC 2010 no error occurs. thanks and regards Uwe
Re: using std_regex on Windows leads to 135 compilation errors
Am 06.12.2015 um 21:08 schrieb Georg Baum: But I started yesterday from scratch because I updated to MSVC 2013 and Qt 5.5.1. so everything is 100% new. And you did not run cmake and/or MSVC without the patches first? I started at first with your patches. Since I got compilation errors i reverted your patches and then I could compile. Now i erased everything again, applied your patches and get e.g. for support.lib: support.lib(_allinone_const.obj) : error LNK2019: unresolved external 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_regex_traits@D@boost@@@boost@@@boost@@AAEAAV12@PBD0I@Z) referenced in function "public: __thiscall boost::basic_regexboost::regex_traits > >::basic_regexboost::w32_regex_traits > >,class std::allocator >(class std::basic_stringstd::char_traits,class std::allocator > const &,unsigned int)" (??$?0U?$char_traits@D@std@@V?$allocator@D@1@@?$basic_regex@DU?$regex_traits@DV?$w32_regex_t raits@D@boost@@@boost@@@boost@@QAE@ABV?$basic_string@DU?$char_traits@D@std@@V?$ allocator@D@2@@std@@I@Z) [D:\LyXGit\Master\compile-2013\src\tests\check_Length. vcxproj] I don't know anything about linking but to me it seems that boost regex is still used somewhere. regards Uwe
Re: Should we release 2.2.0 with Qt 5.5.1?
Am Sonntag, 6. Dezember 2015 um 21:45:23, schrieb Stephan Witt > Am 06.12.2015 um 21:00 schrieb Scott Kostyshak : > > > On Sun, Dec 06, 2015 at 12:13:04PM +0100, Kornel Benko wrote: > >> Am Sonntag, 6. Dezember 2015 um 05:12:30, schrieb Uwe Stöhr > >> > >>> Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > >>> > We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a > couple of things have changed since that conversation began that make me > think we should release with 5.5.1: > > 1. 5.5.1 has been released. > >>> > >>> Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > >>> 2013 (32bit). > >>> > 2. 5.6.0beta1 has been delayed five times so far [2]. Supposedly, it > will be released "as soon as possible" [3] but even if it is released > soon, we cannot be sure the final 5.6 will be released by the time we > want to release 2.2.0. > >>> > >>> I don't see a bug in Qt 5.5.1 that hinders us from using it for a final > >>> release. I cannot reproduce bug #9731 with Qt 5.5.1. > >>> > >>> regards Uwe > >> > >> What about http://www.lyx.org/trac/ticket/9683 > >> > >> On Ubuntu-linux I see it with QT 5.5, but not with QT 5.4 > > > > From what I understand [1], Uwe can reproduce #9227 but not #9683. It > > would be interesting to know if this affects Mac. > > > > Scott > > > > [1] http://www.lyx.org/trac/ticket/9683#comment:12 > > I'm not sure I understand the issue with #9683. The mentioned short cut > doesn't exist on Mac. This is not important. _Any_ shortcut in sub-dialogs does not work for me. > If I try Command-Control-O (dialog-show toc) it > works with Qt 5.4.2 and with 5.5.1. But what I can reproduce is bug #9889. > With Qt 5.4.2 the Advanced-Find-and-Replace dialog is resizable with 5.5.1 > it isn't. Open Advanced-Find-and-Replace dialog and try some shortcuts there. Does it work for you? > Since it is way too small on first open it is unusable. So this > is a show stopper for 5.5.1. +1 > Stephan Kornel signature.asc Description: This is a digitally signed message part.
Re: Latest changes in manuals
Am Sonntag, 6. Dezember 2015 um 20:16:02, schrieb Georg Baum > Kornel Benko wrote: > > > Am Sonntag, 6. Dezember 2015 um 13:52:58, schrieb Georg Baum > > > >> Unfortunately I am not sure what to do. Here are the alternatives I can > >> imagine: > >> > >> - Set \origin to unavailable for all docs in the sources. This would be > >> easy to do, but also mean that we need to change it during installation > >> (which is currently only implemented for autotools, not in cmake and not > >> in the windows installer) > > > > Like the attached? > > If it does not replace \origin outside the header, then yes. For what > purpose are all the other replacements BTW? > Same as in autotools. See target install-data-hook at lib/doc/Makefile.am:322 > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: Should we release 2.2.0 with Qt 5.5.1?
Am 06.12.2015 um 21:00 schrieb Scott Kostyshak : > On Sun, Dec 06, 2015 at 12:13:04PM +0100, Kornel Benko wrote: >> Am Sonntag, 6. Dezember 2015 um 05:12:30, schrieb Uwe Stöhr >> >>> Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: >>> We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a couple of things have changed since that conversation began that make me think we should release with 5.5.1: 1. 5.5.1 has been released. >>> >>> Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC >>> 2013 (32bit). >>> 2. 5.6.0beta1 has been delayed five times so far [2]. Supposedly, it will be released "as soon as possible" [3] but even if it is released soon, we cannot be sure the final 5.6 will be released by the time we want to release 2.2.0. >>> >>> I don't see a bug in Qt 5.5.1 that hinders us from using it for a final >>> release. I cannot reproduce bug #9731 with Qt 5.5.1. >>> >>> regards Uwe >> >> What about http://www.lyx.org/trac/ticket/9683 >> >> On Ubuntu-linux I see it with QT 5.5, but not with QT 5.4 > > From what I understand [1], Uwe can reproduce #9227 but not #9683. It > would be interesting to know if this affects Mac. > > Scott > > [1] http://www.lyx.org/trac/ticket/9683#comment:12 I'm not sure I understand the issue with #9683. The mentioned short cut doesn't exist on Mac. If I try Command-Control-O (dialog-show toc) it works with Qt 5.4.2 and with 5.5.1. But what I can reproduce is bug #9889. With Qt 5.4.2 the Advanced-Find-and-Replace dialog is resizable with 5.5.1 it isn't. Since it is way too small on first open it is unusable. So this is a show stopper for 5.5.1. Stephan
Re: cmake std::regex detection on unix
Am Sonntag, 6. Dezember 2015 um 20:05:26, schrieb Georg Baum > Kornel Benko wrote: > > > The patch does not handle the windows part. For unix and MINGW I'd say > > yes. > > windows is not handled on purpose. Until we know the reason for the linker > errors Uwe is seeing we should not touch the MSVC part IMHO. > Yes, that is my feeling too. Wanted to be sure. > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: using std_regex on Windows leads to 135 compilation errors
Uwe Stöhr wrote: > Am 06.12.2015 um 15:27 schrieb Georg Baum: > >> I still believe that you have left overs from previous compilations. >> Please start again from an empty build directory and tell us the result. > > But I started yesterday from scratch because I updated to MSVC 2013 and > Qt 5.5.1. so everything is 100% new. And you did not run cmake and/or MSVC without the patches first? Georg
Re: using std_regex on Windows leads to 135 compilation errors
Am 06.12.2015 um 15:27 schrieb Georg Baum: I still believe that you have left overs from previous compilations. Please start again from an empty build directory and tell us the result. But I started yesterday from scratch because I updated to MSVC 2013 and Qt 5.5.1. so everything is 100% new. regards Uwe
Re: Should we release 2.2.0 with Qt 5.5.1?
On Sun, Dec 06, 2015 at 12:13:04PM +0100, Kornel Benko wrote: > Am Sonntag, 6. Dezember 2015 um 05:12:30, schrieb Uwe Stöhr > > Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > > > > > We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a > > > couple of things have changed since that conversation began that make me > > > think we should release with 5.5.1: > > > > > > 1. 5.5.1 has been released. > > > > Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > > 2013 (32bit). > > > > > 2. 5.6.0beta1 has been delayed five times so far [2]. Supposedly, it > > > will be released "as soon as possible" [3] but even if it is released > > > soon, we cannot be sure the final 5.6 will be released by the time we > > > want to release 2.2.0. > > > > I don't see a bug in Qt 5.5.1 that hinders us from using it for a final > > release. I cannot reproduce bug #9731 with Qt 5.5.1. > > > > regards Uwe > > What about http://www.lyx.org/trac/ticket/9683 > > On Ubuntu-linux I see it with QT 5.5, but not with QT 5.4 From what I understand [1], Uwe can reproduce #9227 but not #9683. It would be interesting to know if this affects Mac. Scott [1] http://www.lyx.org/trac/ticket/9683#comment:12 signature.asc Description: PGP signature
Re: Should we release 2.2.0 with Qt 5.5.1?
On Sun, Dec 06, 2015 at 12:32:20PM +0100, Georg Baum wrote: > Uwe Stöhr wrote: > > > Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > > > >> We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a > >> couple of things have changed since that conversation began that make me > >> think we should release with 5.5.1: > >> > >> 1. 5.5.1 has been released. > > > > Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > > 2013 (32bit). > > Did you recompile the dependencies iconv, hunspell and zlib with MSVC 2013? > If you did not, we cannot use the result: Even if it seems to work at first > glance, mixing code compiled with different MSVC versions can lead to subtle > crashes at runtime. See also this thread: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189076.html Uwe, I wonder if this has to do with the recent crash you reported (http://www.lyx.org/trac/ticket/9892). Scott signature.asc Description: PGP signature
Re: Latest changes in manuals
Kornel Benko wrote: > Am Sonntag, 6. Dezember 2015 um 13:52:58, schrieb Georg Baum > >> Unfortunately I am not sure what to do. Here are the alternatives I can >> imagine: >> >> - Set \origin to unavailable for all docs in the sources. This would be >> easy to do, but also mean that we need to change it during installation >> (which is currently only implemented for autotools, not in cmake and not >> in the windows installer) > > Like the attached? If it does not replace \origin outside the header, then yes. For what purpose are all the other replacements BTW? Georg
Re: cmake std::regex detection on unix
Kornel Benko wrote: > The patch does not handle the windows part. For unix and MINGW I'd say > yes. windows is not handled on purpose. Until we know the reason for the linker errors Uwe is seeing we should not touch the MSVC part IMHO. Georg
Re: Tentative schedule for 2.2.0 release
Le 05/12/2015 21:41, Scott Kostyshak a écrit : On Tue, Dec 01, 2015 at 08:26:35PM +, Guillaume Munch wrote: is it possible to implement the format change (which I feel is stable now) for 2.2.0 and implement the polished visible changes in 2.2.1 or 2.2.2? I am fine with this but I'd like to get a +1 from someone else. Have we done this in the past? It seems like a great strategy to me. Ok, since everyone agrees that this is a good idea, let's just do the format change for now. I don't have much time currently and it's better to not do things in a rush. I'll post a patch to the list soon (when I have more time). Guillaume
Re: Latest changes in manuals
Am Sonntag, 6. Dezember 2015 um 13:52:58, schrieb Georg Baum
> Uwe Stöhr wrote:
>
> > Am 03.12.2015 um 21:57 schrieb Georg Baum:
> >
> >>> The system for saving relative paths, etc, seems a bit...delicate.
> >>
> >> Maybe, maybe not (so far only Uwe saw this).
> >
> > Also others have this problem as well, see e.g. Kornel's commits:
> >
> http://www.lyx.org/trac/changeset/d879599cec4902a1a3ea7aa7a8d7d24815701036/lyxgit
> > or
> >
> http://www.lyx.org/trac/changeset/42536a561606290ebdb90c46badbb451487f5293/lyxgit
>
> None of these did change a path.
>
> >> One thing is clear however: Files with \origin /systemlyxdir/doc/ must be
> >> edited with a LyX binary that belongs to the directory where the file is
> >> located:
> >
> > Why is this clever?
>
> clear, not clever.
>
> > I don't see the benefit. There is no reason in my
> > opinion that the path is changed because all dependencies of the file
> > are existent and correct. So there is no obvious reason why the relative
> > paths are automatically converted to absolute ones.
>
> I was now able to reproduce the changed paths. According to
> http://www.lyx.org/trac/ticket/9815 this works as designed: If a document
> contains a valid \origin tag, then all relative paths are changed to
> absolute ones constructed from \origin on saving.
>
> This is in general the wanted behaviour (and the reason for having \origin
> at all), except for one case: Editing LyX documentation in a directory which
> is not the system dirctory as determined by the Package class in
> src/support. In this case, the \origin machinery assumes that the user did
> copy the doc to some other location, and that he wants to keep it separate
> from the LyX installation. This assumption is wrong if one edits the docs in
> the source tree, and I agree that something needs to be done for this case.
>
> Unfortunately I am not sure what to do. Here are the alternatives I can
> imagine:
>
> - Set \origin to unavailable for all docs in the sources. This would be easy
> to do, but also mean that we need to change it during installation (which is
> currently only implemented for autotools, not in cmake and not in the
> windows installer)
Like the attached?
> - Implement some heuristic to recognize if docs in a LyX in lib/doc
> directory of a source tree are edited, and do not change paths if that is
> the case. Not very transparent for the user, and strange things can happen
> if the heuristic is wrong.
>
> - Do not change the paths in general if the files can be found using the
> relative paths. Has the additional benefit that this is also the wanted
> behaviour if I copy a whole directory of LyX files (including referenced
> graphics) to a new location. Disadvantage would be that the machinery does
> now depend on the presence of external files, and it is not guaranteed that
> the file that is found is the correct one.
+1
> Are there other possible solutions? I prefer the last one, since it does not
> get into the way of people who know what they are doing and copy a LyX file
> including all needed dependencies. The current solution punishes these
> people by requiring them to repair the incorrectly changed paths by hand, or
> by forcing them to disallow setting \origin in the preferences (but the
> latter does not work if you receive files from collaborators which have
> \origin set).
>
> >> Uwe says he cannot run LyX from the build dir. I believe that this is a
> >> major time sink (installation is needed for testing a tiny source change,
> >> using the debugger is not possible etc), and I offered my help for
> >> investigation, but so far he did not want to investigate why running from
> >> the build dir does not work.
> >
> > That is not true. I know why this doesn't work. That is why the
> > installer exists: you need to specify the PATH variable linking to Perl
> > (e.g for texindy), Python (for our scripts), ImageMagick which needs
> > also Ghostscript, rsvg and/or Inkscape.
>
> If this is the only issue then you can run LyX from within MSVC easily:
> You can specify environment variables for debugging in MSVC, so you can set
> the correct PATH once in MSVC and then save a lot of time by not requiring
> installation for each tiny source change. I don't know by heart how to do
> it, but I can look it up if you want.
>
>
> Georg
Kornel
signature.asc
Description: This is a digitally signed message part.
diff --git a/development/cmake/doc/CMakeLists.txt b/development/cmake/doc/CMakeLists.txt
index 7d9eef3..9391e2c 100644
--- a/development/cmake/doc/CMakeLists.txt
+++ b/development/cmake/doc/CMakeLists.txt
@@ -30,7 +30,11 @@ foreach(_rel_doc ${_rel_lyx_docs})
SET_SOURCE_FILES_PROPERTIES(${_created_doc} GENERATED)
add_custom_command(
OUTPUT "${_created_doc}"
-COMMAND ${LYX_PYTHON_EXECUTABLE} "${TOP_CMAKE_PATH}/doc/ReplaceValues.py" "LYX_USERDIR_VER=${LYX_USERDIR_VER}" "LYX_DIR_VER=${LYX_DIR_VER}" "${TOP_SRC_DIR}/lib/doc/${_rel_doc}" > "${_created_doc}"
+COMMAND ${
Re: cmake std::regex detection on unix
Am Sonntag, 6. Dezember 2015 um 17:56:41, schrieb Georg Baum > Kornel Benko wrote: > > > Test for headers is done in ConfigureChecks.cmake. Simply add the header > > name to the foreach loop at line 28. > > The created variable for header xy.h is "HAVE_XY_H". > > Thanks, this was the place I serached. Unfortunately it does not work > exactly like that (regex is a C++ header), but a few lines above I could see > how C++ headers are checked. > > The attached patch make cmake behave like autotools. OK to go in? > The patch does not handle the windows part. For unix and MINGW I'd say yes. We have CMakeLists.txt:251 if(UNIX OR MINGW) # you changed/added some lines else() # windows part not changed endif() > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: cmake std::regex detection on unix
Am Sonntag, 6. Dezember 2015 um 17:56:41, schrieb Georg Baum > Kornel Benko wrote: > > > Test for headers is done in ConfigureChecks.cmake. Simply add the header > > name to the foreach loop at line 28. > > The created variable for header xy.h is "HAVE_XY_H". > > Thanks, this was the place I serached. Unfortunately it does not work > exactly like that (regex is a C++ header), but a few lines above I could see > how C++ headers are checked. > > The attached patch make cmake behave like autotools. OK to go in? > Looks good. Compiling now. > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: Link to latest pre-release
Scott Kostyshak wrote: > like > http://www.lyx.org/Download/latest-pre the link might fit here http://www.lyx.org/RoadMap p
Re: cmake std::regex detection on unix
Kornel Benko wrote:
> Test for headers is done in ConfigureChecks.cmake. Simply add the header
> name to the foreach loop at line 28.
> The created variable for header xy.h is "HAVE_XY_H".
Thanks, this was the place I serached. Unfortunately it does not work
exactly like that (regex is a C++ header), but a few lines above I could see
how C++ headers are checked.
The attached patch make cmake behave like autotools. OK to go in?
Georg
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a87b049..5840ad0 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -255,6 +255,10 @@ if(UNIX OR MINGW)
# in gcc is unusable in versions less than 4.9.0
# see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631
set(LYX_USE_STD_REGEX 0)
+ else()
+ if (LYX_ENABLE_CXX11)
+ set(LYX_USE_STD_REGEX 1)
+ endif()
endif()
if (LYX_ENABLE_CXX11)
find_package(CXX11Compiler)
@@ -856,6 +860,10 @@ if(QTVERSION MATCHES "^([0-9]+)\\.([0-9]+)\\.([0-9]+).*")
MATH(EXPR QT4_VERSION "(${CMAKE_MATCH_1}<<16)|(${CMAKE_MATCH_2}<<8)|${CMAKE_MATCH_3}")
endif()
+if (NOT HAVE_REGEX)
+ set(LYX_USE_STD_REGEX 0)
+endif()
+
set (cmd ${CMAKE_CTEST_COMMAND})
if (MSVC)
diff --git a/development/cmake/ConfigureChecks.cmake b/development/cmake/ConfigureChecks.cmake
index b29416f..46ee11f 100644
--- a/development/cmake/ConfigureChecks.cmake
+++ b/development/cmake/ConfigureChecks.cmake
@@ -33,6 +33,8 @@ foreach(_h_file aspell.h aspell/aspell.h limits.h locale.h
check_include_files(${_h_file} HAVE_${_HF})
set(Include_Defines "${Include_Defines}#cmakedefine HAVE_${_HF} 1\n")
endforeach()
+check_include_file_cxx(regex HAVE_REGEX)
+set(Include_Defines "${Include_Defines}#cmakedefine HAVE_REGEX 1\n")
configure_file(${LYX_CMAKE_DIR}/configIncludes.cmake ${TOP_BINARY_DIR}/configIncludes.h.cmake)
configure_file(${TOP_BINARY_DIR}/configIncludes.h.cmake ${TOP_BINARY_DIR}/configIncludes.h)
Re: cmake std::regex detection on unix
Am Sonntag, 6. Dezember 2015 um 14:36:41, schrieb Georg Baum > Hi Kornel, > > when compiling with cmake and LYX_ENABLE_CXX11=ON, std::regex is not used. > This is different to autotools, where std::regex is used, if C++11 is used, > and the header is present, and the compiler is not gcc with known std::regex > bugs. It would be nice if cmake could use the same logic. Unfortunately I > don't know how to test for the header, otherwise I'd do it myself. > Test for headers is done in ConfigureChecks.cmake. Simply add the header name to the foreach loop at line 28. The created variable for header xy.h is "HAVE_XY_H". This variable is part of "config.h", so that it can be interpreted also in sources (e.g. *.cpp) cmake: if (HAVE_XY_H) do something endif() > Georg Kornel signature.asc Description: This is a digitally signed message part.
Re: using std_regex on Windows leads to 135 compilation errors
Uwe Stöhr wrote: > Am 04.12.2015 um 20:53 schrieb Georg Baum: > >> This is mot likely caused by an incomplete rebuild. Does it work if you >> rebuild the projects that appear in the error messages (the first one I >> could see was insets.lib)? > > No this doesn't work. The first library with an error is biblio. Forcing > its creation leads to the same errors as before: biblio is not a library. It is a test program that only needs to be compiled if you want to run the source code unit tests. If you recompile only biblio, then it does not recompile the libs that it uses (e.g. support). I searched through the whole source code and cmake config files, and did not find any place wher boost::regex is used directly. The only possibility would be that the preprocessor macros LYX_USE_STD_REGEX or LYX_USE_CXX11 have the wrong value in some cases. Hwoever, seraching for these did not result in any relevant hit either. I still believe that you have left overs from previous compilations. Please start again from an empty build directory and tell us the result. Georg
Re: #9873: lyx.org does not support https
On 12/06/2015 06:41 AM, Georg Baum wrote: > Christian Ridderström wrote: > >> Note: The LE client needs root access, e.g. to stop/start apache, and to >> do other stuff in order to prove to the LE servers that we (i.e. the >> server) really are the one controlling www.lyx.org and wiki.lyx.org. The >> cron job then also needs root/sudo in order to update the client. > Giving root access to the LE client is IMHO a no-go. It means you need to > trust a relatively new piece of code which is controlled from outside (even > worse). See also this (german) blog entry: http://blog.fefe.de/?ts=a89f4ed6 > > It is a rant, but as usual for Fefe it contains some substantial reasoning > as well. > > If Letsencrypt does not allow to download the certificate manually, so that > it can be installed manually in a trusted environment, some other > certificate provider should be used IMHO. This does seem to be possible, but needs some investigation. See https://community.letsencrypt.org/t/i-just-want-a-certificate/5331/10 for some of the relevant details. I intend to play around with this, as I said in a different email, on my own server. If I get it working there, I can do it also on lyx.org, with documentation about how it works. The one downside will be the need to update the certificate manually every three months. Richard
Re: merging of po files done? Send email to translators?
On 12/06/2015 05:50 AM, Georg Baum wrote: > Scott Kostyshak wrote: > >> On Thu, Dec 03, 2015 at 09:36:17PM +0100, Georg Baum wrote: >> >>> I could not find any wrong looking translations by a quick glance at the >>> resulting diff, so I would recommend to run this command and commit the >>> result as a first step. >> If you think you should commit, please do. > Done. > >> It would be nice to say in Development.lyx exactly which commands the >> translators should run and which commands developers are responsible for >> running (and when in the development process we should run them). > There is already a section about translation in Additional.lyx. It's in the Customization manual. > I believe it > would be better not to spread the documentation for translators over > different documents. I agree that having this in Development.lyx make sense, > so what about moving all the translation information to Development.lyx, and > keeping only a hint in Additional.lyx? I think that makes a lot of sense. I would also suggest that we add this file to the Help menu. It wouldn't be a terrible thing for people to be able to discover it. Richard
Re: Latest changes in manuals
Am Sonntag, 6. Dezember 2015 um 13:52:58, schrieb Georg Baum
> Uwe Stöhr wrote:
>
> > Am 03.12.2015 um 21:57 schrieb Georg Baum:
> >
> >>> The system for saving relative paths, etc, seems a bit...delicate.
> >>
> >> Maybe, maybe not (so far only Uwe saw this).
> >
> > Also others have this problem as well, see e.g. Kornel's commits:
> >
> http://www.lyx.org/trac/changeset/d879599cec4902a1a3ea7aa7a8d7d24815701036/lyxgit
> > or
> >
> http://www.lyx.org/trac/changeset/42536a561606290ebdb90c46badbb451487f5293/lyxgit
>
> None of these did change a path.
>
> >> One thing is clear however: Files with \origin /systemlyxdir/doc/ must be
> >> edited with a LyX binary that belongs to the directory where the file is
> >> located:
> >
> > Why is this clever?
>
> clear, not clever.
>
> > I don't see the benefit. There is no reason in my
> > opinion that the path is changed because all dependencies of the file
> > are existent and correct. So there is no obvious reason why the relative
> > paths are automatically converted to absolute ones.
>
> I was now able to reproduce the changed paths. According to
> http://www.lyx.org/trac/ticket/9815 this works as designed: If a document
> contains a valid \origin tag, then all relative paths are changed to
> absolute ones constructed from \origin on saving.
>
> This is in general the wanted behaviour (and the reason for having \origin
> at all), except for one case: Editing LyX documentation in a directory which
> is not the system dirctory as determined by the Package class in
> src/support. In this case, the \origin machinery assumes that the user did
> copy the doc to some other location, and that he wants to keep it separate
> from the LyX installation. This assumption is wrong if one edits the docs in
> the source tree, and I agree that something needs to be done for this case.
>
> Unfortunately I am not sure what to do. Here are the alternatives I can
> imagine:
>
> - Set \origin to unavailable for all docs in the sources. This would be easy
> to do, but also mean that we need to change it during installation (which is
> currently only implemented for autotools, not in cmake and not in the
> windows installer)
How about attached?
> - Implement some heuristic to recognize if docs in a LyX in lib/doc
> directory of a source tree are edited, and do not change paths if that is
> the case. Not very transparent for the user, and strange things can happen
> if the heuristic is wrong.
>
> - Do not change the paths in general if the files can be found using the
> relative paths. Has the additional benefit that this is also the wanted
> behaviour if I copy a whole directory of LyX files (including referenced
> graphics) to a new location. Disadvantage would be that the machinery does
> now depend on the presence of external files, and it is not guaranteed that
> the file that is found is the correct one.
+1
> Are there other possible solutions? I prefer the last one, since it does not
> get into the way of people who know what they are doing and copy a LyX file
> including all needed dependencies. The current solution punishes these
> people by requiring them to repair the incorrectly changed paths by hand, or
> by forcing them to disallow setting \origin in the preferences (but the
> latter does not work if you receive files from collaborators which have
> \origin set).
>
> >> Uwe says he cannot run LyX from the build dir. I believe that this is a
> >> major time sink (installation is needed for testing a tiny source change,
> >> using the debugger is not possible etc), and I offered my help for
> >> investigation, but so far he did not want to investigate why running from
> >> the build dir does not work.
> >
> > That is not true. I know why this doesn't work. That is why the
> > installer exists: you need to specify the PATH variable linking to Perl
> > (e.g for texindy), Python (for our scripts), ImageMagick which needs
> > also Ghostscript, rsvg and/or Inkscape.
>
> If this is the only issue then you can run LyX from within MSVC easily:
> You can specify environment variables for debugging in MSVC, so you can set
> the correct PATH once in MSVC and then save a lot of time by not requiring
> installation for each tiny source change. I don't know by heart how to do
> it, but I can look it up if you want.
>
>
> Georg
Kornel
signature.asc
Description: This is a digitally signed message part.
diff --git a/development/cmake/doc/CMakeLists.txt b/development/cmake/doc/CMakeLists.txt
index 7d9eef3..9391e2c 100644
--- a/development/cmake/doc/CMakeLists.txt
+++ b/development/cmake/doc/CMakeLists.txt
@@ -30,7 +30,11 @@ foreach(_rel_doc ${_rel_lyx_docs})
SET_SOURCE_FILES_PROPERTIES(${_created_doc} GENERATED)
add_custom_command(
OUTPUT "${_created_doc}"
-COMMAND ${LYX_PYTHON_EXECUTABLE} "${TOP_CMAKE_PATH}/doc/ReplaceValues.py" "LYX_USERDIR_VER=${LYX_USERDIR_VER}" "LYX_DIR_VER=${LYX_DIR_VER}" "${TOP_SRC_DIR}/lib/doc/${_rel_doc}" > "${_created_doc}"
+COMMAND $
Re: We now include both png and svgz?
On Sun, Dec 06, 2015 at 11:52:14AM +0100, Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > > > Le 06/12/15 00:02, Scott Kostyshak a écrit : > >> There was an issue on Windows that came from not including a .dll. Now > >> that the issue has been fixed, we should decide if we would like to > >> consider removing the .pngs. If we would like to remove the .pngs for > >> 2.2.0 I think we should definitely do this for beta1. Conversely, if we > >> remove the .pngs for beta, I think it would still be OK to add them back > >> for the final release if we discover problems, as JMarc proposed [1]. > > > > I think we should remove them. > > Me too. As I wrote in the bug report, the current state does not make sense. > If we do not remove the .pngs for some reason, then we need to change the > search algorithm to use .png them if loading .svg fails. The attached script and patch get rid of the unneeded pngs. -- Enrico rmpng.sh Description: Bourne shell script diff --git a/lib/Makefile.am b/lib/Makefile.am index 63ebfba..62d10d4 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -19,7 +19,7 @@ dist_noinst_DATA = \ fonts/stmary10.sfd \ fonts/test/stmary10.lyx \ images/README \ - images/font-smallcaps.png \ + images/font-smallcaps.svgz \ images/math/ams_arrows.png \ images/math/ams_misc.png \ images/math/ams_nrel.png \ @@ -28,13 +28,12 @@ dist_noinst_DATA = \ images/math/arrows.png \ images/math/bop.png \ images/math/brel.png \ - images/math/deco.png \ - images/math/deco.png \ - images/math/delim0.png \ - images/math/delim1.png \ - images/math/delim.png \ - images/math/dots.png \ - images/math/font.png \ + images/math/deco.svgz \ + images/math/delim0.svgz \ + images/math/delim1.svgz \ + images/math/delim.svgz \ + images/math/dots.svgz \ + images/math/font.svgz \ images/math/greek.png \ images/math/misc.png \ images/math/varsz.png @@ -373,196 +372,193 @@ dist_fonts_DATA = \ imagesdir = $(pkgdatadir)/images dist_images_DATA1X = \ - images/all-changes-accept.png \ - images/all-changes-reject.png \ - images/banner.png \ - images/bookmark-goto.png \ - images/bookmark-goto_0.png \ - images/bookmark-save.png \ - images/box-insert.png \ - images/break-line.png \ - images/buffer-close.png \ - images/buffer-export.png \ - images/buffer-export_dvi.png \ - images/buffer-export_dvi3.png \ - images/buffer-export_latex.png \ - images/buffer-export_pdf.png \ - images/buffer-export_pdf2.png \ - images/buffer-export_pdf3.png \ - images/buffer-export_pdf4.png \ - images/buffer-export_pdf5.png \ - images/buffer-export_ps.png \ - images/buffer-export_text.png \ - images/buffer-new.png \ - images/buffer-reload.png \ - images/buffer-toggle-output-sync.png \ - images/buffer-update.png \ - images/buffer-update_dvi.png \ - images/buffer-update_dvi3.png \ - images/buffer-update_pdf.png \ - images/buffer-update_pdf2.png \ - images/buffer-update_pdf3.png \ - images/buffer-update_pdf4.png \ - images/buffer-update_pdf5.png \ - images/buffer-update_ps.png \ - images/buffer-view.png \ - images/buffer-view_dvi.png \ - images/buffer-view_dvi3.png \ - images/buffer-view_pdf.png \ - images/buffer-view_pdf2.png \ - images/buffer-view_pdf3.png \ - images/buffer-view_pdf4.png \ - images/buffer-view_pdf5.png \ - images/buffer-view_ps.png \ - images/buffer-write-as.png \ - images/buffer-write.png \ - images/build-program.png \ + images/all-changes-accept.svgz \ + images/all-changes-reject.svgz \ + images/banner.svgz \ + images/bookmark-goto.svgz \ + images/bookmark-goto_0.svgz \ + images/bookmark-save.svgz \ + images/box-insert.svgz \ + images/break-line.svgz \ + images/buffer-close.svgz \ + images/buffer-export.svgz \ + images/buffer-export_dvi.svgz \ + images/buffer-export_dvi3.svgz \ + images/buffer-export_latex.svgz \ + images/buffer-export_pdf.svgz \ + images/buffer-export_pdf2.svgz \ + images/buffer-export_pdf3.svgz \ + images/buffer-export_pdf4.svgz \ + images/buffer-export_pdf5.svgz \ + images/buffer-export_ps.svgz \ + images/buffer-export_text.svgz \ + images/buffer-new.svgz \ + images/buffer-reload.svgz \ + images/buffer-toggle-output-sync.svgz \ + images/buffer-update.svgz \ + images/buffer-update_dvi.svgz \ + images/buffer-update_dvi3.svgz \ + images/buffer-update_pdf.svgz \ + images/buffer-update_pdf2.svgz \ + images/buffer-update_pdf3.svgz \ + images/buffer-update_pdf4.svgz \ + images/buffer-update_pdf5.svg
cmake std::regex detection on unix
Hi Kornel, when compiling with cmake and LYX_ENABLE_CXX11=ON, std::regex is not used. This is different to autotools, where std::regex is used, if C++11 is used, and the header is present, and the compiler is not gcc with known std::regex bugs. It would be nice if cmake could use the same logic. Unfortunately I don't know how to test for the header, otherwise I'd do it myself. Georg
Re: Latest changes in manuals
Uwe Stöhr wrote: > Am 03.12.2015 um 21:57 schrieb Georg Baum: > >>> The system for saving relative paths, etc, seems a bit...delicate. >> >> Maybe, maybe not (so far only Uwe saw this). > > Also others have this problem as well, see e.g. Kornel's commits: > http://www.lyx.org/trac/changeset/d879599cec4902a1a3ea7aa7a8d7d24815701036/lyxgit > or > http://www.lyx.org/trac/changeset/42536a561606290ebdb90c46badbb451487f5293/lyxgit None of these did change a path. >> One thing is clear however: Files with \origin /systemlyxdir/doc/ must be >> edited with a LyX binary that belongs to the directory where the file is >> located: > > Why is this clever? clear, not clever. > I don't see the benefit. There is no reason in my > opinion that the path is changed because all dependencies of the file > are existent and correct. So there is no obvious reason why the relative > paths are automatically converted to absolute ones. I was now able to reproduce the changed paths. According to http://www.lyx.org/trac/ticket/9815 this works as designed: If a document contains a valid \origin tag, then all relative paths are changed to absolute ones constructed from \origin on saving. This is in general the wanted behaviour (and the reason for having \origin at all), except for one case: Editing LyX documentation in a directory which is not the system dirctory as determined by the Package class in src/support. In this case, the \origin machinery assumes that the user did copy the doc to some other location, and that he wants to keep it separate from the LyX installation. This assumption is wrong if one edits the docs in the source tree, and I agree that something needs to be done for this case. Unfortunately I am not sure what to do. Here are the alternatives I can imagine: - Set \origin to unavailable for all docs in the sources. This would be easy to do, but also mean that we need to change it during installation (which is currently only implemented for autotools, not in cmake and not in the windows installer) - Implement some heuristic to recognize if docs in a LyX in lib/doc directory of a source tree are edited, and do not change paths if that is the case. Not very transparent for the user, and strange things can happen if the heuristic is wrong. - Do not change the paths in general if the files can be found using the relative paths. Has the additional benefit that this is also the wanted behaviour if I copy a whole directory of LyX files (including referenced graphics) to a new location. Disadvantage would be that the machinery does now depend on the presence of external files, and it is not guaranteed that the file that is found is the correct one. Are there other possible solutions? I prefer the last one, since it does not get into the way of people who know what they are doing and copy a LyX file including all needed dependencies. The current solution punishes these people by requiring them to repair the incorrectly changed paths by hand, or by forcing them to disallow setting \origin in the preferences (but the latter does not work if you receive files from collaborators which have \origin set). >> Uwe says he cannot run LyX from the build dir. I believe that this is a >> major time sink (installation is needed for testing a tiny source change, >> using the debugger is not possible etc), and I offered my help for >> investigation, but so far he did not want to investigate why running from >> the build dir does not work. > > That is not true. I know why this doesn't work. That is why the > installer exists: you need to specify the PATH variable linking to Perl > (e.g for texindy), Python (for our scripts), ImageMagick which needs > also Ghostscript, rsvg and/or Inkscape. If this is the only issue then you can run LyX from within MSVC easily: You can specify environment variables for debugging in MSVC, so you can set the correct PATH once in MSVC and then save a lot of time by not requiring installation for each tiny source change. I don't know by heart how to do it, but I can look it up if you want. Georg
Re: #9873: lyx.org does not support https
Christian Ridderström wrote: > Note: The LE client needs root access, e.g. to stop/start apache, and to > do other stuff in order to prove to the LE servers that we (i.e. the > server) really are the one controlling www.lyx.org and wiki.lyx.org. The > cron job then also needs root/sudo in order to update the client. Giving root access to the LE client is IMHO a no-go. It means you need to trust a relatively new piece of code which is controlled from outside (even worse). See also this (german) blog entry: http://blog.fefe.de/?ts=a89f4ed6 It is a rant, but as usual for Fefe it contains some substantial reasoning as well. If Letsencrypt does not allow to download the certificate manually, so that it can be installed manually in a trusted environment, some other certificate provider should be used IMHO. Georg
Re: Should we release 2.2.0 with Qt 5.5.1?
Uwe Stöhr wrote: > Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > >> We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a >> couple of things have changed since that conversation began that make me >> think we should release with 5.5.1: >> >> 1. 5.5.1 has been released. > > Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > 2013 (32bit). Did you recompile the dependencies iconv, hunspell and zlib with MSVC 2013? If you did not, we cannot use the result: Even if it seems to work at first glance, mixing code compiled with different MSVC versions can lead to subtle crashes at runtime. See also this thread: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg189076.html Georg
Re: [LyX/master] Simplify Unicode symbols for old systems
Kornel Benko wrote: > Am Samstag, 5. Dezember 2015 um 17:51:42, schrieb Guillaume Munch > >> >> OK for converting them? Or just the .h and .cpp files? > > From my POV, only .h and .cpp. I don't see a reason for CMakeLists.txt or > .m4 files. With emacs, the conversion is done automatically if using some > char not in ISO-8859. We should have a policy to have all text files in utf8 IMHO. Any other encoding does not make sense nowadays (maybe except for .tex). I vaguely remember that we do already have such a policy, but if that is true it does not seem to be documented. Georg
Re: Should we release 2.2.0 with Qt 5.5.1?
Am Sonntag, 6. Dezember 2015 um 05:12:30, schrieb Uwe Stöhr > Am 05.12.2015 um 23:07 schrieb Scott Kostyshak: > > > We had previously decided to release 2.2.0 with Qt 5.6 [1]. However, a > > couple of things have changed since that conversation began that make me > > think we should release with 5.5.1: > > > > 1. 5.5.1 has been released. > > Good news: I am able to compile LyX 2.2.0alpha2 with Qt 5.5.1 using MSVC > 2013 (32bit). > > > 2. 5.6.0beta1 has been delayed five times so far [2]. Supposedly, it > > will be released "as soon as possible" [3] but even if it is released > > soon, we cannot be sure the final 5.6 will be released by the time we > > want to release 2.2.0. > > I don't see a bug in Qt 5.5.1 that hinders us from using it for a final > release. I cannot reproduce bug #9731 with Qt 5.5.1. > > regards Uwe What about http://www.lyx.org/trac/ticket/9683 On Ubuntu-linux I see it with QT 5.5, but not with QT 5.4 Kornel signature.asc Description: This is a digitally signed message part.
Re: [LyX/master] Spanish Tutorial.lyx: preamble code proposed by Günther
Am Sonntag, 6. Dezember 2015 um 05:25:35, schrieb Uwe Stöhr > Am 04.12.2015 um 09:58 schrieb Guenter Milde: > > >> If I understand correctly, you want all tests with > >>doc/.*/.*systemF > >> being ignored. > > > >> If that should be so, than OK. > >> If not, please help the docs be in good compilable shape. > > > > I see it a bit different: > > > > * The main purpose of the manuals is user documentation. For this, > >compilability to the default output format is required. > > What I can do is to set an explicit export format if XeTeX and/or LuaTeX > fails without system fonts. > > For the compilation with system fonts we should do nothing since we > cannot know the system status of the user. If someones desperately needs > to view a doc file with his own fonts, it is his duty to select fonts > that will work. We are speaking about tests IMHO, not some user's font selection. We are not testing with arbitrary system fonts. If the system font is specified in lyx, we use it. Else we select (for most languages) the font which should be good for that language, and is free to download. > So in my opinion > doc/.*/.*systemF > can in general be ignored for all docs and for many examples files too. > For template files however, it is sensible to check also system font > compilation. > > >@Uwe: if the manuals are designed for pdflatex export, I suggest to set > >the default output format in the documents. Then we would have just one > >"standard export format". > > Agreed. I will try to find the time and do so. > > regards Uwe Kornel signature.asc Description: This is a digitally signed message part.
Re: We now include both png and svgz?
Jean-Marc Lasgouttes wrote: > Le 06/12/15 00:02, Scott Kostyshak a écrit : >> There was an issue on Windows that came from not including a .dll. Now >> that the issue has been fixed, we should decide if we would like to >> consider removing the .pngs. If we would like to remove the .pngs for >> 2.2.0 I think we should definitely do this for beta1. Conversely, if we >> remove the .pngs for beta, I think it would still be OK to add them back >> for the final release if we discover problems, as JMarc proposed [1]. > > I think we should remove them. Me too. As I wrote in the bug report, the current state does not make sense. If we do not remove the .pngs for some reason, then we need to change the search algorithm to use .png them if loading .svg fails. Georg
Re: merging of po files done? Send email to translators?
Scott Kostyshak wrote: > On Thu, Dec 03, 2015 at 09:36:17PM +0100, Georg Baum wrote: > >> I could not find any wrong looking translations by a quick glance at the >> resulting diff, so I would recommend to run this command and commit the >> result as a first step. > > If you think you should commit, please do. Done. > It would be nice to say in Development.lyx exactly which commands the > translators should run and which commands developers are responsible for > running (and when in the development process we should run them). There is already a section about translation in Additional.lyx. I believe it would be better not to spread the documentation for translators over different documents. I agree that having this in Development.lyx make sense, so what about moving all the translation information to Development.lyx, and keeping only a hint in Additional.lyx? Georg
