ru/UserGuide ctests failing
There are several ru/UserGuide ctests failing on current master, including the default output (pdflatex). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Patches to review
On 1/21/21 10:10 AM, Pavel Sanda wrote: On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote: On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote: Please review my recent patches for LyX. Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class. Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's not the case [1, 2]. Sorry that I don't know enough to look at the others. 2,3 is fine. 5 is fine unless we use direct [] access somewhere. I know Riki did not announce it officially yet, but we should start looking at fixing bugs which hinder us from 2.4 release rather than refactoring the codebase. I know, boring... I think I did send an email to that effect. In any event, my understanding is that Yuriy intends to commit these things to a feature branch for now. We don't want to risk another weird surprise like with the move constructor. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master
On 1/21/21 5:59 PM, Andrew Parsloe wrote: On 22/01/2021 11:06 am, Paul A. Rubin wrote: On 1/21/21 4:44 PM, Richard Kimberly Heck wrote: On 1/21/21 3:07 PM, Paul A. Rubin wrote: I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible (minor) bug that I'd like someone to confirm. Create a math inset and click the toolbar button to insert paired delimiters. The lfloor and rfloor delimiters look correct to me, but the lceil and rceil delimiters are just vertical lines (no horizontal "flanges"). Anyone else seeing that? Yes, I see it, and in master too. Screenshot attached. Riki Thanks. Thought I was losing it (which I suppose I still might be). I've filed a bug report (Ticket #12085) and attached your screenshot (with attribution, of course). Paul This is not true on Windows 10. \lceil and \rceil are both there, on 2.3.6 and 2.4.0 alpha. Screenshot from 2.3.6 attached. The SVG is fine. It's in the conversion to whatever we use for display that the problem happens. It looks as if the images are not properly aligned and maybe the top got cut off for some reason. I don't know if these converted images get cached somewhere. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master
On 22/01/2021 11:06 am, Paul A. Rubin wrote: On 1/21/21 4:44 PM, Richard Kimberly Heck wrote: On 1/21/21 3:07 PM, Paul A. Rubin wrote: I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible (minor) bug that I'd like someone to confirm. Create a math inset and click the toolbar button to insert paired delimiters. The lfloor and rfloor delimiters look correct to me, but the lceil and rceil delimiters are just vertical lines (no horizontal "flanges"). Anyone else seeing that? Yes, I see it, and in master too. Screenshot attached. Riki Thanks. Thought I was losing it (which I suppose I still might be). I've filed a bug report (Ticket #12085) and attached your screenshot (with attribution, of course). Paul This is not true on Windows 10. \lceil and \rceil are both there, on 2.3.6 and 2.4.0 alpha. Screenshot from 2.3.6 attached. Andrew -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [CONFIRMED] Delimiter issue in 2.3.6.1 and in master
On 1/21/21 4:44 PM, Richard Kimberly Heck wrote: On 1/21/21 3:07 PM, Paul A. Rubin wrote: I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible (minor) bug that I'd like someone to confirm. Create a math inset and click the toolbar button to insert paired delimiters. The lfloor and rfloor delimiters look correct to me, but the lceil and rceil delimiters are just vertical lines (no horizontal "flanges"). Anyone else seeing that? Yes, I see it, and in master too. Screenshot attached. Riki Thanks. Thought I was losing it (which I suppose I still might be). I've filed a bug report (Ticket #12085) and attached your screenshot (with attribution, of course). Paul -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: CMake on Windows
On Thu, 21 Jan 2021 at 19:23, Kornel Benko wrote: > Am Thu, 21 Jan 2021 18:26:38 +0100 > schrieb Thibaut Cuvelier : > > > Dear list, and Pavel mostly :) > > > > I'm starting again to configure LyX on Windows, and the CMake files do > not behave as > > expected. > > > > I am setting -DLYX_DEPENDENCIES_DOWNLOAD=1 on the command line, but this > is what it > > outputs: > > > > "C:\Program Files\JetBrains\CLion\bin\cmake\win\bin\cmake.exe" > -DCMAKE_BUILD_TYPE=Debug > > -DLYX_DEPENDENCIES_DOWNLOAD=1 -G "CodeBlocks - NMake Makefiles" > D:\Thibaut\LyX -- > > TOP_SRC_DIR = D:/Thibaut/LyX -- > > -- Building out-of-source > > -- Selecting build type defaults from configure.ac > > -- ERROR: Could NOT find GNUWIN32, please set GNUWIN32_DIR > > -- ERROR: or let cmake download all required files by using > > -DLYX_DEPENDENCIES_DOWNLOAD=1 CMake Error at > > development/cmake/modules/FindGNUWIN32.cmake:43 (message): Call Stack > (most recent call > > first): development/cmake/modules/LyXPaths.cmake:57 (find_package) > > CMakeLists.txt:251 (include) > > > > It really looks like the parameter I set is disregarded (as if the check > is done before > > any downloading can happen). My CMake skills do not allow me to debug > this thoroughly… > > > > Moreover, the variables MSVC14 and MSVC10 are discouraged since CMake > 3.8: > > https://cmake.org/cmake/help/v3.8/variable/MSVC14.html. Plus, the same > set of > > dependencies can be used for Visual C++ 2017 and 2019, which the current > code cannot do > > (and there are no more MSVC variables for these). I am joining a patch > to switch to the > > now recommended MSVC_VERSION. It is untested due to the above issue. > > Since the FindGNUWIN32 is called form > development/cmake/modules/LyXPaths.cmake > and this is called from CMakeLists.txt:251, it is no wonder, that > LYX_DEPENDENCIES_DOWNLOAD > had no effect. (It is used at CMakeLists.txt:312, (means later)). > I'm adding a second version of the patch, as the folder structure has evolved on the FTP (and there are no more prebuilt binaries for MSVC 10). unnamed.patch Description: Binary data -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
[CONFIRMED] Delimiter issue in 2.3.6.1 and in master
On 1/21/21 3:07 PM, Paul A. Rubin wrote: I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible (minor) bug that I'd like someone to confirm. Create a math inset and click the toolbar button to insert paired delimiters. The lfloor and rfloor delimiters look correct to me, but the lceil and rceil delimiters are just vertical lines (no horizontal "flanges"). Anyone else seeing that? Yes, I see it, and in master too. Screenshot attached. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Delimiter issue in 2.3.6.1
I'm using LyX 2.3.6.1 on Linux Mint, and I just tripped over a possible (minor) bug that I'd like someone to confirm. Create a math inset and click the toolbar button to insert paired delimiters. The lfloor and rfloor delimiters look correct to me, but the lceil and rceil delimiters are just vertical lines (no horizontal "flanges"). Anyone else seeing that? Paul -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: CMake on Windows
Am Thu, 21 Jan 2021 18:26:38 +0100 schrieb Thibaut Cuvelier : > Dear list, and Pavel mostly :) > > I'm starting again to configure LyX on Windows, and the CMake files do not > behave as > expected. > > I am setting -DLYX_DEPENDENCIES_DOWNLOAD=1 on the command line, but this is > what it > outputs: > > "C:\Program Files\JetBrains\CLion\bin\cmake\win\bin\cmake.exe" > -DCMAKE_BUILD_TYPE=Debug > -DLYX_DEPENDENCIES_DOWNLOAD=1 -G "CodeBlocks - NMake Makefiles" > D:\Thibaut\LyX -- > TOP_SRC_DIR = D:/Thibaut/LyX -- > -- Building out-of-source > -- Selecting build type defaults from configure.ac > -- ERROR: Could NOT find GNUWIN32, please set GNUWIN32_DIR > -- ERROR: or let cmake download all required files by using > -DLYX_DEPENDENCIES_DOWNLOAD=1 CMake Error at > development/cmake/modules/FindGNUWIN32.cmake:43 (message): Call Stack (most > recent call > first): development/cmake/modules/LyXPaths.cmake:57 (find_package) > CMakeLists.txt:251 (include) > > It really looks like the parameter I set is disregarded (as if the check is > done before > any downloading can happen). My CMake skills do not allow me to debug this > thoroughly… > > Moreover, the variables MSVC14 and MSVC10 are discouraged since CMake 3.8: > https://cmake.org/cmake/help/v3.8/variable/MSVC14.html. Plus, the same set of > dependencies can be used for Visual C++ 2017 and 2019, which the current code > cannot do > (and there are no more MSVC variables for these). I am joining a patch to > switch to the > now recommended MSVC_VERSION. It is untested due to the above issue. Since the FindGNUWIN32 is called form development/cmake/modules/LyXPaths.cmake and this is called from CMakeLists.txt:251, it is no wonder, that LYX_DEPENDENCIES_DOWNLOAD had no effect. (It is used at CMakeLists.txt:312, (means later)). Kornel pgpid2OKFVmDw.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
On Thu, Jan 21, 2021 at 10:06:27AM -0500, Scott Kostyshak wrote: > On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote: > > Yes, this is expected, since system libQt5*.so are dependent on libstdc++ > > (assuming you haven't rebuild Qt with libc++). ldd displays all required > > libraries, not only the ones that directly used by the application. > > Ah that makes sense. Thanks. It seems I can use "readelf -d" to show only > direct dependencies. [1] For those of you hanging on the edge of your seat, I rebuilt and checked with "readelf -d" and indeed libstd++ does not show up. Thanks for solving the mystery, Yuriy. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
CMake on Windows
Dear list, and Pavel mostly :)
I'm starting again to configure LyX on Windows, and the CMake files do not
behave as expected.
I am setting -DLYX_DEPENDENCIES_DOWNLOAD=1 on the command line, but this is
what it outputs:
"C:\Program Files\JetBrains\CLion\bin\cmake\win\bin\cmake.exe"
-DCMAKE_BUILD_TYPE=Debug -DLYX_DEPENDENCIES_DOWNLOAD=1 -G "CodeBlocks -
NMake Makefiles" D:\Thibaut\LyX
-- TOP_SRC_DIR = D:/Thibaut/LyX
--
-- Building out-of-source
-- Selecting build type defaults from configure.ac
-- ERROR: Could NOT find GNUWIN32, please set GNUWIN32_DIR
-- ERROR: or let cmake download all required files by using
-DLYX_DEPENDENCIES_DOWNLOAD=1
CMake Error at development/cmake/modules/FindGNUWIN32.cmake:43 (message):
Call Stack (most recent call first):
development/cmake/modules/LyXPaths.cmake:57 (find_package)
CMakeLists.txt:251 (include)
It really looks like the parameter I set is disregarded (as if the check is
done before any downloading can happen). My CMake skills do not allow me to
debug this thoroughly…
Moreover, the variables MSVC14 and MSVC10 are discouraged since CMake 3.8:
https://cmake.org/cmake/help/v3.8/variable/MSVC14.html. Plus, the same set
of dependencies can be used for Visual C++ 2017 and 2019, which the current
code cannot do (and there are no more MSVC variables for these). I am
joining a patch to switch to the now recommended MSVC_VERSION. It is
untested due to the above issue.
Index: CMakeLists.txt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt (revision d81673ecf0836b77fb7ddd38f6eaceddc1511581)
+++ b/CMakeLists.txt (date 1611238973381)
@@ -311,12 +311,12 @@
if(LYX_DEPENDENCIES_DOWNLOAD)
message(STATUS)
- if(MSVC14)
+ if(MSVC_VERSION GREATER_EQUAL 1900)
set(LYX_DEPENDENCIES_DIR ${TOP_BINARY_DIR}/msvc2015-deps)
set(deps_files lyx-windows-deps-msvc2015.zip)
set(deps_server http://ftp.lyx.de/LyX-Windows-Deps)
set(GNUWIN32_DIR ${LYX_DEPENDENCIES_DIR}/lyx-windows-deps-msvc2015)
- elseif(MSVC10)
+ elseif(MSVC_VERSION EQUAL 1600)
set(LYX_DEPENDENCIES_DIR ${TOP_BINARY_DIR}/msvc2010-deps)
set(deps_files lyx-windows-deps-msvc2010.zip)
set(deps_server http://ftp.lyx.de/LyX-Windows-Deps)
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Feature request (show correct graphics page in multipage pdf)
On Thu, Jan 21, 2021 at 11:38:25AM -0500, Neal Becker wrote: > In inserted graphics, we can select a page from a multi-page pdf using > "latex and lyx options". This will show the correct graphics in the > pdf output. But the preview always shows page 1. Would be nice to > implement something to fix the preview. Agreed. This is annoying. It's reported here (by a younger Neal :): https://www.lyx.org/trac/ticket/9039 I think we need to make a new copier variable to fix it. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Feature request (show correct graphics page in multipage pdf)
In inserted graphics, we can select a page from a multi-page pdf using "latex and lyx options". This will show the correct graphics in the pdf output. But the preview always shows page 1. Would be nice to implement something to fix the preview. -- Those who don't understand recursion are doomed to repeat it -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Patches to review
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote:
> diff --git a/src/frontends/qt/DockView.h b/src/frontends/qt/DockView.h
> index 9c3a9e7460..1e7bd5f2db 100644
> --- a/src/frontends/qt/DockView.h
> +++ b/src/frontends/qt/DockView.h
> @@ -36,7 +36,7 @@ public:
>Qt::DockWidgetArea area = Qt::LeftDockWidgetArea, ///<
> Position of
>
>///the dock (and
>
>///also drawer)
> - Qt::WindowFlags flags = 0);
> + Qt::WindowFlags flags = {});
Not part of your changes but the weird 3 line comment above could be just
single line
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Patches to review
On Thu, Jan 21, 2021 at 09:51:46AM -0500, Scott Kostyshak wrote: > On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote: > > Please review my recent patches for LyX. > > Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class. > > Patch 4 also looks good. I thought it could break Qt 4.8 compilation but > that's not the case [1, 2]. > > Sorry that I don't know enough to look at the others. 2,3 is fine. 5 is fine unless we use direct [] access somewhere. I know Riki did not announce it officially yet, but we should start looking at fixing bugs which hinder us from 2.4 release rather than refactoring the codebase. I know, boring... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [PATCH] Patches to review
Le 21/01/2021 à 08:38, Yuriy Skalko a écrit :
Please review my recent patches for LyX.
Concerning patch 1 and 5: what guideline do you use for using vector vs
list. The patches look good, I am just wondering.
Concerning patch 4: what does the replacement of 0 or nullptr by {} bring?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Add move constructor and move assignment operator for FileName class
On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote: > > > > I've tried to reproduce on Linux with Clang and libc++ but cannot. > > However, one thing that I do not understand is that in the output from > > ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this > > expected? > > > > Scott > > > > linux-vdso.so.1 (0x7ffd059e5000) > > libmythes-1.2.so.0 => /lib/x86_64-linux-gnu/libmythes-1.2.so.0 > > (0x7f990dad1000) > > libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 > > (0x7f990d993000) > > libQt5X11Extras.so.5 => > > /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x7f990d98c000) > > libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 > > (0x7f990d962000) > > libenchant-2.so.2 => /lib/x86_64-linux-gnu/libenchant-2.so.2 > > (0x7f990d954000) > > libmagic.so.1 => /lib/x86_64-linux-gnu/libmagic.so.1 > > (0x7f990d92c000) > > libQt5Concurrent.so.5 => > > /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 (0x7f990d921000) > > libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 > > (0x7f990d8c5000) > > libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 > > (0x7f990d229000) > > libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 > > (0x7f990cb71000) > > libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 > > (0x7f990c633000) > > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f990c616000) > > libc++.so.1 => /lib/x86_64-linux-gnu/libc++.so.1 > > (0x7f990c54e000) > > libc++abi.so.1 => /lib/x86_64-linux-gnu/libc++abi.so.1 > > (0x7f990c516000) > > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f990c3c7000) > > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > > (0x7f990c3ac000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f990c1c2000) > > /lib64/ld-linux-x86-64.so.2 (0x7f990dafb000) > > libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 > > (0x7f990bfe1000) > > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f990bfd9000) > > libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 > > (0x7f990bfd3000) > > libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 > > (0x7f990bfcb000) > > libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 > > (0x7f990bfc5000) > > libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 > > (0x7f990be93000) > > liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 > > (0x7f990be6a000) > > libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 > > (0x7f990be55000) > > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > > (0x7f990be33000) > > libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f990bdab000) > > libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 > > (0x7f990bd72000) > > libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 > > (0x7f990bc91000) > > libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 > > (0x7f990bc7d000) > > libdouble-conversion.so.3 => > > /lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7f990bc65000) > > libicui18n.so.67 => /lib/x86_64-linux-gnu/libicui18n.so.67 > > (0x7f990b953000) > > libicuuc.so.67 => /lib/x86_64-linux-gnu/libicuuc.so.67 > > (0x7f990b767000) > > libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 > > (0x7f990b6e4000) > > libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 > > (0x7f990b614000) > > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f990b607000) > > libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 > > (0x7f990b5fd000) > > libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 > > (0x7f990b5e3000) > > libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 > > (0x7f990b57) > > libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 > > (0x7f990b4b8000) > > libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 > > (0x7f990b482000) > > libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 > > (0x7f990b3bf000) > > libgraphite2.so.3 => /lib/x86_64-linux-gnu/libgraphite2.so.3 > > (0x7f990b392000) > > libicudata.so.67 => /lib/x86_64-linux-gnu/libicudata.so.67 > > (0x7f9909879000) > > libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 > > (0x7f990986b000) > > libbrotlicommon.so.1 => > > /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x7f9909846000) > > > > Yes, this is expected, since system libQt5*.so are dependent on libstdc++ > (assuming you haven't rebuild Qt with libc++). ldd displays all required > libraries, not only the ones that directly used by the application. Ah that makes sense. Thanks. It seems I can use "readelf -d" to show only direct dependenci
Re: [PATCH] Patches to review
On Thu, Jan 21, 2021 at 09:38:08AM +0200, Yuriy Skalko wrote: > Please review my recent patches for LyX. Patch 1 (the Development.lyx patch) is good. Nice addition of the enum class. Patch 4 also looks good. I thought it could break Qt 4.8 compilation but that's not the case [1, 2]. Sorry that I don't know enough to look at the others. Scott [1] https://doc.qt.io/archives/qt-4.8/qt.html#MouseButton-enum [2] https://code.qt.io/cgit/qt/qtlocation.git/commit/?id=f3a34ce8890c68c04212eafa0ae2c9eeeb60b555 signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Am Donnerstag, dem 21.01.2021 um 13:45 +0100 schrieb Jean-Marc
Lasgouttes:
> Hmm, what about
> code = Color_background;
> or
> code = colorset.getFromLyXName("background"):
>
> I agree 100% that this needs thinking, but my point is that the
> ColorCode is more important for LyX than the name itself.
My point is saving in the document. We need
\color background
in the LyX header in order to dynamically assign the correct color (and
yes we do that via getFromLyXName).
We cannot save the color code, as we need to save it as string (to
catch both hexnames and semantic names)
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Le 21/01/2021 à 10:48, Jürgen Spitzmüller a écrit :
How would that work with semantic branch names (e.g. \color
background)? Semantic branch names are essential to support branches
properly in different color themes.
Also, how would you export semantic color names in LaTeX (e.g.
\textcolor{notefontcolor})? Exporting static rgb values strikes me like
a huge step backwards.
Hmm, what about
code = Color_background;
or
code = colorset.getFromLyXName("background"):
I agree 100% that this needs thinking, but my point is that the
ColorCode is more important for LyX than the name itself.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Am Donnerstag, dem 21.01.2021 um 10:41 +0100 schrieb Jean-Marc
Lasgouttes:
> Le 21/01/2021 à 09:55, Jürgen Spitzmüller a écrit :
> > Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
> > Lasgouttes:
> > > This is why IMO declaring a name for such colors is a mistake. An
> > > enum value generated on the fly would be enough.
> >
> > And where would you store and access these enum values?
>
> The color cache (is that ColorTable?) would give me one (that would
> be
> an extension of Color_Code) on request (code =
> colorCache.allocateColor("58bbF7")). The int value would be the id of
> the color in memory. When writing to file, one would get the rgb
> value
> and write that to file.
How would that work with semantic branch names (e.g. \color
background)? Semantic branch names are essential to support branches
properly in different color themes.
Also, how would you export semantic color names in LaTeX (e.g.
\textcolor{notefontcolor})? Exporting static rgb values strikes me like
a huge step backwards.
> Doesn't it feel a bit complicated?
No. After all, we only handle that internally.
>
> I agree though that with a loong running LyX instance (as some of
> our users have), the handling of allocation (and deallocation) of
> color
> may get more complicated. I have not thought a lot abpit it, but I
> suspect that there exists a data structure for that.
Coupling the color table to buffer seems the more sensible approach to
me.
>
> JMarc
>
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Le 21/01/2021 à 09:55, Jürgen Spitzmüller a écrit :
Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc
Lasgouttes:
This is why IMO declaring a name for such colors is a mistake. An
enum value generated on the fly would be enough.
And where would you store and access these enum values?
The color cache (is that ColorTable?) would give me one (that would be
an extension of Color_Code) on request (code =
colorCache.allocateColor("58bbF7")). The int value would be the id of
the color in memory. When writing to file, one would get the rgb value
and write that to file.
To me, as long as it does not get written to some file, a name is not
useful.
And the good thing about an int is that it fits perfectly well in our
current FontInfo scheme.
(BTW the name now is as unique as it gets, as it consists of the string
branch, a random integer which is assigned to the branchlist, and the
branch name)
Doesn't it feel a bit complicated?
I agree though that with a loong running LyX instance (as some of
our users have), the handling of allocation (and deallocation) of color
may get more complicated. I have not thought a lot abpit it, but I
suspect that there exists a data structure for that.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Am Donnerstag, dem 21.01.2021 um 09:55 +0100 schrieb Jürgen Spitzmüller: > Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc > Lasgouttes: > > This is why IMO declaring a name for such colors is a mistake. An > > enum value generated on the fly would be enough. > > And where would you store and access these enum values? > > (BTW the name now is as unique as it gets, as it consists of the > string > branch, a random integer which is assigned to the branchlist, and the > branch name) > > Jürgen Of course, this problem could be easily solved also in branch by using a color name "branch_" + branchname rather than just branchname (this doesn't solve the leaking though). Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Am Donnerstag, dem 21.01.2021 um 09:52 +0100 schrieb Jean-Marc Lasgouttes: > This is why IMO declaring a name for such colors is a mistake. An > enum value generated on the fly would be enough. And where would you store and access these enum values? (BTW the name now is as unique as it gets, as it consists of the string branch, a random integer which is assigned to the branchlist, and the branch name) Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Prevent branch background color from leaking out of the document
Le 21/01/2021 à 08:19, Jürgen Spitzmüller a écrit : BTW if you want to have fun, fire up LyX 2.3.x, define a new branch named "foreground" and see how all text (in all opened documents!) magically disappears. Amusing indeed :) This is why IMO declaring a name for such colors is a mistake. An enum value generated on the fly would be enough. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
