Re: [LyX/master] Fix table crash reported on Windows.

[Yu Jin]

Am Mo., 3. Juni 2024 um 06:00 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> On 6/2/24 23:07, Richard Kimberly Heck wrote:
> > commit 3e796c680a11593bd09433be22bec45dcfe0d7a7
> > Author: Richard Kimberly Heck
> > Date:   Sun Jun 2 14:12:23 2024 -0400
> >
> >  Fix table crash reported on Windows.
>
> I did not mean to commit this yet. But I am pretty sure it is right, so
> won't revert.
>

Deleting table rows/columns works as expected for me now.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows (?) Table Crash

[Yu Jin]

Am So., 2. Juni 2024 um 20:14 Uhr schrieb Richard Kimberly Heck:

> On 6/2/24 14:12, Yu Jin wrote:
>
> Thanks.
>
> The attached should fix it, I think.
>
Confirmed, your patch makes first column undeletable though:

[image: image.png] ->
[image: image.png]
And if I just put the cursor into "a" and click delete column nothing
happens at all.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows (?) Table Crash

[Yu Jin]

Am So., 2. Juni 2024 um 19:59 Uhr schrieb Richard Kimberly Heck:

> On 6/2/24 13:18, Udicoudco wrote:
> > On Sun, Jun 2, 2024 at 7:53 PM Richard Kimberly Heck wrote:
> >> On 6/2/24 12:35, Udicoudco wrote:
> >>> On Sun, Jun 2, 2024 at 7:32 PM Richard Kimberly Heck wrote:
>  We've had a report of the following sort of crash, or maybe assertion.
> 
>  Create a table. Mark more than half the rows or columns. Delete those
>  (using the toolbar button, but I doubt that matters). Boom.
> 
>  I cannot reproduce on Linux, but Eugene was able to reproduce on
>  Windows. Anyone else?
> >>> I can reproduce on Windows as well.
> >> Can you get a backtrace?
> > Here is the output when running with -dbg any from the point of
> > clicking the delete rows button:
> >
> > Undo.cpp (23b): +++ Creating new group c for buffer 02A164FFF720
> > frontends\qt\GuiApplication.cpp (6d8): cmd:  action: 362
> > [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> > BufferView.cpp (556): BufferView::dispatch: cmd:  action: 362
> > [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> > Buffer.cpp (b55): Buffer::dispatch: cmd:  action: 362
> > [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> > Cursor.cpp (30d): Cursor::dispatch: cmd:  action: 362
> > [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> >
> >   cursor:| anchor:
> >   inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
> > 02A163DE44B0 idx: 0 par: 0 pos: 0
> >   inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
> > 02A1640B77B0 idx: 5 par: 0 pos: 0
> >   selection: 1 boundary: 0
> >
> > Cursor.cpp (32c): Cursor::dispatch: cmd:  action: 362
> > [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> >
> >   cursor:| anchor:
> >   inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
> > 02A163DE44B0 idx: 0 par: 0 pos: 0
> >   inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
> > 02A1640B77B0 idx: 5 par: 0 pos: 0
> >   selection: 1 boundary: 0
> >
> > insets\InsetTabular.cpp (13bd): # InsetTabular::doDispatch: cmd:
> > action: 362 [tabular-feature]  arg: 'delete-row' x: 0 y: 0
> >cur:
> >   cursor:| anchor:
> >   inset: 02A163DE44B0 idx: 0 par: 0 pos: 0 | inset:
> > 02A163DE44B0 idx: 0 par: 0 pos: 0
> >   inset: 02A1640B77B0 idx: 12 par: 0 pos: 0 | inset:
> > 02A1640B77B0 idx: 5 par: 0 pos: 0
> >   selection: 1 boundary: 0
> >
> > Undo.cpp (152): Create undo element of group c
> > insets\InsetTabular.cpp (19d9): Feature: delete-row value:
> >   C:/Users/pc1/newfile14.lyx.emergency
> > support/os_win32.cpp (149): 
> > [~/newfile14.lyx.emergency]->>[~\newfile14.lyx.emergency]
> >
> > Is this what you meant (or is there a better way to backtrace)?
>
> That's helpful, but what I had in mind is the call stack at the time of
> the crash.
>

I have the callstack:

>
LyX.exe!std::_Vector_const_iterator>>::_Verify_offset(const
__int64 _Off) Line 122 C++

LyX.exe!std::_Vector_const_iterator>>::operator+=(const
__int64 _Off) Line 129 C++

LyX.exe!std::_Vector_iterator>>::operator+=(const
__int64 _Off) Line 310 C++

LyX.exe!std::_Vector_iterator>>::operator+(const
__int64 _Off) Line 316 C++
  LyX.exe!lyx::Tabular::deleteRow(unsigned __int64 row, const bool force)
Line 830 C++
  LyX.exe!lyx::InsetTabular::tabularFeatures(lyx::Cursor & cur,
lyx::Tabular::Feature feature, const std::string & value) Line 6783 C++
  LyX.exe!lyx::InsetTabular::tabularFeatures(lyx::Cursor & cur, const
std::string & argument) Line 6618 C++
  LyX.exe!lyx::InsetTabular::doDispatch(lyx::Cursor & cur, lyx::FuncRequest
& cmd) Line 5376 C++
  LyX.exe!lyx::Inset::dispatch(lyx::Cursor & cur, lyx::FuncRequest & cmd)
Line 355 C++
  LyX.exe!lyx::Cursor::dispatch(const lyx::FuncRequest & cmd0) Line 825 C++
  LyX.exe!lyx::frontend::GuiView::dispatchToBufferView(const
lyx::FuncRequest & cmd, lyx::DispatchResult & dr) Line 4388 C++
  LyX.exe!lyx::frontend::GuiView::dispatch(const lyx::FuncRequest & cmd,
lyx::DispatchResult & dr) Line 5130 C++
  LyX.exe!lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest &
cmd, lyx::DispatchResult & dr) Line 2284 C++
  LyX.exe!lyx::frontend::GuiApplication::dispatch(const lyx::FuncRequest &
cmd) Line 1577 C++
  LyX.exe!lyx::dispatch(const lyx::FuncRequest & action) Line 1490 C++
  LyX.exe!lyx::frontend::Action::action() Line 92 C++
  LyX.exe!lyx::frontend::Action::qt_static_metacall(QObject * _o,
QMetaObject::Call _c, int _id, void * * _a) Line 102 C++
  [External Code]
  LyX.exe!lyx::frontend::GuiApplication::notify(QObject * receiver, QEvent
* event) Line 3001 C++
  [External Code]
  LyX.exe!lyx::frontend::GuiApplication::notify(QObject * receiver, QEvent
* event) Line 3001 C++
  [External Code]
  LyX.exe!lyx::frontend::GuiApplication::exec() Line 2765 C++
  LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Line 377 C++
  LyX.exe!main(int argc, char * * argv) Line 55 C++
  [External Code]


>
> Still, I think I 

Re: [LyX/master] Wininstaller Qt6.7 changed file name

[Yu Jin]

Am So., 26. Mai 2024 um 10:08 Uhr schrieb Pavel Sanda:

> On Sun, May 26, 2024 at 07:35:16AM +, Eugene Chornyi wrote:
> > commit a6d0d7ea92b686fc102b05970830ee11fc51e47b
> > Author: Eugene Chornyi
> > Date:   Sun May 26 09:35:10 2024 +0200
> >
> > Wininstaller Qt6.7 changed file name
> > ---
> >  development/Win32/packaging/installer/src/main.nsh | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/development/Win32/packaging/installer/src/main.nsh
> b/development/Win32/packaging/installer/src/main.nsh
> > index b3713862d1..5062267720 100644
> > --- a/development/Win32/packaging/installer/src/main.nsh
> > +++ b/development/Win32/packaging/installer/src/main.nsh
> > @@ -629,7 +629,8 @@ Section -ProgramFiles
> >File "${FILES_QT}\bin\platforms\qwindows.dll"
> >
> >SetOutPath "$INSTDIR\bin\styles"
> > -  File "${FILES_QT}\bin\styles\qwindowsvistastyle.dll"
> > +  File /nonfatal "${FILES_QT}\bin\styles\qwindowsvistastyle.dll"
> > +  File /nonfatal "${FILES_QT}\bin\styles\qmodernwindowsstyle.dll"
>
> I guess it would make sense to document in INSTALL.Win32
> what combination of Qt and MSVC the build was tested and works?
>

I don't test every possible combination, I usually try to update to the
most recent versions, but the INSTALL.Win32 is still actual regarding the
instructions. This commit regards this line
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=INSTALL.Win32;h=796ed70de9c0be0ec25bf30645b16a9ad53d;hb=HEAD#l148

In the NSIS Script I just don't copy the whole folder recursively, because
there is also a ...d.dll (debug dll) and also might be a .pdb file
depending what exactly is chosen when installing Qt. I don't want those in
the Installer at the end so the individual file is copied.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.4.0 Tarballs

[Yu Jin]

Am So., 26. Mai 2024 um 04:46 Uhr schrieb Richard Kimberly Heck:

> Here:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Let's have a day or two of testing. Assuming all goes well, we can build
> tarballs early next week, and release at the end of the week.
>

Builds well on Windows except a small issue. Qt seems to have changed a
file name in styles. I have fixed it for the installer in master here
https://git.lyx.org/gitweb/?p=lyx.git;a=commit;h=a6d0d7ea92b686fc102b05970830ee11fc51e47b.
Need to push it to the 2.4.x branch as well but the tarballs don't have to
necessarily be rebuilt. Runs well too.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Fr., 24. Mai 2024 um 09:00 Uhr schrieb Kornel Benko:

> Am Thu, 23 May 2024 22:14:37 -0400
> schrieb Richard Kimberly Heck:
>
> > On 5/23/24 16:22, Yu Jin wrote:
> > > Am Do., 23. Mai 2024 um 22:06 Uhr schrieb Yu Jin:
> > >
> > > Am Do., 23. Mai 2024 um 10:05 Uhr schrieb Kornel Benko:
> > >
> > >     Am Wed, 22 May 2024 19:09:05 +0200
> > > schrieb Yu Jin:
> > > > It would be no problem for me, but I think that this still
> > > should be
> > > > addressed and solved.
> > > > Kornel, did you find anything useful in the output?
> > >
> > > No relevant differences. This implies (for me) that the
> > > created CMakeCache.txt files
> > > don't differ.
> > >
> > > Just checked to be sure, the CMakeCache.txt files are identical.
> > >
> > > So I have no idea, why the created project files could be
> > > different.
> > >
> > >
> > > I found the issue. SYSTEM_DATADIR is set
> > > (
> https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=CMakeLists.txt;h=228ef34a2e431e8b9be724eab05fdb09c13c5937;hb=HEAD#l537)
>
> > > before CMAKE_INSTALL_PREFIX is set
> > > (
> https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=CMakeLists.txt;h=228ef34a2e431e8b9be724eab05fdb09c13c5937;hb=HEAD#l573).
>
> > > Then metainfo file is installed into the wrong SYSTEM_DATADIR here
> > >
> https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=development/cmake/Install.cmake;h=a901942b4adb88e92cd9663f091c826db37a60fa;hb=HEAD#l191
> >
> > Good work! Do you have a patch?
> >
> > Riki
> >
>
> Eugene, could you try this?


Works and 2.4.x compiles successfully now.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Do., 23. Mai 2024 um 22:06 Uhr schrieb Yu Jin :

> Am Do., 23. Mai 2024 um 10:05 Uhr schrieb Kornel Benko:
>
>> Am Wed, 22 May 2024 19:09:05 +0200
>> schrieb Yu Jin:
>> > It would be no problem for me, but I think that this still should be
>> > addressed and solved.
>> > Kornel, did you find anything useful in the output?
>>
>> No relevant differences. This implies (for me) that the created
>> CMakeCache.txt files
>> don't differ.
>
>
> Just checked to be sure, the CMakeCache.txt files are identical.
>
>
>> So I have no idea, why the created project files could be different.
>
>
I found the issue. SYSTEM_DATADIR is set (
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=CMakeLists.txt;h=228ef34a2e431e8b9be724eab05fdb09c13c5937;hb=HEAD#l537)
before CMAKE_INSTALL_PREFIX is set (
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=CMakeLists.txt;h=228ef34a2e431e8b9be724eab05fdb09c13c5937;hb=HEAD#l573).
Then metainfo file is installed into the wrong SYSTEM_DATADIR here
https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=development/cmake/Install.cmake;h=a901942b4adb88e92cd9663f091c826db37a60fa;hb=HEAD#l191

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Do., 23. Mai 2024 um 10:05 Uhr schrieb Kornel Benko:

> Am Wed, 22 May 2024 19:09:05 +0200
> schrieb Yu Jin:
> > It would be no problem for me, but I think that this still should be
> > addressed and solved.
> > Kornel, did you find anything useful in the output?
>
> No relevant differences. This implies (for me) that the created
> CMakeCache.txt files
> don't differ.


Just checked to be sure, the CMakeCache.txt files are identical.


> So I have no idea, why the created project files could be different.


-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Mi., 22. Mai 2024 um 15:56 Uhr schrieb Pavel Sanda:

> On Thu, May 16, 2024 at 10:35:45PM +0200, Yu Jin wrote:
> > > > > You could check the value at CMakeLists.txt:575 (after being set on
> > > line 573).
> > > > > message(STATUS
> "CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}")
> > > > >
> > > > This is the output
> > > > CMAKE_INSTALL_PREFIX=LYX_INSTALLED
> > > > looks fine I guess.
> > >
> > > For me it looks wrong. (Should be full path).
> > >
> > > I am interested of the output when run the first time compared to run
> on
> > > second time.
> > >
> > Attached. Both runs in one file one after another.
> >
> > > Also are you compiling as bundle (I hope not)?
> > >
> > No.
>
> As I am not sensing anyone is heading towards investigating this
> what if we release with the windows instruction to simply run
> cmake twice?
>

It would be no problem for me, but I think that this still should be
addressed and solved.
Kornel, did you find anything useful in the output?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Do., 16. Mai 2024 um 21:57 Uhr schrieb Kornel Benko:

> Am Thu, 16 May 2024 21:08:55 +0200
> schrieb Yu Jin:
>
> > > I don't see it in linux though.
> > >
> > > You could check the value at CMakeLists.txt:575 (after being set on
> line 573).
> > > message(STATUS "CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}")
> > >
> > This is the output
> > CMAKE_INSTALL_PREFIX=LYX_INSTALLED
> > looks fine I guess.
>
> For me it looks wrong. (Should be full path).
>
> I am interested of the output when run the first time compared to run on
> second time.
>
Attached. Both runs in one file one after another.

> Also are you compiling as bundle (I hope not)?
>
No.
-- 
  Eugene
C:\lyx>"C:\Program Files\CMake\bin\cmake.exe" -S master -G "Visual Studio 17 
2022" -A x64 -DLYX_EXTERNAL_DTL=0 -DLYX_USE_QT=QT6 -DLYX_INSTALL=1 
-DGNUWIN32_DIR=C:\lyx\lyx-windows-deps-msvc2023_64 -DCMAKE_PREFIX_
PATH=C:\Qt\6.7.0\msvc2019_64 -B "C:\lyx\stablebuild64"
CMake Deprecation Warning at CMakeLists.txt:7 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


-- TOP_SRC_DIR = C:/lyx/master
--
-- Building out-of-source
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
-- The C compiler identification is MSVC 19.39.33523.0
-- The CXX compiler identification is MSVC 19.39.33523.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual 
Studio/2022/Community/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual 
Studio/2022/Community/VC/Tools/MSVC/14.39.33519/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Selecting build type defaults from configure.ac
-- Found GNUWIN32: C:\lyx\lyx-windows-deps-msvc2023_64
--
-- CXX11_FLAG_DETECTED = "/std:c++20"
-- Compiler supports std_regex
-- Found CXX11Compiler: /std:c++20
-- CMAKE_INSTALL_PREFIX=LYX_INSTALLED
-- CMAKE_CXX_STANDARD set to 20
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Found Threads: TRUE
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Could NOT find WrapVulkanHeaders (missing: Vulkan_INCLUDE_DIR)
-- Found Qt-Version 6.7.0
-- Looking for magic_file
-- Looking for magic_file - not found
-- Function magic_file not found
-- Looking for magic_open
-- Looking for magic_open - not found
-- Function magic_open not found
-- Looking for magic_load
-- Looking for magic_load - not found
-- Function magic_load not found
-- Looking for magic_close
-- Looking for magic_close - not found
-- Function magic_close not found
-- Looking for magic_error
-- Looking for magic_error - not found
-- Function magic_error not found
-- Could NOT find Magic (missing: Magic_INCLUDE_DIR Magic_LIBRARY 
HAS_MAGIC_FUNCTIONS)
CMake Deprecation Warning at 3rdparty/mythes/CMakeLists.txt:1 
(cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


CMake Deprecation Warning at 3rdparty/hunspell/CMakeLists.txt:2 
(cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


--   * Hunspell:
--  - include: 
C:/lyx/master/3rdparty/hunspell/1.7.0/src/hunspell;C:/lyx/master/3rdparty/hunspell/1.7.0/src
--  - library: hunspell
-- Could NOT find ASPELL (missing: ASPELL_LIBRARY ASPELL_INCLUDE_DIR)
-- ASPELL not found, building without ASPELL support
-- Could NOT find ENCHANT (missing: ENCHANT_LIBRARY ENCHANT_INCLUDE_DIR)
-- ENCHANT not found, building without ENCHANT support
-- Building with USE_HUNSPELL
-- Could NOT find LYX_PY_polib (missing: LYX_PY_POLIB)
-- You will be unable to update layouttranslations file
CMake Deprecation Warning at 3rdparty/libiconv/CMakeLists.txt:8 
(cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION a

Re: metainfo wrong target dir?

[Yu Jin]

Am Do., 16. Mai 2024 um 11:30 Uhr schrieb Kornel Benko:

> Am Wed, 15 May 2024 17:00:28 +0200
> schrieb Yu Jin:
>
> > Am Di., 14. Mai 2024 um 20:21 Uhr schrieb Pavel Sanda:
> >
> > > On Tue, May 14, 2024 at 06:16:49PM +0200, Yu Jin wrote:
> > > > Why does it try to install that file into my Program Files dir and
> not
> > > into
> > > > CMAKE_INSTALL_PREFIX?
> > >
> > > I do not know, but this file is part of linux infrastructure and can be
> > > dropped
> > > completely from windows.
> >
> >
> > Strange thing is that the cmake_install.cmake file contains the code part
> > sent by me earlier only on the first CMake configure run into an empty
> > directory. When I reconfigure the code part is not present anymore and I
> > don't get the error message. So how to fix it?
>
> Looks like CMAKE_INSTALL_PREFIX is used (from cmake default) before set by
> CMakeLists.txt.
> On second run the correct value is used from cache.
>

On the second run this whole part in cmake_install.cmake

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT
CMAKE_INSTALL_COMPONENT)
  list(APPEND CMAKE_ABSOLUTE_DESTINATION_FILES
   "C:/Program Files/LyX/metainfo/org.lyx.LyX.metainfo.xml")
  if(CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION)
message(WARNING "ABSOLUTE path INSTALL DESTINATION :
${CMAKE_ABSOLUTE_DESTINATION_FILES}")
  endif()
  if(CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION)
message(FATAL_ERROR "ABSOLUTE path INSTALL DESTINATION forbidden (by
caller): ${CMAKE_ABSOLUTE_DESTINATION_FILES}")
  endif()
  file(INSTALL DESTINATION "C:/Program Files/LyX/metainfo" TYPE FILE FILES
"C:/lyx/master/lib/org.lyx.LyX.metainfo.xml")
endif()

becomes this

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT
CMAKE_INSTALL_COMPONENT)
  file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/LYX_INSTALLED/metainfo"
TYPE FILE FILES "C:/lyx/master/lib/org.lyx.LyX.metainfo.xml")
endif()


> I don't see it in linux though.
>
> You could check the value at CMakeLists.txt:575 (after being set on line
> 573).
> message(STATUS "CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}")
>

This is the output
CMAKE_INSTALL_PREFIX=LYX_INSTALLED
looks fine I guess.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: TESTING Tarballs for 2.4.0

[Yu Jin]

Am Mi., 15. Mai 2024 um 12:17 Uhr schrieb Kornel Benko:

> Am Tue, 14 May 2024 18:34:50 +0200
> schrieb Yu Jin:
>
> > Am Di., 14. Mai 2024 um 17:54 Uhr schrieb Kornel Benko:
> >
>
> ...
>
> > > Corrected at 5eaa03a1, sorry.
> > >
> >
> > Well, the 2.4.x branch still does not compile:
> >
> > Build started at 18:30...
> > 1>-- Build started: Project: support (applications\LyX\support),
> > Configuration: Debug x64 --
> > 1>ConsoleApplication.cpp
> > 1>Package.cpp
> > 1>C:\lyx\master\src\support\Package.cpp(553,29): error C2065:
> > 'LYX_DIR_VER': undeclared identifier
> > 1>C:\lyx\master\src\support\Package.cpp(556,46): error C2065:
> > 'LYX_DIR_VER': undeclared identifier
> > 1>C:\lyx\master\src\support\Package.cpp(650,47): error C2065:
> > 'LYX_DIR_VER': undeclared identifier
> > 1>C:\lyx\master\src\support\Package.cpp(666,31): error C2065:
> > 'LYX_USERDIR_VER': undeclared identifier
> > 1>PathChanger.cpp
> > 1>gzstream.cpp
> > 1>C:\lyx\master\src\support\gzstream.cpp(92,19): warning C4244:
> > 'initializing': conversion from '__int64' to 'int', possible loss of data
> > 1>C:\lyx\master\src\support\gzstream.cpp(113,11): warning C4244:
> > 'initializing': conversion from '__int64' to 'int', possible loss of data
> > 1>gettext.cpp
> > 1>Generating Code...
> > 1>Done building project "support.vcxproj" -- FAILED.
> > == Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped
> ==
> > == Build completed at 18:30 and took 03,018 seconds ==
> >
> > or here
> >
> > Build started at 18:33...
> > 1>-- Build started: Project: LyX (applications\LyX\LyX),
> Configuration:
> > Debug x64 --
> > 1>version.cpp
> > 1>C:\lyx\master\src\version.cpp(25,38): error C2065: 'NOTFOUND':
> undeclared
> > identifier
> > 1>C:\lyx\master\src\version.cpp(26,38): error C2065: 'NOTFOUND':
> undeclared
> > identifier
> > 1>Done building project "LyX.vcxproj" -- FAILED.
> > == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
> ==
> > == Build completed at 18:33 and took 00,368 seconds ==
> >
> > not sure why it says NOTFOUND here, line 25 and 26 are actually:
> >
> > extern const int lyx_version_major = LYX_MAJOR_VERSION;
> > extern const int lyx_version_minor = LYX_MINOR_VERSION;
> >
> > Those definitions are not found though.
> >
>
> Thanks for the report. After the amend at 8edc87b6 these errors should go
> too.
>

Confirmed, now only the issue with the metainfo file remains.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: metainfo wrong target dir?

[Yu Jin]

Am Di., 14. Mai 2024 um 20:21 Uhr schrieb Pavel Sanda:

> On Tue, May 14, 2024 at 06:16:49PM +0200, Yu Jin wrote:
> > Why does it try to install that file into my Program Files dir and not
> into
> > CMAKE_INSTALL_PREFIX?
>
> I do not know, but this file is part of linux infrastructure and can be
> dropped
> completely from windows.


Strange thing is that the cmake_install.cmake file contains the code part
sent by me earlier only on the first CMake configure run into an empty
directory. When I reconfigure the code part is not present anymore and I
don't get the error message. So how to fix it?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: TESTING Tarballs for 2.4.0

[Yu Jin]

Am Mo., 13. Mai 2024 um 23:49 Uhr schrieb Richard Kimberly Heck:

> Hi, all,
>
> Tarballs for 2.4.0 are here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please test. Please let me know if I forgot to do or include anything.
>
> Hold off on binaries for now.
>

Also see this
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg221762.html
affects the 2.4.x branch aswell, so I guess will need to be fixed too
before rebuild of the tarballs.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: TESTING Tarballs for 2.4.0

[Yu Jin]

Am Di., 14. Mai 2024 um 17:54 Uhr schrieb Kornel Benko:

> Am Tue, 14 May 2024 17:41:46 +0200
> schrieb Yu Jin:
>
> > Am Mo., 13. Mai 2024 um 23:49 Uhr schrieb Richard Kimberly Heck:
> >
> > > Hi, all,
> > >
> > > Tarballs for 2.4.0 are here:
> > >
> > >  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
> > >
> > > Please test. Please let me know if I forgot to do or include anything.
> > >
> > > Hold off on binaries for now.
> > >
> >
> > Cmake fails, I get this error
> >
> > C:\lyx>"C:\Program Files\CMake\bin\cmake.exe" -S lyx-2.4.0 -G "Visual
> > Studio 17 2022" -A x64 -DLYX_EXTERNAL_DTL=0 -DLYX_USE_QT=QT6
> > -DLYX_INSTALL=1 -DLYX_CONSOLE=0
> > -DGNUWIN32_DIR=C:\lyx\lyx-windows-deps-msvc2023_64
> > -DCMAKE_PREFIX_PATH=C:\Qt\6.7.0\msvc2019_64 -B
> "C:\lyx\lyx-2.4.0-build-64"
> > CMake Deprecation Warning at CMakeLists.txt:7 (cmake_minimum_required):
> >   Compatibility with CMake < 3.5 will be removed from a future version of
> >   CMake.
> >
> >   Update the VERSION argument  value or use a ... suffix to
> tell
> >   CMake that the project does not need compatibility with older versions.
> >
> >
> > -- TOP_SRC_DIR = C:/lyx/lyx-2.4.0
> > --
> > -- Building out-of-source
> > -- Selecting Windows SDK version 10.0.22621.0 to target Windows
> 10.0.22631.
> > CMake Error at development/cmake/modules/LyXMacros.cmake:466 (message):
> >   "C:/lyx/lyx-2.4.0/configure.ac": Unable to determine build-type from
> > suffix
> >   "" in AC_INIT macro
> > Call Stack (most recent call first):
> >   CMakeLists.txt:120 (determineversionandbuildtype)
> >
> >
> > -- Configuring incomplete, errors occurred!
> >
> >
>
> Corrected at 5eaa03a1, sorry.
>

Well, the 2.4.x branch still does not compile:

Build started at 18:30...
1>-- Build started: Project: support (applications\LyX\support),
Configuration: Debug x64 --
1>ConsoleApplication.cpp
1>Package.cpp
1>C:\lyx\master\src\support\Package.cpp(553,29): error C2065:
'LYX_DIR_VER': undeclared identifier
1>C:\lyx\master\src\support\Package.cpp(556,46): error C2065:
'LYX_DIR_VER': undeclared identifier
1>C:\lyx\master\src\support\Package.cpp(650,47): error C2065:
'LYX_DIR_VER': undeclared identifier
1>C:\lyx\master\src\support\Package.cpp(666,31): error C2065:
'LYX_USERDIR_VER': undeclared identifier
1>PathChanger.cpp
1>gzstream.cpp
1>C:\lyx\master\src\support\gzstream.cpp(92,19): warning C4244:
'initializing': conversion from '__int64' to 'int', possible loss of data
1>C:\lyx\master\src\support\gzstream.cpp(113,11): warning C4244:
'initializing': conversion from '__int64' to 'int', possible loss of data
1>gettext.cpp
1>Generating Code...
1>Done building project "support.vcxproj" -- FAILED.
== Build: 0 succeeded, 1 failed, 2 up-to-date, 0 skipped ==
== Build completed at 18:30 and took 03,018 seconds ==

or here

Build started at 18:33...
1>-- Build started: Project: LyX (applications\LyX\LyX), Configuration:
Debug x64 --
1>version.cpp
1>C:\lyx\master\src\version.cpp(25,38): error C2065: 'NOTFOUND': undeclared
identifier
1>C:\lyx\master\src\version.cpp(26,38): error C2065: 'NOTFOUND': undeclared
identifier
1>Done building project "LyX.vcxproj" -- FAILED.
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
== Build completed at 18:33 and took 00,368 seconds ==

not sure why it says NOTFOUND here, line 25 and 26 are actually:

extern const int lyx_version_major = LYX_MAJOR_VERSION;
extern const int lyx_version_minor = LYX_MINOR_VERSION;

Those definitions are not found though.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

metainfo wrong target dir?

[Yu Jin]

Hi,
I get this error on the current master when building the INSTALL
CMakeTarget.

29>CMake Error at cmake_install.cmake:3953 (file):
29>  file cannot create directory: C:/Program Files (x86)/LyX/metainfo.
Maybe
29>  need administrative privileges.
29>
29>
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: The command "setlocal
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P
cmake_install.cmake
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: if %errorlevel% neq 0 goto :cmEnd
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: :cmEnd
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: :cmErrorLevel
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: exit /b %1
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: :cmDone
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: if %errorlevel% neq 0 goto :VCEnd
29>C:\Program Files\Microsoft Visual
Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(166,5):
error MSB3073: :VCEnd" exited with code 1.

Code in cmake_install.cmake:

if(CMAKE_INSTALL_COMPONENT STREQUAL "Unspecified" OR NOT
CMAKE_INSTALL_COMPONENT)
  list(APPEND CMAKE_ABSOLUTE_DESTINATION_FILES
   "C:/Program Files (x86)/LyX/metainfo/org.lyx.LyX.metainfo.xml")
  if(CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION)
message(WARNING "ABSOLUTE path INSTALL DESTINATION :
${CMAKE_ABSOLUTE_DESTINATION_FILES}")
  endif()
  if(CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION)
message(FATAL_ERROR "ABSOLUTE path INSTALL DESTINATION forbidden (by
caller): ${CMAKE_ABSOLUTE_DESTINATION_FILES}")
  endif()
  file(INSTALL DESTINATION "C:/Program Files (x86)/LyX/metainfo" TYPE FILE
FILES "C:/lyx/master/lib/org.lyx.LyX.metainfo.xml")
endif()

Why does it try to install that file into my Program Files dir and not into
CMAKE_INSTALL_PREFIX?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: TESTING Tarballs for 2.4.0

[Yu Jin]

Am Mo., 13. Mai 2024 um 23:49 Uhr schrieb Richard Kimberly Heck:

> Hi, all,
>
> Tarballs for 2.4.0 are here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please test. Please let me know if I forgot to do or include anything.
>
> Hold off on binaries for now.
>

Cmake fails, I get this error

C:\lyx>"C:\Program Files\CMake\bin\cmake.exe" -S lyx-2.4.0 -G "Visual
Studio 17 2022" -A x64 -DLYX_EXTERNAL_DTL=0 -DLYX_USE_QT=QT6
-DLYX_INSTALL=1 -DLYX_CONSOLE=0
-DGNUWIN32_DIR=C:\lyx\lyx-windows-deps-msvc2023_64
-DCMAKE_PREFIX_PATH=C:\Qt\6.7.0\msvc2019_64 -B "C:\lyx\lyx-2.4.0-build-64"
CMake Deprecation Warning at CMakeLists.txt:7 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


-- TOP_SRC_DIR = C:/lyx/lyx-2.4.0
--
-- Building out-of-source
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.22631.
CMake Error at development/cmake/modules/LyXMacros.cmake:466 (message):
  "C:/lyx/lyx-2.4.0/configure.ac": Unable to determine build-type from
suffix
  "" in AC_INIT macro
Call Stack (most recent call first):
  CMakeLists.txt:120 (determineversionandbuildtype)


-- Configuring incomplete, errors occurred!


-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.8 Tarballs

[Yu Jin]

Am Do., 2. Mai 2024 um 22:48 Uhr schrieb Richard Kimberly Heck:

> Here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>
> Please check that they build and run properly, especially export to and
> from 2.4.x.
>
> When we've verified all is well, I'll give the signal to build binaries
> for real.
>

Works on Windows.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.8 Ready To Go?

[Yu Jin]

Am Do., 2. Mai 2024 um 16:55 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> Just double checking that all issues there have been resolved. If so,
> I'll build the tarballs.
>

Check for Windows .
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Mi., 1. Mai 2024 um 18:53 Uhr schrieb Jean-Marc Lasgouttes:

> Le 01/05/2024 à 17:50, Yu Jin a écrit :
> > You are right, simply adding
> > #include 
> > to Format.cpp resolves the errors.
>
> Great!
>

May I push it into the 2.3.x branch?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Mi., 1. Mai 2024 um 13:36 Uhr schrieb Jean-Marc Lasgouttes:

> Le 01/05/2024 à 13:32, Jean-Marc Lasgouttes a écrit :
> > Le 01/05/2024 à 11:54, Yu Jin a écrit :
> >> 2.4 compiles with c++20 standard. The Problem with 2.3 are the
> >> "unary_function"s, which seem to require c++11(?) and as far as I can
> >> see the current Visual Studio just can not do that, c++14 is minimum.
> >
> > Reading this:
> >https://en.cppreference.com/w/cpp/utility/functional/unary_function
> > I would think that it works with C++14 and was remove din C++17 only.
>
> Actually, the function is in , which is not included in
> Format.cpp.
>
>
> https://learn.microsoft.com/en-us/answers/questions/1348183/std-binary-function-is-missing-in-msvc-14-37-32822


You are right, simply adding
#include 
to Format.cpp resolves the errors.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Fr., 19. Apr. 2024 um 11:00 Uhr schrieb Kornel Benko :

> Am Thu, 18 Apr 2024 16:43:25 +0200
> schrieb Pavel Sanda:
>
> > On Wed, Apr 17, 2024 at 09:22:34AM +0200, Kornel Benko wrote:
> > > Am Tue, 16 Apr 2024 15:54:26 +0200
> > > schrieb Yu Jin:
> > >
> > > > > Alternatively you can try setting CMAKE_CXX_STANDARD directly.
> > > > > Like in CMakeLists.txt:646
> > > > > -if(NOT MSVC)
> > > > > +if (MSVC)
> > > > > +   set(CMAKE_CXX_STANDARD 11)
> > > > > +else()
> > > > >
> > > > > Since I cannot test for MSVC, it is untested.
> > > > >
> > > > Does not seem to do anything, the standard set in Visual Studio is
> still "Default
> > > > (C++14)" and still the same error occurs.
> > > >
> > >
> > > Sorry Eugene, I would try to check for diff of the used cxx parameters
> in lyx2.3 and
> > > lyx2.5 compilation. Other than that, I am out of suggestions.
> >
> > If we run out of ideas how to compile 2.3 with the current win compilers,
> > how hard or complex patches would be backporting compilation fixes
> present
> > in 2.4?
> >
> > Pavel
>
> Looks like not so easy. The changes in are
> development/cmake/modules/LyXMacros.cmake: easy managable
> development/cmake/modules/FindCXX11Compiler.cmake: looks not
> difficult
> CMakeLists.txt: Huge
>
> If Eugene is able to compile lyx2.4 with qt5

Yes I am.

> then I'd still like to know the
> differences of the used cxx parameters.

2.4 compiles with c++20 standard. The Problem with 2.3 are the
"unary_function"s, which seem to require c++11(?) and as far as I can see
the current Visual Studio just can not do that, c++14 is minimum.

> Seems easier to make a patch then (at least for
> Eugene's compiler)

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Di., 16. Apr. 2024 um 14:14 Uhr schrieb Kornel Benko:

> Am Fri, 12 Apr 2024 21:50:28 +0200
> schrieb Yu Jin:
>
> > Am Fr., 12. Apr. 2024 um 09:56 Uhr schrieb Kornel Benko:
> >
> > > Am Thu, 11 Apr 2024 17:13:20 +0200
> > > schrieb Yu Jin:
> > >
> > > > Am Do., 11. Apr. 2024 um 10:17 Uhr schrieb Kornel Benko:
> > > >
> > > > > Am Wed, 10 Apr 2024 21:02:40 +0200
> > > > > schrieb Yu Jin:
> > > > >
> > >
> > > [snip]
> > >
> > > > > Please check ./development/cmake/modules/LyXMacros.cmake:471
> > > > >
> > > >
> > > > On the 2.3.x branch there LyXMacros.cmake file only contains  403
> lines.
> > > >
> > >
> > >
> > > I completely forgot the 2.3 branch.
> > >
> > > Please check development/cmake/modules/FindCXX11Compiler.cmake:47
> > > and set CXX11_FLAG_CANDIDATES appropriate.
> > > (You may also look at
> > > # git log development/cmake/modules/FindCXX11Compiler.cmake
> > > in lyx2.4 for changes prior to 2ec243d47)
> >
> >
> > I either don't understand what I need to do or it does not help either. I
> > put "--std=c++11" in there but it did not help, still the same error.
>
> Alternatively you can try setting CMAKE_CXX_STANDARD directly.
> Like in CMakeLists.txt:646
> -if(NOT MSVC)
> +if (MSVC)
> +   set(CMAKE_CXX_STANDARD 11)
> +else()
>
> Since I cannot test for MSVC, it is untested.
>

Does not seem to do anything, the standard set in Visual Studio is still
"Default (C++14)" and still the same error occurs.


-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Fr., 12. Apr. 2024 um 09:56 Uhr schrieb Kornel Benko :

> Am Thu, 11 Apr 2024 17:13:20 +0200
> schrieb Yu Jin:
>
> > Am Do., 11. Apr. 2024 um 10:17 Uhr schrieb Kornel Benko:
> >
> > > Am Wed, 10 Apr 2024 21:02:40 +0200
> > > schrieb Yu Jin:
> > >
>
> [snip]
>
> > > Please check ./development/cmake/modules/LyXMacros.cmake:471
> > >
> >
> > On the 2.3.x branch there LyXMacros.cmake file only contains  403 lines.
> >
>
>
> I completely forgot the 2.3 branch.
>
> Please check development/cmake/modules/FindCXX11Compiler.cmake:47
> and set CXX11_FLAG_CANDIDATES appropriate.
> (You may also look at
> # git log development/cmake/modules/FindCXX11Compiler.cmake
> in lyx2.4 for changes prior to 2ec243d47)


I either don't understand what I need to do or it does not help either. I
put "--std=c++11" in there but it did not help, still the same error.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Do., 11. Apr. 2024 um 10:17 Uhr schrieb Kornel Benko :

> Am Wed, 10 Apr 2024 21:02:40 +0200
> schrieb Yu Jin :
>
> > Am Mi., 10. Apr. 2024 um 16:02 Uhr schrieb Jean-Marc Lasgouttes :
> >
> > > Le 09/04/2024 à 06:30, Yu Jin a écrit :
> > > > Normally, unary_function and binary_function only disappeared in
> > > C++17.
> > > > Does C++14 work?
> > > >
> > > > Unfortunately not.
> > >
> > > Do you select the C++ level in Visual Studio or in cmake?
> > >
> >
> > I don't see any option in CMake regarding c++ level, I just execute
> > configure and as far as I can see it does not set any explicit c++ level
> > and default in the current Visual Studio is c++14 and there seems no way
> to
> > use c++11.
> >
> https://developercommunity.visualstudio.com/t/Need-C11-in-visual-studio-not-C11-or/10081597?space=8=idea=visualizer
> > Manually setting '/std:c++11' command line switch also does not work, it
> > actually says that this switch is unknown and will be ignored -> so again
> > c++14 is used. And installing an older Visual Studio (Community) is also
> > not an option, because Microsoft does not offer that (only Professional
> and
> > Enterprise), so rip lyX 2.3.8 on Windows I guess, unless someone decides
> to
> > cross compile it using MinGW or so.
>
>
> Please check ./development/cmake/modules/LyXMacros.cmake:471
>

On the 2.3.x branch there LyXMacros.cmake file only contains  403 lines.

In the function lyxgetknowncmakestd() we use the info from cmake to get the
> correct c++
> level (if the cmake version >= 3.9)
>

On the 2.3.x branch I can't find any "lyxgetknowncmakestd".
I have CMake 3.28.0

>
> OTOH, if your cmake version is less 3.9, we try to check for 98, 11 and 14.
> If that is the case for you, you could select your own values.
>


-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Dictionaries in Win installer (was: LyX 2.4.0 & Jupyter Notebooks)

[Yu Jin]

Am Mi., 10. Apr. 2024 um 23:38 Uhr schrieb Pavel Sanda:

> On Wed, Apr 10, 2024 at 09:38:04PM +0200, Pavel Sanda wrote:
> > It was under svn, not git until few weeks back when we update our infra.
> > Now both git or trac can be used (I used trac just because the conversion
> > patch was easier to write, but feel free to use git if you want, it's the
> > primary source after all).
>
> BTW since I inadvertedly broke windows installs (dictionary URLs need
> to be fixed for new releases) and accidentally found that our trac log
> exploded with warnings about inexisting paths - I was able to narrow down
> number of unique attempts to download sets of dictionaries. It gives ~50
> win
> installs requesting at least 1 dictionary per day during last 20 days.
>
> We never had any idea about the order of magnitude of our reach,
> this gives some approximation to ~18k win installs per year...
>

At least those that request a dictionary, because some common dictionaries
(german, few english variants, french, spanish) are included in the
installer itself so they never get requested.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Dictionaries in Win installer (was: LyX 2.4.0 & Jupyter Notebooks)

[Yu Jin]

Am Mi., 10. Apr. 2024 um 21:18 Uhr schrieb Pavel Sanda:

> On Wed, Apr 10, 2024 at 04:10:07PM +0200, Pavel Sanda wrote:
> > On Wed, Apr 10, 2024 at 12:22:46PM +, Bernt Lie wrote:
> > > OK - I'm in the process of downloading LyX 2.4.0 RC4, with MikTeX as
> back-end (I already had MikTeX installed...).
> > >
> > > This is what didn't work so far (during installation):
> > > * installation of dictionaries and thesauri in both Norwegian forms
> failed (Norsk Bokm??l, Nynorsk)
> > > * installation of thesauri in US and GB English failed.
> >
> > This looks like a problem in our win installer.
> > Eugene, do dictionaries installation work for you now?
> >
> > If they are not part of the package but we download them,
> > things might be broken after our recent infrastracture updates.
> >
> > The primary repository address is now at git (e.g.
> https://git.lyx.org/gitweb/?p=dictionaries.git;a=summary );
> > trac can be still used (mirror), but has slightly different url and
> scheme (no more lyxsvn and no "trunk").
>
> I indeed found that there are old links are present in dictionaries.nsh
> and took
> the liberty of fixing them. But untested, please check...


Yeah I just wanted to do that too, looks good, but it should also be
backported to 2.4.x and 2.4.1-devel?
I was just searching for a reason why trac is used there in the first place
instead of https://git.lyx.org/, I remember there was a reason but not what
it was exactly, but can't find it any more, I think there was a discussion
in a ticket on track somewhere.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Mi., 10. Apr. 2024 um 16:02 Uhr schrieb Jean-Marc Lasgouttes :

> Le 09/04/2024 à 06:30, Yu Jin a écrit :
> > Normally, unary_function and binary_function only disappeared in
> C++17.
> > Does C++14 work?
> >
> > Unfortunately not.
>
> Do you select the C++ level in Visual Studio or in cmake?
>

I don't see any option in CMake regarding c++ level, I just execute
configure and as far as I can see it does not set any explicit c++ level
and default in the current Visual Studio is c++14 and there seems no way to
use c++11.
https://developercommunity.visualstudio.com/t/Need-C11-in-visual-studio-not-C11-or/10081597?space=8=idea=visualizer
Manually setting '/std:c++11' command line switch also does not work, it
actually says that this switch is unknown and will be ignored -> so again
c++14 is used. And installing an older Visual Studio (Community) is also
not an option, because Microsoft does not offer that (only Professional and
Enterprise), so rip lyX 2.3.8 on Windows I guess, unless someone decides to
cross compile it using MinGW or so.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am Mo., 8. Apr. 2024 um 22:05 Uhr schrieb Jean-Marc Lasgouttes:

> Le 08/04/2024 à 19:36, Yu Jin a écrit :
> > Can you try to enforce C++11 mode to see whether it works better?
> >
> >
> > That's a problem, I am not able to select C++11:
> > image.png
> > even installed an older Windows SDK and ran CMake reconfigure completely
> > new.
>
> Normally, unary_function and binary_function only disappeared in C++17.
> Does C++14 work?
>
Unfortunately not.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.x does not compile on Windows

[Yu Jin]

Am So., 7. Apr. 2024 um 20:40 Uhr schrieb Jean-Marc Lasgouttes <
lasgout...@lyx.org>:

> Le 05/04/2024 à 22:12, Yu Jin a écrit :
> > Hi,
> >
> > Since 2.3.8 is around the corner I thought to try compiling the 2.3.x
> > branch but failed on Format.cpp, get these errors:
> >
> > Build started at 22:05...
> > 1>-- Build started: Project: LyX (applications\LyX\LyX),
> > Configuration: Debug x64 --
> > 1>Format.cpp
> > 1>C:\lyx\master\src\Format.cpp(61,33): error C2504: 'unary_function':
> > base class undefined
> > 1>C:\lyx\master\src\Format.cpp(61,47): error C2143: syntax error:
> > missing ',' before '<'
> > 1>C:\lyx\master\src\Format.cpp(75,38): error C2504: 'unary_function':
> > base class undefined
> > 1>C:\lyx\master\src\Format.cpp(75,52): error C2143: syntax error:
> > missing ',' before '<'
> > 1>C:\lyx\master\src\Format.cpp(89,32): error C2504: 'unary_function':
> > base class undefined
> > 1>C:\lyx\master\src\Format.cpp(89,46): error C2143: syntax error:
> > missing ',' before '<'
> > 1>C:\lyx\master\src\Format.cpp(608,18): warning C4244: 'return':
> > conversion from '__int64' to 'int', possible loss of data
> > 1>Done building project "LyX.vcxproj" -- FAILED.
> > == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
> ==
> > == Build completed at 22:05 and took 00,762 seconds ==
> >
> > Any Ideas?
>
> Can you try to enforce C++11 mode to see whether it works better?


That's a problem, I am not able to select C++11:
[image: image.png]
even installed an older Windows SDK and ran CMake reconfigure completely
new.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

2.3.x does not compile on Windows

[Yu Jin]

Hi,

Since 2.3.8 is around the corner I thought to try compiling the 2.3.x
branch but failed on Format.cpp, get these errors:

Build started at 22:05...
1>-- Build started: Project: LyX (applications\LyX\LyX), Configuration:
Debug x64 --
1>Format.cpp
1>C:\lyx\master\src\Format.cpp(61,33): error C2504: 'unary_function': base
class undefined
1>C:\lyx\master\src\Format.cpp(61,47): error C2143: syntax error: missing
',' before '<'
1>C:\lyx\master\src\Format.cpp(75,38): error C2504: 'unary_function': base
class undefined
1>C:\lyx\master\src\Format.cpp(75,52): error C2143: syntax error: missing
',' before '<'
1>C:\lyx\master\src\Format.cpp(89,32): error C2504: 'unary_function': base
class undefined
1>C:\lyx\master\src\Format.cpp(89,46): error C2143: syntax error: missing
',' before '<'
1>C:\lyx\master\src\Format.cpp(608,18): warning C4244: 'return': conversion
from '__int64' to 'int', possible loss of data
1>Done building project "LyX.vcxproj" -- FAILED.
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==
== Build completed at 22:05 and took 00,762 seconds ==

Any Ideas?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: c2248 compile error with qcompare and Qt 6.7.0

[Yu Jin]

Am Fr., 5. Apr. 2024 um 18:05 Uhr schrieb Jean-Marc Lasgouttes:

> Le 05/04/2024 à 17:55, Yu Jin a écrit :
> > Yeah I get this error now in Text.cpp
> >
> > Build started at 17:53...
> > 1>-- Build started: Project: LyX (applications\LyX\LyX),
> > Configuration: Debug x64 --
> > 1>Text.cpp
> > 1>C:\lyx\master\src\Text.cpp(5961,19): error C2065: 'uint': undeclared
> > identifier
>
> Is it better when replacing uint with unsigned int?
>
Yeah, it is.

>
> > 1>C:\lyx\master\src\Text.cpp(5961,11): error C2672: 'convert': no
> > matching overloaded function found
> > 1>C:\lyx\master\src\support\convert.h(24,8):
> > 1>could be 'Target lyx::convert(Source)'
> > 1> C:\lyx\master\src\Text.cpp(5961,19):
> > 1> 'lyx::convert': invalid template argument for 'Target', type expected
> > 1>Done building project "LyX.vcxproj" -- FAILED.
> >
> > (I omitted the Warnings)
>
> Warnings might be useful to see too.
>
Ok, here.

Build started at 18:07...
1>-- Build started: Project: LyX (applications\LyX\LyX), Configuration:
Debug x64 --
1>Text.cpp
1>C:\lyx\master\src\Text.cpp(3226,10): warning C4244: 'initializing':
conversion from 'const lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3238,28): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3238,18): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'const int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3240,15): warning C4244: 'return': conversion
from 'lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3295,18): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3408,20): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3499,30): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'int', possible loss of data
1>C:\lyx\master\src\Text.cpp(3499,21): warning C4244: 'initializing':
conversion from 'lyx::pos_type' to 'const int', possible loss of data
1>Done building project "LyX.vcxproj".
== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==
== Build completed at 18:07 and took 01,649 seconds ==

(with the uint replaced by "unsigned int")

>
> >
> > What we learn here is that including  might be enough to
> trigger
> > an error.
> >
> > No, I tried on a minimal project and just including it did not do
> > anything, compiled successfully.
>
> Good.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: c2248 compile error with qcompare and Qt 6.7.0

[Yu Jin]

Am Do., 4. Apr. 2024 um 17:51 Uhr schrieb Jean-Marc Lasgouttes:

> Le 03/04/2024 à 17:03, Yu Jin a écrit :
> > I am not able to compile LyX with the newest Qt (6.7.0), I get these
> > error when compiling factory.cpp:
> > 1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(228,30): error
> > C2248: 'Qt::partial_ordering::partial_ordering': cannot access private
> > member declared in class 'Qt::partial_ordering'
> > 1>Note: including file:
> > C:\Qt\6.7.0\msvc2019_64\include\QtCore/qlatin1stringview.h
> > 1>Note: including file:
> >   C:\Qt\6.7.0\msvc2019_64\include\QtCore/qchar.h
> > 1>(compiling source file '../../master/src/factory.cpp')
>
> Hi,
>
> I believe that the reason factory.cpp triggers this bug is that
> InsetInfo.h includes . I fixed that in git master, because it is
> a bad idea and it is not really necessary.

Thanks

> You should now experience a compiler error somewhere else %-] At least
> it should be a less weird message.
>
Yeah I get this error now in Text.cpp

Build started at 17:53...
1>-- Build started: Project: LyX (applications\LyX\LyX), Configuration:
Debug x64 --
1>Text.cpp
1>C:\lyx\master\src\Text.cpp(5961,19): error C2065: 'uint': undeclared
identifier
1>C:\lyx\master\src\Text.cpp(5961,11): error C2672: 'convert': no matching
overloaded function found
1>C:\lyx\master\src\support\convert.h(24,8):
1>could be 'Target lyx::convert(Source)'
1> C:\lyx\master\src\Text.cpp(5961,19):
1> 'lyx::convert': invalid template argument for 'Target', type expected
1>Done building project "LyX.vcxproj" -- FAILED.

(I omitted the Warnings)

What we learn here is that including  might be enough to trigger
> an error.
>
No, I tried on a minimal project and just including it did not do anything,
compiled successfully.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

c2248 compile error with qcompare and Qt 6.7.0

[Yu Jin]

I am not able to compile LyX with the newest Qt (6.7.0), I get these error
when compiling factory.cpp:
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(228,30): error C2248:
'Qt::partial_ordering::partial_ordering': cannot access private member
declared in class 'Qt::partial_ordering'
1>Note: including file:
C:\Qt\6.7.0\msvc2019_64\include\QtCore/qlatin1stringview.h
1>Note: including file:
 C:\Qt\6.7.0\msvc2019_64\include\QtCore/qchar.h
1>(compiling source file '../../master/src/factory.cpp')
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(189,5):
1>see declaration of 'Qt::partial_ordering::partial_ordering'
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(65,7):
1>see declaration of 'Qt::partial_ordering'
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(408,30): error C2248:
'Qt::partial_ordering::partial_ordering': cannot access private member
declared in class 'Qt::partial_ordering'
1>(compiling source file '../../master/src/factory.cpp')
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(189,5):
1>see declaration of 'Qt::partial_ordering::partial_ordering'
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(65,7):
1>see declaration of 'Qt::partial_ordering'
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(411,27): error C2248:
'Qt::weak_ordering::weak_ordering': cannot access private member declared
in class 'Qt::weak_ordering'
1>(compiling source file '../../master/src/factory.cpp')
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(377,5):
1>see declaration of 'Qt::weak_ordering::weak_ordering'
1>C:\Qt\6.7.0\msvc2019_64\include\QtCore\qcompare.h(220,7):
1>see declaration of 'Qt::weak_ordering'

I posted it on Qt bug tracker https://bugreports.qt.io/browse/QTBUG-123934
but they can't reproduce. Can anybody make sense of this? I don't
understand where LyX is trying to call these functions. Can you help create
a minimal example?

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4 RC4

[Yu Jin]

Am So., 24. März 2024 um 23:37 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> One last RC, just to be on the safe side.
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please prepare binaries.
>
Done for Windows, uploaded as usual.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Error: Font size of the environment choice box changes

[Yu Jin]

Am So., 25. Feb. 2024 um 12:26 Uhr schrieb Andreas Plihal :

> Hi,
>
> I am working with LYX 2.3.7 (January 1, 2023) on Windows 11 Home, version
> 23H2.
>
> Since I don't see too well, I increased the general text size in the
> Windows settings. However, this had an unexpected impact on LyX:
>
> The Environment choice box, which is located on the left end of the
> toolbar, reduces its font size! See my two attached pictures.
>
> I haven't found a way to compensate for this phenomenon within LyX.
> Please, can you fix this bug?
>

>From what I can remember Qt5 just does not scale well on Windows (2.3.7
uses Qt5), I looked into this too a couple years ago and experienced the
same issues, there is no fix or workaround I am aware of. Qt6 is better
with scaling, which you can test with 2.4.0 RC3.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: RC3 Tarballs

[Yu Jin]

Am Sa., 10. Feb. 2024 um 02:08 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> Here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please prepare binaries.
>

Done for Windows, uploaded as usual.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/2.3.x] Fix a number of issues that were stopping compilation with MSVC 19.

[Yu Jin]

Am Mo., 5. Feb. 2024 um 23:42 Uhr schrieb Jean-Marc Lasgouttes :

> I pushed this my mistake obviously. I was about the revert, and then I
> got confused by the fact that this supposedly fixes compilation with
> MSVC 2019. Can somebody enlighten me on whether this patch is needed
> with relevant versions of MSVC?


I am not able to compile with or without the patch with the most recent
visual studio (17.8.6), I get these errors:

Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Details
Fehler C2504 "unary_function": Basisklasse undefiniert LyX
C:\lyx\master\src\Format.cpp 61
Fehler C2143 Syntaxfehler: Es fehlt "," vor "<" LyX
C:\lyx\master\src\Format.cpp 61
Fehler C2504 "unary_function": Basisklasse undefiniert LyX
C:\lyx\master\src\Format.cpp 75
Fehler C2143 Syntaxfehler: Es fehlt "," vor "<" LyX
C:\lyx\master\src\Format.cpp 75
Fehler C2504 "unary_function": Basisklasse undefiniert LyX
C:\lyx\master\src\Format.cpp 89
Fehler C2143 Syntaxfehler: Es fehlt "," vor "<" LyX
C:\lyx\master\src\Format.cpp 89

without the patch I get more of them though

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: RC2 Tarballs

[Yu Jin]

Am Mo., 5. Feb. 2024 um 04:10 Uhr schrieb Richard Kimberly Heck:

> are here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please prepare binaries.
>

Done, uploaded as usual.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: RC1!!

[Yu Jin]

Am Do., 11. Jan. 2024 um 17:14 Uhr schrieb Richard Kimberly Heck:

> Here:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please build binaries.
>

Done for Windows, uploaded as usual.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 22. Okt. 2023 um 21:36 Uhr schrieb Yu Jin:

> It's this on Windows:
>
>
> C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>
>
>
> to be continued...
> https://bugreports.qt.io/browse/QTBUG-118462
>

It is actually fixed by Qt (wow that was fast). Version 6.7.0 will contain
the fix.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 22. Okt. 2023 um 21:06 Uhr schrieb Kornel Benko:

> Am Sun, 22 Oct 2023 20:48:38 +0200
> schrieb Yu Jin:
>
> > Am So., 22. Okt. 2023 um 17:32 Uhr schrieb Kornel Benko:
> >
> > > Am Sun, 22 Oct 2023 10:22:54 +0200
> > > schrieb Yu Jin:
> > >
> > > > Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin:
> > > >
> > > > > Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
> > > > >
> > > > >>
> > > > >> What bothers me, is that the following configure is OK.
> > > > >> For me that implies that the first configure already created
> > > > >> CMakeCache.txt.
> > > > >> Could you compare the first CMakeCache.txt with later created
> version?
> > > > >> Normally I would
> > > > >> expect they have same content.
> > > > >>
> > > > >
> > > > > Well the following configure does not do any checks or
> try_compile, so
> > > it
> > > > > can't run into this error .
> > > > >
> > > >
> > > > I think it comes from here:
> > > >
> > >
> https://git.lyx.org/?p=lyx.git;a=blob;f=development/cmake/ConfigureChecks.cmake;h=9062372c38e107156a7e561bce340045b0cd53e0;hb=0b5a9060c2afc3e68b3b055ec5b02db7d13458ab#l287
> > > > set(CMAKE_REQUIRED_INCLUDES ${${QtVal}Core_INCLUDE_DIRS})
> > > >
> > > > I just added a message after this line for testing message(STATUS
> > > "includes
> > > > set: "${${QtVal}Core_INCLUDE_DIRS})
> > > > and it returns:
> > > > includes set:
> > > >
> > >
> C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>
> > > >
> > > > So exactly what is set in CMakeCache.txt of the try_compie project,
> so in
> > > > the end it's set in ${Qt6Core_INCLUDE_DIRS}, which comes from Qt I
> > > suppose,
> > > > I guess I can make a minimal example with this and ask on the Qt
> forum...
> > > >
> > >
> > > That asking the forum would be nice. And yes, Qt6Core_INCLUDE_DIRS
> comes
> > > from Qt, not our
> > >
> >
> > What does it contain on Linux though? could you try with a simple
> > message(STATUS  ${Qt6Core_INCLUDE_DIRS})
> > ?
>
> Qt6Core_INCLUDE_DIRS =
> /usr/include/x86_64-linux-gnu/qt6/QtCore;/usr/include/x86_64-linux-gnu/qt6
>
> This is also with cmake3.28
>

It's this on Windows:

C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>


to be continued...
https://bugreports.qt.io/browse/QTBUG-118462

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 22. Okt. 2023 um 17:32 Uhr schrieb Kornel Benko:

> Am Sun, 22 Oct 2023 10:22:54 +0200
> schrieb Yu Jin:
>
> > Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin:
> >
> > > Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
> > >
> > >>
> > >> What bothers me, is that the following configure is OK.
> > >> For me that implies that the first configure already created
> > >> CMakeCache.txt.
> > >> Could you compare the first CMakeCache.txt with later created version?
> > >> Normally I would
> > >> expect they have same content.
> > >>
> > >
> > > Well the following configure does not do any checks or try_compile, so
> it
> > > can't run into this error .
> > >
> >
> > I think it comes from here:
> >
> https://git.lyx.org/?p=lyx.git;a=blob;f=development/cmake/ConfigureChecks.cmake;h=9062372c38e107156a7e561bce340045b0cd53e0;hb=0b5a9060c2afc3e68b3b055ec5b02db7d13458ab#l287
> > set(CMAKE_REQUIRED_INCLUDES ${${QtVal}Core_INCLUDE_DIRS})
> >
> > I just added a message after this line for testing message(STATUS
> "includes
> > set: "${${QtVal}Core_INCLUDE_DIRS})
> > and it returns:
> > includes set:
> >
> C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>
> >
> > So exactly what is set in CMakeCache.txt of the try_compie project, so in
> > the end it's set in ${Qt6Core_INCLUDE_DIRS}, which comes from Qt I
> suppose,
> > I guess I can make a minimal example with this and ask on the Qt forum...
> >
>
> That asking the forum would be nice. And yes, Qt6Core_INCLUDE_DIRS comes
> from Qt, not our
>

What does it contain on Linux though? could you try with a simple
message(STATUS  ${Qt6Core_INCLUDE_DIRS})
?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am Sa., 21. Okt. 2023 um 22:00 Uhr schrieb Yu Jin :

> Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:
>
>>
>> What bothers me, is that the following configure is OK.
>> For me that implies that the first configure already created
>> CMakeCache.txt.
>> Could you compare the first CMakeCache.txt with later created version?
>> Normally I would
>> expect they have same content.
>>
>
> Well the following configure does not do any checks or try_compile, so it
> can't run into this error .
>

I think it comes from here:
https://git.lyx.org/?p=lyx.git;a=blob;f=development/cmake/ConfigureChecks.cmake;h=9062372c38e107156a7e561bce340045b0cd53e0;hb=0b5a9060c2afc3e68b3b055ec5b02db7d13458ab#l287
set(CMAKE_REQUIRED_INCLUDES ${${QtVal}Core_INCLUDE_DIRS})

I just added a message after this line for testing message(STATUS "includes
set: "${${QtVal}Core_INCLUDE_DIRS})
and it returns:
includes set:
C:/Qt/6.6.0/msvc2019_64/include/QtCoreC:/Qt/6.6.0/msvc2019_64/includeC:/Qt/6.6.0/msvc2019_64/include/QtZlib$<$>:>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>

So exactly what is set in CMakeCache.txt of the try_compie project, so in
the end it's set in ${Qt6Core_INCLUDE_DIRS}, which comes from Qt I suppose,
I guess I can make a minimal example with this and ask on the Qt forum...

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am Sa., 21. Okt. 2023 um 19:42 Uhr schrieb Kornel Benko:

>
> What bothers me, is that the following configure is OK.
> For me that implies that the first configure already created
> CMakeCache.txt.
> Could you compare the first CMakeCache.txt with later created version?
> Normally I would
> expect they have same content.
>

Well the following configure does not do any checks or try_compile, so it
can't run into this error .
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am Sa., 21. Okt. 2023 um 08:42 Uhr schrieb Yu Jin :

> Am So., 15. Okt. 2023 um 22:32 Uhr schrieb Yu Jin  >:
>
>> Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:
>>
>>>
>>> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>>>
>>
>> Ping...
>> I don't really understand what is wrong here, could some1 help out with a
>> minimal example so I can ask the Qt forum?
>>
>> Git bisect leads to this
>
> https://git.lyx.org/?p=lyx.git;a=commitdiff;h=ebe4834684a523de15f55068a32b487cae251bea
>
> I ran cmake with --debug-trycompile and found some more infos, here is
the error:

-- Looking for C++ include QtGui/qtgui-config.h
CMake Debug Log at C:/Program
Files/CMake/share/cmake-3.26/Modules/CheckIncludeFileCXX.cmake:94
(try_compile):
  Executing try_compile (HAVE_QTGUI_CONFIG_H) in:

C:/lyx/master-build-64/CMakeFiles/CMakeScratch/TryCompile-896vpl
Call Stack (most recent call first):
  development/cmake/ConfigureChecks.cmake:290 (check_include_file_cxx)
  CMakeLists.txt:1146 (include)


CMake Error at
C:/lyx/master-build-64/CMakeFiles/CMakeScratch/TryCompile-896vpl/CMakeLists.txt:12
(include_directories):
  Error evaluating generator expression:

$

  Target "Qt6::ZlibPrivate" not found.

here is the File
C:/lyx/master-build-64/CMakeFiles/CMakeScratch/TryCompile-896vpl/CMakeLists.txt:

cmake_minimum_required(VERSION 3.28.0.0)
set(CMAKE_MODULE_PATH
"C:/lyx/master/development/cmake/modules;C:/Qt/6.6.0/msvc2019_64/lib/cmake/Qt6;C:/Qt/6.6.0/msvc2019_64/lib/cmake/Qt6/3rdparty/extra-cmake-modules/find-modules;C:/Qt/6.6.0/msvc2019_64/lib/cmake/Qt6/3rdparty/kwin")
cmake_policy(SET CMP0091 OLD)
cmake_policy(SET CMP0141 OLD)
cmake_policy(SET CMP0126 OLD)
cmake_policy(SET CMP0128 OLD)
project(CMAKE_TRY_COMPILE CXX)
set(CMAKE_VERBOSE_MAKEFILE 1)
set(CMAKE_CXX_FLAGS "/DWIN32 /D_WINDOWS /W3 /GR /EHsc")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMPILE_DEFINITIONS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${EXE_LINKER_FLAGS}")
include_directories(${INCLUDE_DIRECTORIES})
set(CMAKE_SUPPRESS_REGENERATION 1)
link_directories(${LINK_DIRECTORIES})
cmake_policy(SET CMP0065 OLD)
cmake_policy(SET CMP0083 OLD)
cmake_policy(SET CMP0155 OLD)
include("${CMAKE_ROOT}/Modules/Internal/HeaderpadWorkaround.cmake")
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY
"C:/lyx/master-build-64/CMakeFiles/CMakeScratch/ TryCompile-896vpl")
add_executable(cmTC_cde46)
target_sources(cmTC_cde46 PRIVATE

"C:/lyx/master-build-64/CMakeFiles/CMakeScratch/TryCompile-896vpl/CheckIncludeFile.cxx"
)
file(GENERATE OUTPUT
"${CMAKE_BINARY_DIR}/cmTC_cde46_$>_loc"
 CONTENT $)
target_link_libraries(cmTC_cde46 ${LINK_LIBRARIES})


So it fails on
include_directories(${INCLUDE_DIRECTORIES})
I have checked the file
C:/lyx/master-build-64/CMakeFiles/CMakeScratch/TryCompile-896vpl/CMakeCache.txt:

//No help, variable specified on the command line.
INCLUDE_DIRECTORIES:UNINITIALIZED=C:/Qt/6.6.0/msvc2019_64/include/QtCore;C:/Qt/6.6.0/msvc2019_64/include;C:/Qt/6.6.0/msvc2019_64/include/QtZlib;$<$>:>;$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0>;$<$>:C:/Qt/6.6.0/msvc2019_64/include/QtZlib/6.6.0/QtZlib>

Is this something variable specified by CMake or can we affect it? Maybe
it's the same thing as in this thread?
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218586.html
For quick reminder we ended up doing this:
https://git.lyx.org/?p=lyx.git;a=commitdiff;h=26a3a085
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 15. Okt. 2023 um 22:32 Uhr schrieb Yu Jin :

> Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:
>
>>
>> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>>
>
> Ping...
> I don't really understand what is wrong here, could some1 help out with a
> minimal example so I can ask the Qt forum?
>
> Git bisect leads to this
https://git.lyx.org/?p=lyx.git;a=commitdiff;h=ebe4834684a523de15f55068a32b487cae251bea
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am Mo., 2. Okt. 2023 um 21:51 Uhr schrieb Yu Jin:

>
> C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
>

Ping...
I don't really understand what is wrong here, could some1 help out with a
minimal example so I can ask the Qt forum?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Implement ui style selection dialog 12832

[Yu Jin]

Am Mi., 11. Okt. 2023 um 20:54 Uhr schrieb Pavel Sanda:

> On Wed, Oct 11, 2023 at 06:47:10PM +0200, Eugene Chornyi wrote:
> > commit 072ba7bd2e1ac7514117fafee3143b0bfb8796eb
> > Author: Eugene Chornyi
> > Date:   Wed Oct 11 20:06:52 2023 +0200
> >
> > Implement ui style selection dialog 12832
> > ---
> >  lib/RELEASE-NOTES   |4 ++
> >  src/LyX.cpp |   10 --
> >  src/LyXRC.cpp   |   15 +
> >  src/LyXRC.h |3 ++
> >  src/frontends/qt/GuiApplication.cpp |3 ++
> >  src/frontends/qt/GuiPrefs.cpp   |   13 
> >  src/frontends/qt/ui/PrefUi.ui   |   54
> ---
> >  7 files changed, 81 insertions(+), 21 deletions(-)
>
> Eugene, several things seem to be missing:
> - incremented LYXRC_FILEFORMAT & update of prefs2prefs scripts
> - documentation of the new combo in our manuals


Sorry, I didn't know that I needed to do that, thank you for telling me.
done at
https://git.lyx.org/?p=lyx.git;a=commitdiff;h=f1deb1c658c121e21d484130dbd1ba4e6feaa9f4;hp=c9c5a2a9d824acc10fdd96b0972223450c47c6dd
hope that's right.
Just another question, do I need to worry about the translation (of the
strings and the UserGuide.lyx)?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am Sa., 30. Sept. 2023 um 13:45 Uhr schrieb Kornel Benko:

> Am Sat, 30 Sep 2023 09:35:57 +0200
> schrieb Yu Jin:
>
> > Am So., 17. Sept. 2023 um 07:24 Uhr schrieb Yu Jin:
> >
> > > Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin
> > > >:
> > >
> > >> When I configure for the first time (into an empty folder) I get this
> > >> error:
> > >>
> > >> CMake Error at
> > >>
> C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
> > >> (include_directories):
> > >>   Error evaluating generator expression:
> > >>
> > >> $
> > >>
> > >>   Target "Qt6::ZlibPrivate" not found.
> > >>
> > >> (full log attached)
> > >>
> > > Log
> > >
> > >> If I ignore this error and click configure again it works. Looks like
> it
> > >> only occurs with Qt6.
> > >>
> > >
> > Nobody has an idea?? I found this in the  CMakeConfigureLog.yaml file:
> >   -
> > kind: "try_compile-v1"
> > backtrace:
> >   - "C:/Program
> > Files/CMake/share/cmake-3.26/Modules/CheckIncludeFileCXX.cmake:94
> > (try_compile)"
> >   - "development/cmake/ConfigureChecks.cmake:290
> > (check_include_file_cxx)"
> >   - "CMakeLists.txt:1146 (include)"
> > checks:
> >   - "Looking for C++ include QtGui/qtgui-config.h"
> > directories:
> >   source:
> > "C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-z4oq2c"
> >   binary:
> > "C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-z4oq2c"
> > cmakeVariables:
> >   CMAKE_CXX_FLAGS: "/DWIN32 /D_WINDOWS /W3 /GR /EHsc"
> >   CMAKE_MODULE_PATH:
> >
> "C:/lyx/master/development/cmake/modules;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6/3rdparty/extra-cmake-modules/find-modules;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6/3rdparty/kwin"
> > buildResult:
> >   variable: "HAVE_QTGUI_CONFIG_H"
> >   cached: true
> >   stdout: |
> >   exitCode: 1
> >
> > (this is from another configure attempt). Of course the CMakeScratch
> folder
> > is empty.
>
> Where is the "QtGui/qtgui-config.h" located on your system?
> Here it is under
> /usr/include/x86_64-linux-gnu/qt6/QtGui/qtgui-config.h
> The CMAKE_MODULE_PATH looks good (same as here but different system
> prefix), does not
> contain "qt6" path.
>

C:\Qt\6.5.2\msvc2019_64\include\QtGui\qtgui-config.h
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 17. Sept. 2023 um 07:24 Uhr schrieb Yu Jin :

> Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin  >:
>
>> When I configure for the first time (into an empty folder) I get this
>> error:
>>
>> CMake Error at
>> C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
>> (include_directories):
>>   Error evaluating generator expression:
>>
>> $
>>
>>   Target "Qt6::ZlibPrivate" not found.
>>
>> (full log attached)
>>
> Log
>
>> If I ignore this error and click configure again it works. Looks like it
>> only occurs with Qt6.
>>
>
Nobody has an idea?? I found this in the  CMakeConfigureLog.yaml file:
  -
kind: "try_compile-v1"
backtrace:
  - "C:/Program
Files/CMake/share/cmake-3.26/Modules/CheckIncludeFileCXX.cmake:94
(try_compile)"
  - "development/cmake/ConfigureChecks.cmake:290
(check_include_file_cxx)"
  - "CMakeLists.txt:1146 (include)"
checks:
  - "Looking for C++ include QtGui/qtgui-config.h"
directories:
  source:
"C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-z4oq2c"
  binary:
"C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-z4oq2c"
cmakeVariables:
  CMAKE_CXX_FLAGS: "/DWIN32 /D_WINDOWS /W3 /GR /EHsc"
  CMAKE_MODULE_PATH:
"C:/lyx/master/development/cmake/modules;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6/3rdparty/extra-cmake-modules/find-modules;C:/Qt/6.5.2/msvc2019_64/lib/cmake/Qt6/3rdparty/kwin"
buildResult:
  variable: "HAVE_QTGUI_CONFIG_H"
  cached: true
  stdout: |
  exitCode: 1

(this is from another configure attempt). Of course the CMakeScratch folder
is empty.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake fails on first configure

[Yu Jin]

Am So., 17. Sept. 2023 um 07:23 Uhr schrieb Yu Jin :

> When I configure for the first time (into an empty folder) I get this
> error:
>
> CMake Error at
> C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
> (include_directories):
>   Error evaluating generator expression:
>
> $
>
>   Target "Qt6::ZlibPrivate" not found.
>
> (full log attached)
>
Log

> If I ignore this error and click configure again it works. Looks like it
> only occurs with Qt6.
>
-- 
  Eugene
TOP_SRC_DIR = C:/lyx/master

Building out-of-source
Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22621.
Selecting build type defaults from configure.ac
Found GNUWIN32: C:/lyx/lyx-windows-deps-msvc2023_64

CXX11_FLAG_DETECTED = "/std:c++20"
Compiler supports std_regex
Found CXX11Compiler: /std:c++20  
CMAKE_CXX_STANDARD set to 20
Performing Test CMAKE_HAVE_LIBC_PTHREAD
Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
Looking for pthread_create in pthreads
Looking for pthread_create in pthreads - not found
Looking for pthread_create in pthread
Looking for pthread_create in pthread - not found
Found Threads: TRUE  
Performing Test HAVE_STDATOMIC
Performing Test HAVE_STDATOMIC - Success
Found WrapAtomic: TRUE  
Could NOT find WrapVulkanHeaders (missing: Vulkan_INCLUDE_DIR) 
Found Qt-Version 6.5.2
Looking for magic_file
Looking for magic_file - not found
Function magic_file not found
Looking for magic_open
Looking for magic_open - not found
Function magic_open not found
Looking for magic_load
Looking for magic_load - not found
Function magic_load not found
Looking for magic_close
Looking for magic_close - not found
Function magic_close not found
Looking for magic_error
Looking for magic_error - not found
Function magic_error not found
Could NOT find Magic (missing: Magic_INCLUDE_DIR Magic_LIBRARY 
HAS_MAGIC_FUNCTIONS) 
  * Hunspell:
 - include: 
C:/lyx/master/3rdparty/hunspell/1.7.0/src/hunspell;C:/lyx/master/3rdparty/hunspell/1.7.0/src
 - library: hunspell
Could NOT find ASPELL (missing: ASPELL_LIBRARY ASPELL_INCLUDE_DIR) 
ASPELL not found, building without ASPELL support
Could NOT find ENCHANT (missing: ENCHANT_LIBRARY ENCHANT_INCLUDE_DIR) 
ENCHANT not found, building without ENCHANT support
Building with USE_HUNSPELL
Could NOT find LYX_PY_polib (missing: LYX_PY_POLIB) 
You will be unable to update layouttranslations file
Looking for sys/types.h
Looking for sys/types.h - found
Looking for stdint.h
Looking for stdint.h - found
Looking for stddef.h
Looking for stddef.h - found
Check size of ptrdiff_t
Check size of ptrdiff_t - done
Check size of sig_atomic_t
Check size of sig_atomic_t - done
Check size of size_t
Check size of size_t - done
Check size of wchar_t
Check size of wchar_t - done
Check size of wint_t
Check size of wint_t - done
Check size of long long int
Check size of long long int - done
Check size of unsigned long long int
Check size of unsigned long long int - done
Check size of _Bool
Check size of _Bool - done
Looking for include file alloca.h
Looking for include file alloca.h - not found
Looking for include file dlfcn.h
Looking for include file dlfcn.h - not found
Looking for include file inttypes.h
Looking for include file inttypes.h - found
Looking for include file mach-o/dyld.h
Looking for include file mach-o/dyld.h - not found
Looking for include file memory.h
Looking for include file memory.h - found
Looking for include file search.h
Looking for include file search.h - found
Looking for include file stdlib.h
Looking for include file stdlib.h - found
Looking for include file strings.h
Looking for include file strings.h - not found
Looking for include file string.h
Looking for include file string.h - found
Looking for include file sys/bitypes.h
Looking for include file sys/bitypes.h - not found
Looking for include file sys/inttypes.h
Looking for include file sys/inttypes.h - not found
Looking for include file sys/param.h
Looking for include file sys/param.h - not found
Looking for include file sys/socket.h
Looking for include file sys/socket.h - not found
Looking for include file sys/stat.h
Looking for include file sys/stat.h - found
Looking for include file sys/time.h
Looking for include file sys/time.h - not found
Looking for include file unistd.h
Looking for include file unistd.h - not found
Looking for include file wchar.h
Looking for include file wchar.h - found
Looking for include file winsock2.h
Looking for include file winsock2.h - found
Looking for canonicalize_file_name
Looking for canonicalize_file_name - not found
Looking for dcgettext
Looking for dcgettext - not found
Looking for gettext
Looking for gettext - not found
Looking for iconv
Looking for iconv - not found
Looking for lstat
Looking for lstat - not found
Looking for mbrtowc
Looking for mbrtowc - found
Looking for mbsinit
Looking for mbsinit - not found
Looking for memmove
Looking for memmove - found
Looking for atoll
Lo

CMake fails on first configure

[Yu Jin]

When I configure for the first time (into an empty folder) I get this error:

CMake Error at
C:/lyx/master-build-64-qt6/CMakeFiles/CMakeScratch/TryCompile-re0snf/CMakeLists.txt:12
(include_directories):
  Error evaluating generator expression:

$

  Target "Qt6::ZlibPrivate" not found.

(full log attached)
If I ignore this error and click configure again it works. Looks like it
only occurs with Qt6.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 5 dmg

[Yu Jin]

Am Di., 5. Sept. 2023 um 16:43 Uhr schrieb Richard Kimberly Heck:

> is at http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/.
>
> We're still waiting for the Windows installer.
>


Sorry, I was away, I just uploaded it to my drive as usual.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: No display of file icon, the slanted blue coloured L

[Yu Jin]

>From the users list:

Am Fr., 14. Juli 2023 um 15:18 Uhr schrieb Akhilesh Singh:

> After installing LyX-2.3.7 for Windows 10, the LyX installs very well and
> works very well. But, all the *.lyx files prepared by LyX does not display
> its icon, the slanted blue coloured L before the filename.
>
> Although, there is no problem in working. But, I wanted to bring this to
> the notice of developers.
>

Which is the current document icon? Isn't it this one?:
[image: image.png]
At least it's what is in the git repo.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Fr., 7. Juli 2023 um 19:31 Uhr schrieb Yu Jin:

>
> Yeah we need other opinions on this.
>

I have created a new ticket
https://www.lyx.org/trac/ticket/12832
I think that is better to keep track of.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Fr., 7. Juli 2023 um 15:25 Uhr schrieb Thibaut Cuvelier:

> Qt hasn't changed its -style parameter at least since Qt 4 (2005), that's
> quite stable (there is also an environment variable, QT_STYLE_OVERRIDE).
> I couldn't find any way to tell if the style was set from the command line
> or not (or to get the default style for the current platform), so we would
> always need to check manually whether there has been some CLI-set style,
> whatever path we end up taking.
>

>From what I understand Qt has some style picking priority when creating the
QApplication.
https://stackoverflow.com/questions/48093102/how-does-qt-select-a-default-style


(There is some precedent with locale handling, where Qt is trying hard to
> impose its locale, it seems.)
> (More details: the -style parameter is dealt with in
> QGuiApplicationPrivate, not accessible from LyX and not available anywhere
> in the API, as far as I can tell.)
>
> As Qt can dynamically change the style at runtime, why would you need to
> know it when instantiating GuiApplication? Anyway, in my patch, the style
> is set before calling QApplication::exec, before any user interaction can
> take place, the user should not see any difference in delay before
> interacting with LyX.
>

Your patch basically disables the "-style" CLI argument, because it sets
(overwrites) the style *after* QApplication is created. My patch sets the
style *before* QApplication is created, this style is then used by Qt when
creating QApplication. If the user passed -style argument however,
QApplication is created using that argument instead, because of some
priority rules (I think it should be similar with the environment
variable). But if you set the style after creation, those rules don't
apply, it just sets the style on the existing QApplication.

So
1. your patch would need to implement that priority rule(s) by its own
instead of letting Qt handle it and
2. frontend::Application * createApplication(int & argc, char * argv[])
removes all the arguments it knows so the -style argument is not present
anymore when your patch sets the style, so additionally you would need to
read that argument before createApplication (here we go again), save it and
then do task 1 afterwards.

>
> I have no opinion on whether the LyXRC file should be read before or after
> createApplication, I have no idea about the trade-offs here. What do others
> think about it? This change may impact other platforms too.
>

Yeah we need other opinions on this.

>
> Anyway, it works as expected.
>
>
>> Also note that in the patch I have set "fusion" to default on Windows,
>> other OSes can do it the same way if they want.
>>
>
> Fusion doesn't look native at all on any platform by design
> ,
> but it's the only not-too-terrible choice for dark themes on Windows :/. I
> would do either of the following: let Qt handle the default theme or only
> impose the strange Fusion style on users when we know it's the least worst
> for users. The idea is to have a good default for users, with LyX being as
> native-looking as possible --- a goal that is currently achieved, albeit
> the support for dark themes on Windows is really subpar (like many Windows
> apps).
>

To be honest I think that the fusion style looks much more native on
Windows 11 than the windowsvista style.

>
> Actually, I'd be OK with merging this patch with a change in the way the
> default theme is selected.
>
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Fr., 7. Juli 2023 um 04:37 Uhr schrieb Thibaut Cuvelier:

> I'm having an issue with your patch: QStyle::name has only been added in
> Qt 6.1 (https://doc.qt.io/qt-6/qstyle.html#name). I believe
> QObject::objectName should do the trick too.
>
> As I understand your problem, in LyX.cpp, LyX::exec first creates a
> GuiApplication (line 358) before initialising LyX (line 366). If I do the
> initialisation in GuiApplication::exec instead, I don't get any crash;
> actually, your patch works :)!
> I have added a similar line in PrefInput::applyRC so that the style change
> applies immediately when clicking Apply in the Preferences window.
>

I think it is actually better to do that in PrefUserInterface::applyRC for
affiliation.

>
> I'm attaching the corresponding patch.
>

I didn't understand this part:
@@ -718,13 +718,13 @@ GuiView::GuiView(int id)
  connect(zoom_value_, SIGNAL(pressed()), this,
SLOT(showZoomContextMenu()));
  // zoom_value_->setPalette(palette);
  zoom_value_->setForegroundRole(statusBar()->foregroundRole());
  zoom_value_->setFixedHeight(fm.height());
 #if (QT_VERSION >= QT_VERSION_CHECK(5, 11, 0))
- zoom_value_->setMinimumWidth(fm.horizontalAdvance("444\%"));
+ zoom_value_->setMinimumWidth(fm.horizontalAdvance("444%"));
 #else
- zoom_value_->setMinimumWidth(fm.width("444\%"));
+ zoom_value_->setMinimumWidth(fm.width("444%"));
 #endif
  zoom_value_->setAlignment(Qt::AlignCenter);
  zoom_value_->setText(toqstr(bformat(_("[[ZOOM]]%1$d%"), zoom)));
  statusBar()->addPermanentWidget(zoom_value_);
  zoom_value_->setEnabled(currentBufferView());


>
> Side question: why is createApplication declared in Application.h but
> defined in GuiApplication.cpp?
>
>
> On Fri, 7 Jul 2023 at 02:23, Thibaut Cuvelier wrote:
>
>> Can't you use setStyle later on, once LyXRC is read?
>>
>
You could, like in your patch, but this creates another problem (see below)


> I suspect it should be enough to apply the style to the whole application,
>> based on the source code (
>> https://github.com/qt/qtbase/blob/dev/src/widgets/kernel/qapplication.cpp#L971),
>> as I understand that GuiApplication is the root widget for the whole LyX.
>>
>> Also, I believe that LyXRC shouldn't take precedence over CLI arguments
>> (-style windows, for instance); does Qt implement this itself or do we have
>> to check in QCoreApplication::arguments if a style is given?
>>
>
I believe the way would be to set the style *before* the QApplication is
created, then if any style is given in CLI arguments, QApplication uses
that over the one previously set.

I don't know, to me it seems we *need* to know style setting from lyxrc
before we create the gui app
frontend::GuiApplication * guiApp = new frontend::GuiApplication(argc,
argv);
which is not given.
otherwise we would need to check cli arguments manually for "-style" and I
don't want to do that, if Qt decides to change those in the future we would
have to put more work into it.
What can be done is calling readRcFile("preferences", true) before
CreateApplication, like I have done here in the attached patch, but I don't
know if that is ok or not, it seems to work, but I can't assess it 100%,
any ideas/objections?
Also note that in the patch I have set "fusion" to default on Windows,
other OSes can do it the same way if they want.
-- 
  Eugene


0001-Implement-style-selection-dialog.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Do., 6. Juli 2023 um 03:47 Uhr schrieb Thibaut Cuvelier:

> On Wed, 5 Jul 2023 at 22:02, Enrico Forestieri wrote:
>
>> On Wed, Jul 05, 2023 at 08:42:21PM +0200, Pavel Sanda wrote:
>> >
>> >I think your patch should go for windows port only as it would probably
>> >interfere with ppl choosing windows style under linux (yes, apparently
>> >there are users choosing this as I read users list).
>>
>> I don't think this is a good idea because LyX would look different from
>> any other application.
>>
>
> +1, the Fusion style isn't native at all (the colours are completely off,
> for instance). Maybe some users will like it, though (like the author of
> https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5).
>
> However, it seems that the classic Windows theme has a dark mode starting
> with Qt 6.5 (out since April):
> https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5. The Windows
> style, both in Qt 5 and Qt 6, is horrible, though... Here is what it looks
> like (2.4 beta 3 with Qt 6.5.1 as built by Eugene; run with:
> .\LyX.exe -platform windows:darkmode=2 -style windows
> ):
>
> What's strange is that the situation isn't much better for Qt Quick, with
> no native Windows dark theme. There are other open-source projects that
> provide a good Windows theme that also works in dark, such as
> https://github.com/witalihirsch/QTWin11 for Python only or
> https://github.com/marunemitsu/QTFluent (very modern style, unlike the
> default Vista one). I have seen good results with
> https://github.com/ColinDuquesnoy/QDarkStyleSheet (but not with its light
> theme!), which is more or less maintained and should work with Qt 6 (not
> PyQt 6 out of the box, though). Wireshark went that route, but the code
> didn't get merged (
> https://gitlab.com/wireshark/wireshark/-/merge_requests/6382).
>
> Overall, it seems that Qt's dark theme for Windows is inexistent; their
> preferred solution is to avoid implementing a proper theme, so that people
> have to rely on unmaintained projects or use their own solution. They rely
> consider it done (
> https://bugreports.qt.io/browse/QTBUG-72028#comment-712180)!
>
> How complex would it be to have a new LyX setting to choose the Qt theme?
> I believe it should not be too hard, as you can change the style on
> QApplication. Or is there something I'm missing?
>

I tried my luck here (patch attached) but it is not working though. While I
think I got the UI and LyXRC right, the problem is that at the time of
creation of QApplication the LyXRC is initialized but not read, so the
saved style preference is not available.

This stacktrace is from application creation:
  LyX.exe!lyx::createApplication(int & argc, char * * argv) Zeile 224 C++
  LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 358 C++
  LyX.exe!main(int argc, char * * argv) Zeile 55 C++

This one from LyXRC reading:
  LyX.exe!lyx::LyXRC::read(lyx::Lexer & lexrc, bool check_format) Zeile 608
C++
  LyX.exe!lyx::LyXRC::read(const lyx::support::FileName & filename, bool
check_format) Zeile 242 C++
  LyX.exe!lyx::LyX::readRcFile(const std::string & name, bool check_format)
Zeile 1148 C++
  LyX.exe!lyx::LyX::init() Zeile 998 C++
  LyX.exe!lyx::LyX::init(int & argc, char * * argv) Zeile 483 C++
  LyX.exe!lyx::LyX::exec(int & argc, char * * argv) Zeile 366 C++
  LyX.exe!main(int argc, char * * argv) Zeile 55 C++

second function from bottom: line 358 vs 366.

Any ideas what I could do here?
-- 
  Eugene


0001-Implement-style-selection-dialog.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Di., 4. Juli 2023 um 15:42 Uhr schrieb Pavel Sanda:

> On Tue, Jul 04, 2023 at 10:55:14AM +0200, Yu Jin wrote:
> > Am Di., 4. Juli 2023 um 10:40 Uhr schrieb Jürgen Spitzmüller:
> >
> > > Am Dienstag, dem 04.07.2023 um 10:33 +0200 schrieb Yu Jin:
> > > > How do you switch on Linux/MacOS? Or does it just follow the system
> > > > setting?
> > >
> > > It follows the system settings unless you use a dark style via cl
> > > switch.
>
> On linux systems where desktop manager does not do it automatically, you
> can use (in case of QT 5) qt5ct tool to set it up. E.g. you select fusion
> style and "darker" (or any other you might like) color scheme.
>
> Then before running lyx you set the environment variable
> QT_QPA_PLATFORMTHEME=qt5ct
> and that should work (tested on oldstable debian).
>
> > What if we make "fusion" style default on windows then? That would make
> > LyX's behavior the same as on Linux and MacOS.
>
> Given that you are now the principal maintainer of the windows port
> I think that's up to you to decide.
>
> Advantage of fusion is that it will look the same across platform
> disadvantage might be that it looks less native to windows than
> other apps on your desktop?
>

Actually Qt blog says that "their" preferred style on Windows is fusion
¯\_(ツ)_/¯.

So would that be something we want to set on all platforms? or only Windows?
I attached 2 patches accordingly, the style can be overwritten by the user
through command line arguments as before.

Which one should I push?
-- 
  Eugene


0001-set-default-application-style-to-fusion-on-Windows.patch
Description: Binary data


0001-set-default-application-style-to-fusion.patch
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Di., 4. Juli 2023 um 10:40 Uhr schrieb Jürgen Spitzmüller:

> Am Dienstag, dem 04.07.2023 um 10:33 +0200 schrieb Yu Jin:
> > How do you switch on Linux/MacOS? Or does it just follow the system
> > setting?
>
> It follows the system settings unless you use a dark style via cl
> switch.


What if we make "fusion" style default on windows then? That would make
LyX's behavior the same as on Linux and MacOS.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows Dark Mode and "fusion" style

[Yu Jin]

Am Di., 4. Juli 2023 um 09:59 Uhr schrieb Jürgen Spitzmüller:

> Am Dienstag, dem 04.07.2023 um 08:46 +0200 schrieb Yu Jin:
> > Do we have a setting for switching to fusion style and/or toggling
> > dark mode on/off?
>
> No. A setting that let's you chose "System Settings/Dark/Light" would
> be good, but it's not trivial to implement AFAICS.
>

How do you switch on Linux/MacOS? Or does it just follow the system setting?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: trac & gmail

[Yu Jin]

Am Mo., 3. Juli 2023 um 23:31 Uhr schrieb Pavel Sanda:

> On Mon, Jun 26, 2023 at 07:18:24PM +0200, Yu Jin wrote:
> > > We do not know why this is happening, but we can reset the password for
> > > you.
> > >
> > Yeah sure. Additionally if it is just gmail, maybe just update my
> account's
> > email address to yu_...@lyx.org? If that forwarding is still up.
>
> I tried to setup new email for you, see my private email.
>
> > About beta2 all I got was #12630. Is there anything else I should have
> > gotten?
>
> Just sent another email with bug numbers (basically those targetted for 2.4
> with os=windows keywords).

Yes, it works now, now I'm getting emails. Thanks.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: trac & gmail

[Yu Jin]

Am Mo., 26. Juni 2023 um 17:04 Uhr schrieb Richard Kimberly Heck:

> On 6/26/23 05:07, Yu Jin wrote:
>
> Am Fr., 16. Juni 2023 um 13:28 Uhr schrieb Pavel Sanda:
>
>> On Fri, Jun 16, 2023 at 10:53:39AM +0200, Pavel Sanda wrote:
>> > I wonder whether our bug tracker notifications became essentialy
>> unusable fro anyone having gmail address.
>>
>> I also figured out that whatever we sent to Eugene for windows OS in trac
>> probably did not reach target, because I do not see his account (Yu_Jin)
>> on
>> trac. Either never was there or we lost it...
>>
>> Eugene, are you around still? Should we create an account for you? There
>> are
>> some bugs, which need attention from someone on Windows.
>
>
> Yeah trac pretty much still does not work for me. Now I can't even login
> anymore (wrong credentials), using "forgot password" it says that trac sent
> me a new one but I don't receive anything.
>
> We do not know why this is happening, but we can reset the password for
> you.
>
Yeah sure. Additionally if it is just gmail, maybe just update my account's
email address to yu_...@lyx.org? If that forwarding is still up.

> Actually, I just discovered some weird corruption in the password
> database. I've fixed that, so maybe it will work now?
>
No, I still can't login.

> Did you get the emails about beta2?
>
About beta2 all I got was #12630. Is there anything else I should have
gotten?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: trac & gmail

[Yu Jin]

Am Fr., 16. Juni 2023 um 13:28 Uhr schrieb Pavel Sanda:

> On Fri, Jun 16, 2023 at 10:53:39AM +0200, Pavel Sanda wrote:
> > I wonder whether our bug tracker notifications became essentialy
> unusable fro anyone having gmail address.
>
> I also figured out that whatever we sent to Eugene for windows OS in trac
> probably did not reach target, because I do not see his account (Yu_Jin) on
> trac. Either never was there or we lost it...
>
> Eugene, are you around still? Should we create an account for you? There
> are
> some bugs, which need attention from someone on Windows.


Yeah trac pretty much still does not work for me. Now I can't even login
anymore (wrong credentials), using "forgot password" it says that trac sent
me a new one but I don't receive anything.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 3 On FTP Now

[Yu Jin]

Am Do., 22. Juni 2023 um 17:28 Uhr schrieb Richard Kimberly Heck:

> I have gotten access to the ftp site again, so beta 3 has been uploaded
> there:
>
> http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please prepare binaries for release next week.


I have built and uploaded to my google drive folder as usual.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Include ".vs" in gitignore?

[Yu Jin]

Can we do that? Visual Studio always creates some files in the '.vs'
subfolder when I open the repository with it.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Windows-specific Python Packages and Preview

[Yu Jin]

Am So., 12. März 2023 um 21:27 Uhr schrieb Richard Kimberly Heck:

> On 3/12/23 09:06, Yu Jin wrote:
>
> Am So., 12. März 2023 um 01:43 Uhr schrieb Richard Kimberly Heck:
>
>> On 3/11/23 03:22, Yu Jin wrote:
>>
>> Am Sa., 11. März 2023 um 08:31 Uhr schrieb Yu Jin:
>>
>>> Am Sa., 11. März 2023 um 07:09 Uhr schrieb Richard Kimberly Heck:
>>>
>>>> On 3/10/23 17:04, Jean-Marc Lasgouttes wrote:
>>>> > Le 10/03/2023 à 22:21, Yu Jin a écrit :
>>>> >> all the win* imports from lyxpreview_tools.py fail, but those are in
>>>> >> a try-except block
>>>> >
>>>> > What do we gain when they ar present? It might be important enough to
>>>> > warrant having those modules.
>>>>
>>>>  try:
>>>>  import pywintypes
>>>>  import win32con
>>>>  import win32event
>>>>  import win32file
>>>>  import win32pipe
>>>>  import win32process
>>>>  import win32security
>>>>  import winerror
>>>>  except:
>>>>  sys.stderr.write("Consider installing the PyWin extension
>>>> modules " \
>>>>   "if you're irritated by windows appearing
>>>> briefly.\n")
>>>>
>>> Just checked, those imports also fail in the Python2 package which I've
>>> used so far.
>>>
>>
>> I have found a way of installing pywin32 into the embeddable package, it
>> is considered a hack on the web, because the embedded python is not meant
>> to be enhanced with more packages, but it works. With the pywin32 package
>> installed using that hack the imports work. But there are 2 things
>> resulting from the "hack":
>> 1. there is a bit of manual work to do when updating the python, I can
>> document it though, so not a big deal.
>>
>> That part seems fine.
>>
>>
>> 2. The python package gets significantly larger (50MB vs 18MB unzipped)
>> and also the LyX installer itself when finished (65MB vs. 55MB).
>>
>> Not a big deal either.
>>
>>
>> So what would you say? Is pywin32 needed or do I skip it?
>>
>> Did you see my message about what this is supposed to do? Suppress
>> certain windows (terminals, I guess) from appearing when we're doing
>> certain things? If so, perhaps it would be worth seeing just how annoying
>> those windows are. If the answer is "not very", then maybe it isn't worth
>> the trouble.
>>
> Yeah I could test that as well, I just don't know what those "certain
> things" are, what should I do for testing?
>
> It would presumably involve the scripts where these modules are called. It
> looks like it involves preview, possibly of images and PDFs, maybe of math
> too?
>
There is an example "Instant_Preview.lyx", I opened it, preview worked and
I did not see any windows appearing...
Also tried some previews in empty documents, like a pdf file and some basic
math, but no windows...
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am So., 12. März 2023 um 09:59 Uhr schrieb Yu Jin :

> Am So., 12. März 2023 um 03:37 Uhr schrieb Thibaut Cuvelier:
>
>> On Sun, 12 Mar 2023 at 03:25, Richard Kimberly Heck  wrote:
>>
>>> On 3/11/23 20:18, Thibaut Cuvelier wrote:
>>>
>>> On Sun, 12 Mar 2023 at 01:44, Richard Kimberly Heck wrote:
>>>
>>>> On 3/11/23 03:22, Yu Jin wrote:
>>>>
>>> So what would you say? Is pywin32 needed or do I skip it?
>>>>
>>>> Did you see my message about what this is supposed to do? Suppress
>>>> certain windows (terminals, I guess) from appearing when we're doing
>>>> certain things? If so, perhaps it would be worth seeing just how annoying
>>>> those windows are. If the answer is "not very", then maybe it isn't worth
>>>> the trouble.
>>>>
>>> For a typical Windows user, as I could see, having such windows
>>> appearing is associated with viruses. I'm not too fond of adding a message
>>> to the user saying that such windows are normal, they'd tend to think that
>>> LyX is poorly coded.
>>>
>>> Are you able to test with and without the PyWin packages?
>>>
>> I could with a recent installer for 2.4 (these modules don't appear in
>> the 2.3 package); I think I could just delete a bunch of files. Eugene,
>> could you provide me with that? Otherwise, I'll test with my local build
>> (hoping that my results are reproducible with the installer).
>>
> Sure, I just uploaded 2 signed Installers to google drive for you, you
> should have received a message from google a couple of minutes ago.
>
Oh, you might want to delete the file python311._pth inside the Python
folder, I just understood that it prevents loading custom modules if the
paths to those are not listed in it. Or you can put the paths to LyX'
modules manually in there, but I don't know which ones those are exactly,
so I think I'll just delete the file altogether in the future Windows
installers.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am So., 12. März 2023 um 01:43 Uhr schrieb Richard Kimberly Heck:

> On 3/11/23 03:22, Yu Jin wrote:
>
> Am Sa., 11. März 2023 um 08:31 Uhr schrieb Yu Jin:
>
>> Am Sa., 11. März 2023 um 07:09 Uhr schrieb Richard Kimberly Heck:
>>
>>> On 3/10/23 17:04, Jean-Marc Lasgouttes wrote:
>>> > Le 10/03/2023 à 22:21, Yu Jin a écrit :
>>> >> all the win* imports from lyxpreview_tools.py fail, but those are in
>>> >> a try-except block
>>> >
>>> > What do we gain when they ar present? It might be important enough to
>>> > warrant having those modules.
>>>
>>>  try:
>>>  import pywintypes
>>>  import win32con
>>>  import win32event
>>>  import win32file
>>>  import win32pipe
>>>  import win32process
>>>  import win32security
>>>  import winerror
>>>  except:
>>>  sys.stderr.write("Consider installing the PyWin extension
>>> modules " \
>>>   "if you're irritated by windows appearing
>>> briefly.\n")
>>>
>> Just checked, those imports also fail in the Python2 package which I've
>> used so far.
>>
>
> I have found a way of installing pywin32 into the embeddable package, it
> is considered a hack on the web, because the embedded python is not meant
> to be enhanced with more packages, but it works. With the pywin32 package
> installed using that hack the imports work. But there are 2 things
> resulting from the "hack":
> 1. there is a bit of manual work to do when updating the python, I can
> document it though, so not a big deal.
>
> That part seems fine.
>
>
> 2. The python package gets significantly larger (50MB vs 18MB unzipped)
> and also the LyX installer itself when finished (65MB vs. 55MB).
>
> Not a big deal either.
>
>
> So what would you say? Is pywin32 needed or do I skip it?
>
> Did you see my message about what this is supposed to do? Suppress certain
> windows (terminals, I guess) from appearing when we're doing certain
> things? If so, perhaps it would be worth seeing just how annoying those
> windows are. If the answer is "not very", then maybe it isn't worth the
> trouble.
>
Yeah I could test that as well, I just don't know what those "certain
things" are, what should I do for testing?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am So., 12. März 2023 um 03:37 Uhr schrieb Thibaut Cuvelier:

> On Sun, 12 Mar 2023 at 03:25, Richard Kimberly Heck  wrote:
>
>> On 3/11/23 20:18, Thibaut Cuvelier wrote:
>>
>> On Sun, 12 Mar 2023 at 01:44, Richard Kimberly Heck wrote:
>>
>>> On 3/11/23 03:22, Yu Jin wrote:
>>>
>> So what would you say? Is pywin32 needed or do I skip it?
>>>
>>> Did you see my message about what this is supposed to do? Suppress
>>> certain windows (terminals, I guess) from appearing when we're doing
>>> certain things? If so, perhaps it would be worth seeing just how annoying
>>> those windows are. If the answer is "not very", then maybe it isn't worth
>>> the trouble.
>>>
>> For a typical Windows user, as I could see, having such windows appearing
>> is associated with viruses. I'm not too fond of adding a message to the
>> user saying that such windows are normal, they'd tend to think that LyX is
>> poorly coded.
>>
>> Are you able to test with and without the PyWin packages?
>>
> I could with a recent installer for 2.4 (these modules don't appear in the
> 2.3 package); I think I could just delete a bunch of files. Eugene, could
> you provide me with that? Otherwise, I'll test with my local build (hoping
> that my results are reproducible with the installer).
>
Sure, I just uploaded 2 signed Installers to google drive for you, you
should have received a message from google a couple of minutes ago.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am Sa., 11. März 2023 um 08:31 Uhr schrieb Yu Jin:

> Am Sa., 11. März 2023 um 07:09 Uhr schrieb Richard Kimberly Heck:
>
>> On 3/10/23 17:04, Jean-Marc Lasgouttes wrote:
>> > Le 10/03/2023 à 22:21, Yu Jin a écrit :
>> >> all the win* imports from lyxpreview_tools.py fail, but those are in
>> >> a try-except block
>> >
>> > What do we gain when they ar present? It might be important enough to
>> > warrant having those modules.
>>
>>  try:
>>  import pywintypes
>>  import win32con
>>  import win32event
>>  import win32file
>>  import win32pipe
>>  import win32process
>>  import win32security
>>  import winerror
>>  except:
>>  sys.stderr.write("Consider installing the PyWin extension
>> modules " \
>>   "if you're irritated by windows appearing
>> briefly.\n")
>>
> Just checked, those imports also fail in the Python2 package which I've
> used so far.
>

I have found a way of installing pywin32 into the embeddable package, it is
considered a hack on the web, because the embedded python is not meant to
be enhanced with more packages, but it works. With the pywin32 package
installed using that hack the imports work. But there are 2 things
resulting from the "hack":
1. there is a bit of manual work to do when updating the python, I can
document it though, so not a big deal.
2. The python package gets significantly larger (50MB vs 18MB unzipped) and
also the LyX installer itself when finished (65MB vs. 55MB).
So what would you say? Is pywin32 needed or do I skip it?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am Sa., 11. März 2023 um 07:09 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> On 3/10/23 17:04, Jean-Marc Lasgouttes wrote:
> > Le 10/03/2023 à 22:21, Yu Jin a écrit :
> >> all the win* imports from lyxpreview_tools.py fail, but those are in
> >> a try-except block
> >
> > What do we gain when they ar present? It might be important enough to
> > warrant having those modules.
>
>  try:
>  import pywintypes
>  import win32con
>  import win32event
>  import win32file
>  import win32pipe
>  import win32process
>  import win32security
>  import winerror
>  except:
>  sys.stderr.write("Consider installing the PyWin extension
> modules " \
>   "if you're irritated by windows appearing
> briefly.\n")
>
Just checked, those imports also fail in the Python2 package which I've
used so far.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Include Python3 in the Windows installer

[Yu Jin]

Am Mi., 8. März 2023 um 14:49 Uhr schrieb Pavel Sanda:

>
> Another approach could be just collect all import lines from
> all scripts in lib/scripts and check they are within that minimal
> p3 install.
>
This sounds like a good idea, I just did that, there are quite a few
imports:

import os, re, subprocess, sys
import sys
from lyxpreview_tools import error, find_exe_or_terminate, run_command
from __future__ import print_function
import os, re, sys
import csv, unicodedata
import os, sys
import optparse
import subprocess
import os
import os.path
import re
import shutil
import sys
from __future__ import print_function
import glob
import os
import shutil
import sys
import tempfile
import zipfile
from io import open  # Required for Python 2.
import getopt, os, shutil, sys
from lyxpreview_tools import error
from __future__ import print_function
import sys,string,os
from __future__ import print_function
import os, sys
import shutil
import re
from __future__ import print_function
import os, sys, re
from __future__ import print_function
import os, sys
from subprocess import Popen, PIPE
from sys import argv, stderr, exit
import shutil
import os, string, sys, re
from lyxpreview_tools import error, run_command
from __future__ import print_function
import sys, os
import os, re, sys
import argparse
import glob, os, pipes, re, sys, tempfile
from lyxpreview_tools import check_latex_log, copyfileobj, error,
filter_pages, find_exe, find_exe_or_terminate, join_metrics_and_rename,
latex_commands, latex_file_re, make_texcolor, pdflatex_commands, progress,
run_command, run_latex, warning, write_metrics_info
from __future__ import print_function
import sys, string
from __future__ import print_function
import gzip, os, re, sys
from getopt import getopt
from io import BytesIO
from shutil import copyfile
from tempfile import NamedTemporaryFile
import zipfile
import tarfile
from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_int
from ctypes.wintypes import LPWSTR, LPCWSTR
import getopt, os, sys, subprocess
import os, re, subprocess, sys, tempfile
import pywintypes
import win32con
import win32event
import win32file
import win32pipe
import win32process
import win32security
import winerror
from __future__ import print_function
import getopt, glob, os, re, shutil, sys, tempfile
import lyxpreview_tools
from legacy_lyxpreview2ppm import extract_resolution,
legacy_conversion_step1
from lyxpreview_tools import bibtex_commands, check_latex_log, copyfileobj,
error, filter_pages, find_exe, find_exe_or_terminate,
join_metrics_and_rename, latex_commands, latex_file_re, make_texcolor,
pdflatex_commands, progress, run_command, run_latex, run_tex, warning,
write_metrics_info
import sys, re
import re
from __future__ import print_function
import os, re, string, sys
from getopt import getopt
import io
from prefs2prefs_lfuns import conversions
from prefs2prefs_prefs import conversions
import re
import sys
import subprocess
from __future__ import print_function
import os, sys, re, subprocess
from __future__ import print_function
import os, sys, re, subprocess
import os, string, sys
from lyxpreview_tools import error
from __future__ import print_function
import os, sys, re

a lot of those probably dupes, but there are also imports from lyx custom
modules, do I just ignore those? If so this is what the python command
prompt returns if I just paste all those imports (removed all lines
containing 'lyx') in it:
>>> import os, re, subprocess, sys
>>> import sys
>>> from __future__ import print_function
>>> import os, re, sys
>>> import csv, unicodedata
>>> import os, sys
>>> import optparse
>>> import subprocess
>>> import os
>>> import os.path
>>> import re
>>> import shutil
>>> import sys
>>> from __future__ import print_function
>>> import glob
>>> import os
>>> import shutil
>>> import sys
>>> import tempfile
>>> import zipfile
>>> from io import open
>>> import getopt, os, shutil, sys
>>> from __future__ import print_function
>>> import sys,string,os
>>> from __future__ import print_function
>>> import os, sys
>>> import shutil
>>> import re
>>> from __future__ import print_function
>>> import os, sys, re
>>> from __future__ import print_function
>>> import os, sys
>>> from subprocess import Popen, PIPE
>>> from sys import argv, stderr, exit
>>> import shutil
>>> import os, string, sys, re
>>> from __future__ import print_function
>>> import sys, os
>>> import os, re, sys
>>> import argparse
>>> import glob, os, pipes, re, sys, tempfile
:1: DeprecationWarning: 'pipes' is deprecated and slated for removal
in Python 3.13
>>> from __future__ import print_function
>>> import sys, string
>>> from __future__ import print_function
>>> import gzip, os, re, sys
>>> from getopt import getopt
>>> from io import BytesIO
>>> from shutil import copyfile
>>> from tempfile import NamedTemporaryFile
>>> import zipfile
>>> import tarfile
>>> from ctypes import WINFUNCTYPE, windll, POINTER, byref, c_int
>>> from ctypes.wintypes import LPWSTR, LPCWSTR
>>> import 

Include Python3 in the Windows installer

[Yu Jin]

I am probably a bit late on this, but Python2 like does not exist anymore,
so I am thinking on including python 3 in the installer. I have looked at
the download page for python and found Windows embeddable package (64-bit),
which is 8-10 MB small (depending on the version), I have looked into that
zip archive and seen that it does not look like a full python version like
what you would get when downloading the installer. So I want to check if I
can use this small package and if it will be "enough" for lyx' needs. Can
somebody tell me if there is a way I can test/assess it? I can produce 2
separate installers, one with the old python I still have and one with
python 3, I would also be able to install them separately on a local VM for
comparison, but I don't know what are the actual test scenarios, any ideas?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 2 Tarballs

[Yu Jin]

Am Mi., 11. Jan. 2023 um 19:45 Uhr schrieb Richard Kimberly Heck:

> Here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.4/
>
> Please produce binaries.


Done and uploaded to google drive.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.7 Tarballs Available

[Yu Jin]

Am Mo., 2. Jan. 2023 um 00:53 Uhr schrieb Richard Kimberly Heck:

> Here:
>
>  http://ftp.lyx.org/pub/lyx/devel/lyx-2.3/
>
> Note that I've named these files as 2.3.7-1, but did not do that in
> configure.ac, since we did not release anything yet.
>
> Please build binaries.
>

Works here.
Riki, I have set up a google drive share folder, please find it in your
google drive. You should also have gotten a message from google.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: State of Stable and Master?

[Yu Jin]

Am Sa., 17. Dez. 2022 um 20:43 Uhr schrieb Richard Kimberly Heck:

> Hi, all,
>
> In amongst the latest grading frenzy (thankfully coming to an end), I've
> lost track of where we are with 2.3.7 and 2.4-beta2. I know there were
> build issues of various kinds with both of them. Have these now been
> resolved? Or, at least, do we think they have? That is, are we ready to
> go with rebuilding and trying again?
>

>From my perspective for master yes, for stable I don't know, did somebody
fix the missing hunspell win_api config file?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am Fr., 16. Dez. 2022 um 21:47 Uhr schrieb Scott Kostyshak:

> On Fri, Dec 16, 2022 at 09:18:08PM +0100, Yu Jin wrote:
> > Done at 26a3a085
>
> Sorry for the late comment Yu Jin, but should that line be conditional
> on (not?) LYX_EXTERNAL_Z?
>
> I'm guessing that the answer is that it's only necessary if
> LYX_EXTERNAL_Z is OFF, but that if LYX_EXTERNAL_Z is ON, it doesn't
> hurt? If this is indeed the answer, I think I would still be in favor of
> adding the conditional, although not a strong opinion.


sounds plausible actually. How do I use external Zlib though? I mean Qt
does not seem to have a zlib.lib somewhere in the kit, so including Qts
zlib.h does not make sense then either. Would I have to compile my own
zlib.lib separately and use the corresponding zlib.h? Then I would also not
need QtZlib, indeed I would also get the same error if I compiled a
different zlib.lib version then Qts zlib.h... As I already wrote, the whole
thing seems kinda suspicious. The variable is called
_Qt6ZlibPrivate_OWN_INCLUDE_DIRS, "private" suggests like it is just for
Qt, not for the application which uses Qt (like LyX), so why does it
include it in LyX in the first place?
I mean I don't know, as I wrote my commit was a workaround rather than a
solution...
--
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am Fr., 16. Dez. 2022 um 09:16 Uhr schrieb Kornel Benko :

> Am Fri, 16 Dec 2022 07:37:00 +0100
> schrieb Yu Jin:
>
> > > Yes it does work, but actually I had a better idea to use
> > > ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead of
> "${CMAKE_PREFIX_PATH}/include/QtZlib",
> > > because it is in the variable already. I have sent a patch here:
> > > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218797.html
> can you test it
> > > again, it contains 2 more changes, but you can ignore those, they only
> affect
> > > wininstaller. Then I can push it if it still works for linux.
> > >
> > Here is a separate patch for just the CMake part.
> >
>
> +1 to commit


Done at 26a3a085
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am Do., 15. Dez. 2022 um 22:54 Uhr schrieb Yu Jin :

> Am Mi., 14. Dez. 2022 um 19:50 Uhr schrieb Scott Kostyshak <
> skost...@lyx.org>:
>
>> On Sat, Dec 10, 2022 at 05:09:46PM +0100, Kornel Benko wrote:
>> > Am Sat, 10 Dec 2022 15:38:43 +0100
>> > schrieb Yu Jin :
>> >
>> > > Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko <
>> kor...@lyx.org>:
>> > >
>> > > > Am Thu, 8 Dec 2022 09:52:29 -0500
>> > > > schrieb Scott Kostyshak :
>> > > >
>> > > > > On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
>> > > > > > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda <
>> sa...@lyx.org>:
>> > > > > >
>> > > > > > >
>> > > > > > > Given that on major linux distributions will still link
>> against qt5
>> > > > > > > I think stikcing for 2.4 with Qt 5 is just fine...
>> > > > > >
>> > > > > >
>> > > > > > I think my curiosity helped here :)
>> > > > > >
>> > > > > > So I found out that there is different version of zlib in the Qt
>> > > > versions,
>> > > > > > the working Qt has a version 1.2.11 (I can see it in the zlib.h
>> in e.g.
>> > > > > > C:\Qt\6.3.1\msvc2019_64\include\QtZlib folder and the broken Qt
>> > > > Versions
>> > > > > > have 1.2.12 or 13.
>> > > > > > I digged a bit more and found that our projects in Visual Studio
>> > > > include
>> > > > > > those QtZlib folders for some reason:
>> > > > > > and lyx's zlib folder gets included further below which means
>> it has
>> > > > lower
>> > > > > > priority. If I just remove the QtZlib include from the project,
>> > > > compilation
>> > > > > > works. Can we do something in CMake here so that QtZlib is not
>> > > > included?
>> > > > >
>> > > > > CC'ing Kornel if he has time to take a look at the CMake question.
>> > > > >
>> > > > > Scott
>> > > >
>> > > > I really have no idea. I don't even have QtZlib directory on my
>> system.
>> > > > Even searching with 'apt-file find QtZlib'
>> > > >
>> > > > Ok so i found out that QtZlib is a dependency of QtCore and QtCore
>> is a
>> > > dependency of Qt6Core5Compat. Since we have
>> > > include_directories(${Qt6Core5Compat_INCLUDE_DIRS})
>> > >
>> > >
>> https://git.lyx.org/?p=lyx.git;a=blob;f=CMakeLists.txt;h=4a9c428d4a48c838f9e9cd61fab59c46a330b1b3;hb=HEAD#l837
>> > >
>> > > It includes those dirs. I don't know it does seem kinda suspicious to
>> me,
>> > > because actually Qt forces everyone who needs Core to use QtZlib with
>> that,
>> > > but I can't evaluate that. I just tried to add a
>> > > list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
>> > > "C:/Qt/6.4.1/msvc2019_64/include/QtZlib")
>> > > just before that include_directories command and it works
>> > > perfectly fine, everything compiles and runs as it should. With Qt5 it
>> > > works fine because we don't include any dirs there but we do with that
>> > > compatibility module.
>> > > What we could do is use this command:
>> > > list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
>> > > "${CMAKE_PREFIX_PATH}/include/QtZlib")
>> > > but it would rather be a workaround than a solution. Any thoughts?
>> >
>> > If this works for you, then I have no objection.
>> > Works for debian (it is noop there).
>>
>> Yu Jin, does Kornel's patch indeed work for you? Even though it is a
>> workaround, since we don't have a better fix let's just go for it if it
>> works for you?
>>
>
> Yes it does work, but actually I had a better idea to
> use ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead of
> "${CMAKE_PREFIX_PATH}/include/QtZlib", because it is in the variable
> already. I have sent a patch here:
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218797.html
> can you test it again, it contains 2 more changes, but you can ignore
> those, they only affect wininstaller.
> Then I can push it if it still works for linux.
>

Here is a separate patch for just the CMake part.

-- 
  Eugene


qtzlibinc.diff
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 2 Tarballs

[Yu Jin]

Am Fr., 16. Dez. 2022 um 00:46 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> On 12/15/22 13:25, Yu Jin wrote:
>
> Am Do., 15. Dez. 2022 um 06:38 Uhr schrieb Yu Jin  >:
>
>> Am Mi., 14. Dez. 2022 um 20:05 Uhr schrieb Richard Kimberly Heck :
>>
>>> So it's just 2.3.7 that doesn't work?
>>>
>>>
>>> Yes
>>
>
> Actually, if you are going to make these again, can you please include the
> attached patch? It fixes the QtZlib issue with Qt6 on Windows and
> apparently the LyX needs 2 more dll now, I tested it on a fresh installed
> Windows, so I fixed the main.nsh file, I will push those to master later.
>
> I think I forgot to mention here that this patch is for the beta tarballs,
not 2.3.7 ones, since you mentioned that you will build beta again too.

> You can push it, yes? Or are you still having access problems?
>
> This doesn't seem to apply here. I get:
>
> ../lyx/lyx-stable/ [⚡ 2.3.x] > git apply beta.diff
> error: patch failed: CMakeLists.txt:834
> error: CMakeLists.txt: patch does not apply
> error: development/Win32/packaging/installer/src/main.nsh: No such file or
> direc
> tory
>
I just pushed the wininstaller part to master, for the cmake part Im
waiting for feedback in another thread.
Yeah you are in the 2.3.x branch there, it still has the "old" installer,
It was never backported, I think because there was no plan on releasing
2.3.7 (and 2.3.6?) initially, so I just compiled the nsis script from
master pointing it to the files in the other (2.3.x) build folder.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am Mi., 14. Dez. 2022 um 19:50 Uhr schrieb Scott Kostyshak :

> On Sat, Dec 10, 2022 at 05:09:46PM +0100, Kornel Benko wrote:
> > Am Sat, 10 Dec 2022 15:38:43 +0100
> > schrieb Yu Jin :
> >
> > > Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko  >:
> > >
> > > > Am Thu, 8 Dec 2022 09:52:29 -0500
> > > > schrieb Scott Kostyshak :
> > > >
> > > > > On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> > > > > > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda <
> sa...@lyx.org>:
> > > > > >
> > > > > > >
> > > > > > > Given that on major linux distributions will still link
> against qt5
> > > > > > > I think stikcing for 2.4 with Qt 5 is just fine...
> > > > > >
> > > > > >
> > > > > > I think my curiosity helped here :)
> > > > > >
> > > > > > So I found out that there is different version of zlib in the Qt
> > > > versions,
> > > > > > the working Qt has a version 1.2.11 (I can see it in the zlib.h
> in e.g.
> > > > > > C:\Qt\6.3.1\msvc2019_64\include\QtZlib folder and the broken Qt
> > > > Versions
> > > > > > have 1.2.12 or 13.
> > > > > > I digged a bit more and found that our projects in Visual Studio
> > > > include
> > > > > > those QtZlib folders for some reason:
> > > > > > and lyx's zlib folder gets included further below which means it
> has
> > > > lower
> > > > > > priority. If I just remove the QtZlib include from the project,
> > > > compilation
> > > > > > works. Can we do something in CMake here so that QtZlib is not
> > > > included?
> > > > >
> > > > > CC'ing Kornel if he has time to take a look at the CMake question.
> > > > >
> > > > > Scott
> > > >
> > > > I really have no idea. I don't even have QtZlib directory on my
> system.
> > > > Even searching with 'apt-file find QtZlib'
> > > >
> > > > Ok so i found out that QtZlib is a dependency of QtCore and QtCore
> is a
> > > dependency of Qt6Core5Compat. Since we have
> > > include_directories(${Qt6Core5Compat_INCLUDE_DIRS})
> > >
> > >
> https://git.lyx.org/?p=lyx.git;a=blob;f=CMakeLists.txt;h=4a9c428d4a48c838f9e9cd61fab59c46a330b1b3;hb=HEAD#l837
> > >
> > > It includes those dirs. I don't know it does seem kinda suspicious to
> me,
> > > because actually Qt forces everyone who needs Core to use QtZlib with
> that,
> > > but I can't evaluate that. I just tried to add a
> > > list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
> > > "C:/Qt/6.4.1/msvc2019_64/include/QtZlib")
> > > just before that include_directories command and it works
> > > perfectly fine, everything compiles and runs as it should. With Qt5 it
> > > works fine because we don't include any dirs there but we do with that
> > > compatibility module.
> > > What we could do is use this command:
> > > list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
> > > "${CMAKE_PREFIX_PATH}/include/QtZlib")
> > > but it would rather be a workaround than a solution. Any thoughts?
> >
> > If this works for you, then I have no objection.
> > Works for debian (it is noop there).
>
> Yu Jin, does Kornel's patch indeed work for you? Even though it is a
> workaround, since we don't have a better fix let's just go for it if it
> works for you?
>

Yes it does work, but actually I had a better idea to
use ${_Qt6ZlibPrivate_OWN_INCLUDE_DIRS} instead of
"${CMAKE_PREFIX_PATH}/include/QtZlib", because it is in the variable
already. I have sent a patch here:
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg218797.html
can you test it again, it contains 2 more changes, but you can ignore
those, they only affect wininstaller.
Then I can push it if it still works for linux.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 2 Tarballs

[Yu Jin]

Am Do., 15. Dez. 2022 um 06:38 Uhr schrieb Yu Jin :

> Am Mi., 14. Dez. 2022 um 20:05 Uhr schrieb Richard Kimberly Heck :
>
>> So it's just 2.3.7 that doesn't work?
>>
>>
>> Yes
>

Actually, if you are going to make these again, can you please include the
attached patch? It fixes the QtZlib issue with Qt6 on Windows and
apparently the LyX needs 2 more dll now, I tested it on a fresh installed
Windows, so I fixed the main.nsh file, I will push those to master later.

-- 
  Eugene


beta.diff
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 2 Tarballs

[Yu Jin]

Am Mi., 14. Dez. 2022 um 20:05 Uhr schrieb Richard Kimberly Heck :

> So it's just 2.3.7 that doesn't work?
>
>
> Yes


-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.7 Tarballs

[Yu Jin]

Am Di., 13. Dez. 2022 um 17:46 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> On 12/12/22 16:35, Yu Jin wrote:
>
> Am So., 11. Dez. 2022 um 17:16 Uhr schrieb Richard Kimberly Heck <
> rikih...@gmail.com>:
>
>> Tarballs for 2.3.7 are here:
>>
>> http://www.frege.org/transfer/
>>
>> Because my IP has changed, I can't (right now) upload them to the ftp
>> server. I'll do that when I can.
>>
>> Please build the binaries!
>>
>> Does not work here unfortunately, CMake  error when generating Visual
> Studio solution:
>
> CMake Error at 3rdparty/hunspell/CMakeLists.txt:50 (add_library):
>   Cannot find source file:
>
> C:/lyx/lyx-2.3.7/3rdparty/hunspell/1.7.0/src/win_api/config.h
>
>   Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm
> .h
>   .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc
>
>
> CMake Error at 3rdparty/hunspell/CMakeLists.txt:50 (add_library):
>   No SOURCES given to target: hunspell
>
> I just checked win_api folder does not exist in
> 3rdparty/hunspell/1.7.0/src
>
> Does Kornel's patch for master fix this?
>
It probably won't as I don't have this issue with master.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 2 Tarballs

[Yu Jin]

Am Di., 13. Dez. 2022 um 17:45 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> On 12/12/22 04:01, Kornel Benko wrote:
> > Am Sun, 11 Dec 2022 21:14:47 -0500
> > schrieb Scott Kostyshak :
> >
> >> On Sun, Dec 11, 2022 at 08:50:46PM +0100, Pavel Sanda wrote:
> >>> On Sun, Dec 11, 2022 at 11:37:02AM -0500, Richard Kimberly Heck wrote:
>  Tarballs for beta 2 are at:
> 
>  http://www.frege.org/transfer/
> 
>  Let's test these a bit before proceeding to binaries. (Also, of
> course, we
>  have 2.3.7 to deal with.)
> >>> On a first sight seem to work as well... P
> >> Same here.
> >>
> >> Only thing I noticed is that if I try to build with CMake there is an
> issue:
> >>
> >> CMake Error: File
> >> /home/scott/Downloads/temp/lyx-2.4.0-beta2/development/unix/
> lyxrc.dist.in does not
> >> exist. CMake Error at development/cmake/Install.cmake:175
> (configure_file):
> >> configure_file Problem configuring file Call Stack (most recent call
> first):
> >>CMakeLists.txt:1204 (include)
> >>
> >> I'll see Kornel to see if he has an idea.
> >>
> >> Scott
> > Maybe missing from dist target.
>
> If someone can confirm that this solves the problem, I'll commit and
> rebuild.
>

These sources work for me without any patch, lyx compiles.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.7 Tarballs

[Yu Jin]

Am So., 11. Dez. 2022 um 17:16 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> Tarballs for 2.3.7 are here:
>
> http://www.frege.org/transfer/
>
> Because my IP has changed, I can't (right now) upload them to the ftp
> server. I'll do that when I can.
>
> Please build the binaries!
>
> Does not work here unfortunately, CMake  error when generating Visual
Studio solution:

CMake Error at 3rdparty/hunspell/CMakeLists.txt:50 (add_library):
  Cannot find source file:

C:/lyx/lyx-2.3.7/3rdparty/hunspell/1.7.0/src/win_api/config.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h
  .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc


CMake Error at 3rdparty/hunspell/CMakeLists.txt:50 (add_library):
  No SOURCES given to target: hunspell

I just checked win_api folder does not exist in 3rdparty/hunspell/1.7.0/src
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am Do., 8. Dez. 2022 um 16:11 Uhr schrieb Kornel Benko :

> Am Thu, 8 Dec 2022 09:52:29 -0500
> schrieb Scott Kostyshak :
>
> > On Mon, Dec 05, 2022 at 10:15:18PM +0100, Yu Jin wrote:
> > > Am Mo., 5. Dez. 2022 um 10:39 Uhr schrieb Pavel Sanda :
> > >
> > > >
> > > > Given that on major linux distributions will still link against qt5
> > > > I think stikcing for 2.4 with Qt 5 is just fine...
> > >
> > >
> > > I think my curiosity helped here :)
> > >
> > > So I found out that there is different version of zlib in the Qt
> versions,
> > > the working Qt has a version 1.2.11 (I can see it in the zlib.h in e.g.
> > > C:\Qt\6.3.1\msvc2019_64\include\QtZlib folder and the broken Qt
> Versions
> > > have 1.2.12 or 13.
> > > I digged a bit more and found that our projects in Visual Studio
> include
> > > those QtZlib folders for some reason:
> > > and lyx's zlib folder gets included further below which means it has
> lower
> > > priority. If I just remove the QtZlib include from the project,
> compilation
> > > works. Can we do something in CMake here so that QtZlib is not
> included?
> >
> > CC'ing Kornel if he has time to take a look at the CMake question.
> >
> > Scott
>
> I really have no idea. I don't even have QtZlib directory on my system.
> Even searching with 'apt-file find QtZlib'
>
> Ok so i found out that QtZlib is a dependency of QtCore and QtCore is a
dependency of Qt6Core5Compat. Since we have
include_directories(${Qt6Core5Compat_INCLUDE_DIRS})

https://git.lyx.org/?p=lyx.git;a=blob;f=CMakeLists.txt;h=4a9c428d4a48c838f9e9cd61fab59c46a330b1b3;hb=HEAD#l837

It includes those dirs. I don't know it does seem kinda suspicious to me,
because actually Qt forces everyone who needs Core to use QtZlib with that,
but I can't evaluate that. I just tried to add a
list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
"C:/Qt/6.4.1/msvc2019_64/include/QtZlib")
just before that include_directories command and it works
perfectly fine, everything compiles and runs as it should. With Qt5 it
works fine because we don't include any dirs there but we do with that
compatibility module.
What we could do is use this command:
list(REMOVE_ITEM Qt6Core5Compat_INCLUDE_DIRS
"${CMAKE_PREFIX_PATH}/include/QtZlib")
but it would rather be a workaround than a solution. Any thoughts?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: master compile errors gzlib?

[Yu Jin]

Am So., 4. Dez. 2022 um 20:03 Uhr schrieb Pavel Sanda :

> Did you update gzlib or compiler?
>

No, it I just tried to compile with Qt5 though, it works, only Qt6
doesn't... I don't understand why, I even tried to update to zlib 1.2.13,
but no success.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

master compile errors gzlib?

[Yu Jin]

I can't build master currently on Windows, I get these errors:

Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzread" in Funktion ""public: virtual int __cdecl
gz::gzstreambuf::underflow(void)" (?underflow@gzstreambuf@gz@@UEAAHXZ)".
check_layout C:\lyx\masterbuild64Qt6\src\tests\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzwrite" in Funktion ""private: int __cdecl
gz::gzstreambuf::flush_buffer(void)" (?flush_buffer@gzstreambuf@gz@@AEAAHXZ)".
check_layout C:\lyx\masterbuild64Qt6\src\tests\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzclose" in Funktion ""public: virtual __cdecl
gz::gzstreambase::~gzstreambase(void)" (??1gzstreambase@gz@@UEAA@XZ)".
check_layout C:\lyx\masterbuild64Qt6\src\tests\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzopen" in Funktion ""public: __cdecl
gz::gzstreambase::gzstreambase(char const *,int)" (??0gzstreambase@gz
@@QEAA@PEBDH@Z)". check_layout
C:\lyx\masterbuild64Qt6\src\tests\support.lib(gzstream.obj) 1
Fehler LNK1120 4 nicht aufgelöste Externe check_layout
C:\lyx\masterbuild64Qt6\bin\Release\check_layout.exe 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzread" in Funktion ""public: virtual int __cdecl
gz::gzstreambuf::underflow(void)" (?underflow@gzstreambuf@gz@@UEAAHXZ)".
tex2lyx (applications\TeX2LyX\tex2lyx)
C:\lyx\masterbuild64Qt6\src\tex2lyx\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzwrite" in Funktion ""private: int __cdecl
gz::gzstreambuf::flush_buffer(void)" (?flush_buffer@gzstreambuf@gz@@AEAAHXZ)".
tex2lyx (applications\TeX2LyX\tex2lyx)
C:\lyx\masterbuild64Qt6\src\tex2lyx\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzclose" in Funktion ""public: virtual __cdecl
gz::gzstreambase::~gzstreambase(void)" (??1gzstreambase@gz@@UEAA@XZ)".
tex2lyx (applications\TeX2LyX\tex2lyx)
C:\lyx\masterbuild64Qt6\src\tex2lyx\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzopen" in Funktion ""public: __cdecl
gz::gzstreambase::gzstreambase(char const *,int)" (??0gzstreambase@gz
@@QEAA@PEBDH@Z)". tex2lyx (applications\TeX2LyX\tex2lyx)
C:\lyx\masterbuild64Qt6\src\tex2lyx\support.lib(gzstream.obj) 1
Fehler LNK1120 4 nicht aufgelöste Externe tex2lyx
(applications\TeX2LyX\tex2lyx)
C:\lyx\masterbuild64Qt6\bin\Release\tex2lyx.exe 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzread" in Funktion ""public: virtual int __cdecl
gz::gzstreambuf::underflow(void)" (?underflow@gzstreambuf@gz@@UEAAHXZ)".
LyX (applications\LyX\LyX)
C:\lyx\masterbuild64Qt6\src\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzwrite" in Funktion ""private: int __cdecl
gz::gzstreambuf::flush_buffer(void)" (?flush_buffer@gzstreambuf@gz@@AEAAHXZ)".
LyX (applications\LyX\LyX)
C:\lyx\masterbuild64Qt6\src\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzclose" in Funktion ""public: virtual __cdecl
gz::gzstreambase::~gzstreambase(void)" (??1gzstreambase@gz@@UEAA@XZ)". LyX
(applications\LyX\LyX)
C:\lyx\masterbuild64Qt6\src\support.lib(gzstream.obj) 1
Fehler LNK2019 Verweis auf nicht aufgelöstes externes Symbol
"__imp_z_gzopen" in Funktion ""public: __cdecl
gz::gzstreambase::gzstreambase(char const *,int)" (??0gzstreambase@gz
@@QEAA@PEBDH@Z)". LyX (applications\LyX\LyX)
C:\lyx\masterbuild64Qt6\src\support.lib(gzstream.obj) 1
Fehler LNK1120 4 nicht aufgelöste Externe LyX (applications\LyX\LyX)
C:\lyx\masterbuild64Qt6\bin\Release\LyX.exe 1

any ideas?
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Baby steps towards more frequent major releases

[Yu Jin]

Am Mo., 28. Nov. 2022 um 10:19 Uhr schrieb Pavel Sanda :

>
> Where it would be perhaps more useful is Windows/Mac platforms,
> but esp. in Win world we are nowhere close to an automatic builds
> (am I correct Eugene?)
>

I think it might be possible, running the compiler from the command line in
windows should be no problem, also copy the files from Qt and the
dependencies with a script, also let it run NSIS and basically done. There
are just a few variables that would change. Unfortunately I have no idea
about CI build pipelines.
-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: 2.3.7 Bugs

[Yu Jin]

Am Mi., 23. Nov. 2022 um 03:40 Uhr schrieb Richard Kimberly Heck <
rikih...@gmail.com>:

> I've gone through the bugs with 2.3.7 milestones and backported the ones
> that applied cleanly. There were a few that did not on which I've asked
> for help. Once all that's sorted out, I can build the tarballs.
>
> Is Eugene still around? He was building the Windows installers not long
> ago. If not, is there someone who can build them? I do have access to a
> Windows machine now (I've started using Ableton Live, so needed one), so
> I could do it, but it would take time for me to figure out the process
> again.
>
> Yes, I am around. I will build as before.

-- 
  Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX 2.4.0

[Yu Jin]

Am Do., 2. Dez. 2021 um 06:54 Uhr schrieb Jürgen Spitzmüller :

> Am Mittwoch, dem 01.12.2021 um 16:48 -0500 schrieb Richard Kimberly
> Heck:
> > Hi, all,
> >
> > Things got a bit crazy again, but I now should have a bit of time.
> > Where do people think we stand with 2.4.0? I've seen a bit of
> > activity in the interim. Do we need to do one more alpha? Or should
> > we proceed directly to beta 1?
>
> Go beta. And call feature freeze.
>

I thought we already had beta 

https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg216160.html
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Qt6 sets UNICODE on Windows

[Yu Jin]

Am Mo., 31. Mai 2021 um 16:42 Uhr schrieb Pavel Sanda :

> On Sat, May 29, 2021 at 06:47:05PM +0200, Yu Jin wrote:
> > > But I also think that the "universal" function calls (CreateNamedPipe()
> > > and WaitNamedPipe()) should be made specific (CreateNamedPipeA() and
> > > WaitNamedPipeA()), because the arguments are also specific (c_str()
> always
> > > returns const char*). I have attached the patch showing it, the patch
> alone
> > > fixes the compilation with unicode definition (can I commit it?). Once
> Qt
> > > 6.1.1 releases though, I will create a patch to disable unicode in
> CMake
> > > again.
> > >
> > Forgot the patch.
>
> It's inside _WIN32 section, thus safe for other archs. So I'd say go on
> and commit. :)
>

Thanks, Qt 6.1.1 released today, as mentioned I have prepared the patch for
CMake, please review. I have tested successfully with both Qt6 and Qt5. On
Qt5 it does nothing, because the property did not exist back then I guess.
Note: With this version Qt6 sets UNICODE for basically everything now, so
also libraries and console applications, so the patch deactivates it for
all main targets.
-- 
Eugene


file.diff
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Qt6 sets UNICODE on Windows

[Yu Jin]

Am Sa., 29. Mai 2021 um 18:43 Uhr schrieb Yu Jin :

> Am Sa., 29. Mai 2021 um 10:57 Uhr schrieb Yu Jin :
>
>>
>>
>> Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko :
>>
>>> Am Sat, 29 May 2021 09:56:06 +0200
>>> schrieb Yu Jin :
>>>
>>> > this is connected to the Beta 1 tarballs, trying to build LyX I
>>> stumbled
>>> > across this:
>>> > [image: grafik.png]
>>> > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when
>>> > configuring without LYX_CONSOLE. It does that by setting the character
>>> set
>>> > to Unicode (as shown in the screenshot above) and it also sets the
>>> > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does
>>> not do
>>> > that. I have just tried to manually change the character set and remove
>>> > those definitions in Visual Studio and it worked just fine. Any Idea if
>>> > this is intended by us or how we can prevent it? Maybe in CMake?
>>>
>>> The only setting for UNICODE i see is in
>>> development/Win32/vld/cmake/CMakeLists.txt
>>> This is used, if LYX_VLD is set. But this should be OFF on default.
>>>
>>
>> Thank you for your response. Actually it is Qt6 after all, I just tested
>> on a minimal example, it seems that Windows GUI applications are indeed
>> defaulted to UNICODE on Qt6. I also just found in the keynote here:
>> https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf
>>
>> QtCore classes can now only deal with Unicode encodings
>> –For other encodings: QTextCodec in Qt5Compat
>>
>> Don't really understand what that really means for LyX. But Qt5Compat is
>> used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE
>> default can be deactivated.
>>
>
> There was a bug report already:
> https://bugreports.qt.io/browse/QTBUG-89951
> apparently the unicode default will stay for all WIN32 (Windows GUI)
> applications and it will be possible to disable only with the next (6.1.1)
> release.
>
> But I also think that the "universal" function calls (CreateNamedPipe()
> and WaitNamedPipe()) should be made specific (CreateNamedPipeA() and
> WaitNamedPipeA()), because the arguments are also specific (c_str() always
> returns const char*). I have attached the patch showing it, the patch alone
> fixes the compilation with unicode definition (can I commit it?). Once Qt
> 6.1.1 releases though, I will create a patch to disable unicode in CMake
> again.
>
Forgot the patch.
-- 
Eugene


file.diff
Description: Binary data
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Qt6 sets UNICODE on Windows

[Yu Jin]

Am Sa., 29. Mai 2021 um 10:57 Uhr schrieb Yu Jin :

>
>
> Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko :
>
>> Am Sat, 29 May 2021 09:56:06 +0200
>> schrieb Yu Jin :
>>
>> > this is connected to the Beta 1 tarballs, trying to build LyX I stumbled
>> > across this:
>> > [image: grafik.png]
>> > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when
>> > configuring without LYX_CONSOLE. It does that by setting the character
>> set
>> > to Unicode (as shown in the screenshot above) and it also sets the
>> > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does
>> not do
>> > that. I have just tried to manually change the character set and remove
>> > those definitions in Visual Studio and it worked just fine. Any Idea if
>> > this is intended by us or how we can prevent it? Maybe in CMake?
>>
>> The only setting for UNICODE i see is in
>> development/Win32/vld/cmake/CMakeLists.txt
>> This is used, if LYX_VLD is set. But this should be OFF on default.
>>
>
> Thank you for your response. Actually it is Qt6 after all, I just tested
> on a minimal example, it seems that Windows GUI applications are indeed
> defaulted to UNICODE on Qt6. I also just found in the keynote here:
> https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf
>
> QtCore classes can now only deal with Unicode encodings
> –For other encodings: QTextCodec in Qt5Compat
>
> Don't really understand what that really means for LyX. But Qt5Compat is
> used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE
> default can be deactivated.
>

There was a bug report already:
https://bugreports.qt.io/browse/QTBUG-89951
apparently the unicode default will stay for all WIN32 (Windows GUI)
applications and it will be possible to disable only with the next (6.1.1)
release.

But I also think that the "universal" function calls (CreateNamedPipe() and
WaitNamedPipe()) should be made specific (CreateNamedPipeA() and
WaitNamedPipeA()), because the arguments are also specific (c_str() always
returns const char*). I have attached the patch showing it, the patch alone
fixes the compilation with unicode definition (can I commit it?). Once Qt
6.1.1 releases though, I will create a patch to disable unicode in CMake
again.
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Qt6 sets UNICODE on Windows

[Yu Jin]

Am Sa., 29. Mai 2021 um 10:22 Uhr schrieb Kornel Benko :

> Am Sat, 29 May 2021 09:56:06 +0200
> schrieb Yu Jin :
>
> > this is connected to the Beta 1 tarballs, trying to build LyX I stumbled
> > across this:
> > [image: grafik.png]
> > Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when
> > configuring without LYX_CONSOLE. It does that by setting the character
> set
> > to Unicode (as shown in the screenshot above) and it also sets the
> > "UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does not
> do
> > that. I have just tried to manually change the character set and remove
> > those definitions in Visual Studio and it worked just fine. Any Idea if
> > this is intended by us or how we can prevent it? Maybe in CMake?
>
> The only setting for UNICODE i see is in
> development/Win32/vld/cmake/CMakeLists.txt
> This is used, if LYX_VLD is set. But this should be OFF on default.
>

Thank you for your response. Actually it is Qt6 after all, I just tested on
a minimal example, it seems that Windows GUI applications are indeed
defaulted to UNICODE on Qt6. I also just found in the keynote here:
https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf

QtCore classes can now only deal with Unicode encodings
–For other encodings: QTextCodec in Qt5Compat

Don't really understand what that really means for LyX. But Qt5Compat is
used, so I hope it will be fine. I will ask in the Qt Forum how the UNICODE
default can be deactivated.
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Beta 1

[Yu Jin]

Am Do., 27. Mai 2021 um 22:49 Uhr schrieb Yu Jin :

> Am Do., 27. Mai 2021 um 20:17 Uhr schrieb Yu Jin :
>
>> Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck <
>> rikih...@lyx.org>:
>>
>>> Hi, all,
>>>
>>> I have put tarballs for beta 1 here:
>>>
>>>
>>> https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing
>>>
>>> I need to get my IP updated with our FTP people before I can upload
>>> again to ftp.lyx.org. Usually that does not take too long. In any
>>> event,
>>> please prepare binaries, and I'll release later this week.
>>>
>>
>> Unfortunately these don't compile for me, I get these errors:
>>
>> Severity Code Description Project File Line Suppression State
>> Error C2664 'BOOL WaitNamedPipeW(LPCWSTR,DWORD)': cannot convert argument
>> 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX)
>> C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 530
>> Error C2664 'HANDLE
>> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)':
>> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX
>> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 178
>> Error C2664 'HANDLE
>> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)':
>> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX
>> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 492
>>
>> Only occurs when LYX_CONSOLE is disabled though, which is what we want
>> for the beta release.
>>
> Ah, I see, it's because of the
>
> UNICODE
> _UNICODE
>
> preprocessor definitions What to do about that then?
>
I removed those for these tarballs (see also the other thread which I just
started) and successfully built LyX, so Uploaded the installer as usual
(only 64 bit, as mentioned earlier). I guess this is a good time to see how
Qt6 goes, since it is a beta. If people ask for 32 bit, I can still build
it later. Hopefully the UNICODE thing gets resolved until the next
release/beta.
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Qt6 sets UNICODE on Windows

[Yu Jin]

this is connected to the Beta 1 tarballs, trying to build LyX I stumbled
across this:
[image: grafik.png]
Apparently Qt6 sets UNICODE and _UNICODE on LyX (and only on LyX) when
configuring without LYX_CONSOLE. It does that by setting the character set
to Unicode (as shown in the screenshot above) and it also sets the
"UNICODE" and "_UNICODE" preprocessor definitions manually. Qt5 does not do
that. I have just tried to manually change the character set and remove
those definitions in Visual Studio and it worked just fine. Any Idea if
this is intended by us or how we can prevent it? Maybe in CMake?
-- 
Eugene
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel