Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/21/2018 03:12 PM, Kornel Benko wrote:
>
> Am Montag, 21. Mai 2018 12:25:00 CEST schrieb Richard Kimberly Heck
> :
>
> > On 05/21/2018 11:47 AM, Kornel Benko wrote:
>
> > >
>
> > > Am Montag, 21. Mai 2018 11:21:30 CEST schrieb Richard Kimberly Heck
>
> > > :
>
> > >
>
> > > > On 05/19/2018 01:48 PM, Kornel Benko wrote:
>
> > >
>
> > > > >
>
> > >
>
> > > > > Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller
>
> > >
>
> > > > > :
>
> > >
>
> > > > >
>
> > >
>
> > > > > > Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen
>
> > > Spitzmüller 
> > >
>
> > > > >
>
> > >
>
> > > > > > > i...@lyx.org>:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel
> Benko:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > No, it does not. For windows it is using
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > 'development/cmake/lyx.rc'.
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > But, for reason I don't
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > understand, the icon creation is explicitly disabled
> if using
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > mingw.
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > See src/CMakeLists.txt:97
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > if(WIN32 AND NOT MINGW)
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > message(STATUS "Using icon defined in resource file:
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > ${FILE_RC}")
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > endif()
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > Is this relevant?
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > https://stackoverflow.com/questions/3526794/
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > Jürgen
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > > > Kornel
>
> > >
>
> > > > >
>
> > >
>
> > > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > It is. Since we are compiling with mingw, both WIN32 and
> MINGW are
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > set.
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > In this case is FILE_RC not set, so that LyX.exe is not
>
> > > dependent on
>
> > >
>
> > > > >
>
> > >
>
> > > > > > > lyx.rc.
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > I meant whether the stackexchange threat I posted was relevant,
>
> > > since
>
> > >
>
> > > > >
>
> > >
>
> > > > > > it deals with some setting that needs to be done for windres
>
> > > with MinGW
>
> > >
>
> > > > >
>
> > >
>
> > > > > > and cmake.
>
> > >
>
> > > > >
>
> > >
>
> > > > > >
>
> > >
>
> > > > >
>
> > >
>
> > > > > > Jürgen
>
> > >
>
> > > > >
>
> > >
>
> > > > >  
>
> > >
>
> > > > >
>
> > >
>
> > > > > Ah, OK. Should be doable that way. Provided one has windres. In my
>
> > >
>
> > > > > case, although ubuntu is based on debian,
>
> > >
>
> > > > >
>
> > >
>
> > > > > I don't get it through standard package sources.
>
> > >
>
> > > > >
>
> > >
>
> > > >
>
> > >
>
> > > > I seem to have windres, actually, though under a slightly different
>
> > >
>
> > > > name. It's part of the mingw32-binutils package, but is installed as
>
> > >
>
> > > > /usr/bin/i686-w64-mingw32-windres. There is code in
> CMakeLists.txt to
>
> > >
>
> > > > set this, and it seems to work:
>
> > >
>
> > > >
>
> > >
>
> > > > build/CMakeFiles/3.11.0/CMakeRCCompiler.cmake:set(CMAKE_RC_COMPILER
>
> > >
>
> > > > "/usr/bin/i686-w64-mingw32-windres")
>
> > >
>
> > > >
>
> > >
>
> > > > But it doesn't seem to get used anywhere.
>
> > >
>
> > > >
>
> > >
>
> > > > I guess all we need to do now is figure out where and how to
> invoke this
>
> > >
>
> > > > to build a resource file from /development/cmake/lyx.rc. The
> link that
>
> > >
>
> > > > Jürgen found suggests we need somthing like:
>
> > >
>
> > > >
>
> > >
>
> > > > ${CMAKE_RC_COMPILER} -O coff -i development/cmake/lyx.rc -o lyx.coff
>
> > >
>
> > > >
>
> > >
>
> > > > and then to link the lyx.coff file into the executable.
>
> > >
>
> > > >
>
> > >
>
> > > > Riki
>
> > >
>
> > > >
>
> > >
>
> > >  
>
> > >
>
> > > I found it too, but unfortunately it is not working.
>
> > >
>
> > > 1.) The RC-compiler grumbles about not able to find "config.h".
>
> > >
>
> > > 2.) Copying this file to '.' does not help either. This time because
>
> > > of undefined resource.
>
> > >
>
> > > 3.) /usr/bin/i686-w64-mingw32-windres --help does not give me a clue
>
> > > about the correct
>
> > >
>
> > > settings to be used.
>
> > >
>
> > >  
>
> > >
>
> > > I gave up.
>
> > >
>
> >
>
> > I had to change the lyx.rc file to use "/" instead of "\". Otherwise, of
>
> > course, it fails to 

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Montag, 21. Mai 2018 12:25:00 CEST schrieb Richard Kimberly Heck 
:
> On 05/21/2018 11:47 AM, Kornel Benko wrote:
> >
> > Am Montag, 21. Mai 2018 11:21:30 CEST schrieb Richard Kimberly Heck
> > :
> >
> > > On 05/19/2018 01:48 PM, Kornel Benko wrote:
> >
> > > >
> >
> > > > Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller
> >
> > > > :
> >
> > > >
> >
> > > > > Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
> >
> > > >
> >
> > > > > > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen
> > Spitzmüller  >
> > > >
> >
> > > > > > i...@lyx.org>:
> >
> > > >
> >
> > > > > > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> >
> > > >
> >
> > > > > > > > No, it does not. For windows it is using
> >
> > > >
> >
> > > > > > 'development/cmake/lyx.rc'.
> >
> > > >
> >
> > > > > > > > But, for reason I don't
> >
> > > >
> >
> > > > > > > > understand, the icon creation is explicitly disabled if using
> >
> > > >
> >
> > > > > > mingw.
> >
> > > >
> >
> > > > > > > > See src/CMakeLists.txt:97
> >
> > > >
> >
> > > > > > > > if(WIN32 AND NOT MINGW)
> >
> > > >
> >
> > > > > > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> >
> > > >
> >
> > > > > > > > message(STATUS "Using icon defined in resource file:
> >
> > > >
> >
> > > > > > > > ${FILE_RC}")
> >
> > > >
> >
> > > > > > > > endif()
> >
> > > >
> >
> > > > > > >
> >
> > > >
> >
> > > > > > > Is this relevant?
> >
> > > >
> >
> > > > > > >
> >
> > > >
> >
> > > > > > > https://stackoverflow.com/questions/3526794/
> >
> > > >
> >
> > > > > > >
> >
> > > >
> >
> > > > > > > Jürgen
> >
> > > >
> >
> > > > > > >
> >
> > > >
> >
> > > > > > > > Kornel
> >
> > > >
> >
> > > > > >
> >
> > > >
> >
> > > > > > It is. Since we are compiling with mingw, both WIN32 and MINGW are
> >
> > > >
> >
> > > > > > set.
> >
> > > >
> >
> > > > > > In this case is FILE_RC not set, so that LyX.exe is not
> > dependent on
> >
> > > >
> >
> > > > > > lyx.rc.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > I meant whether the stackexchange threat I posted was relevant,
> > since
> >
> > > >
> >
> > > > > it deals with some setting that needs to be done for windres
> > with MinGW
> >
> > > >
> >
> > > > > and cmake.
> >
> > > >
> >
> > > > >
> >
> > > >
> >
> > > > > Jürgen
> >
> > > >
> >
> > > >  
> >
> > > >
> >
> > > > Ah, OK. Should be doable that way. Provided one has windres. In my
> >
> > > > case, although ubuntu is based on debian,
> >
> > > >
> >
> > > > I don't get it through standard package sources.
> >
> > > >
> >
> > >
> >
> > > I seem to have windres, actually, though under a slightly different
> >
> > > name. It's part of the mingw32-binutils package, but is installed as
> >
> > > /usr/bin/i686-w64-mingw32-windres. There is code in CMakeLists.txt to
> >
> > > set this, and it seems to work:
> >
> > >
> >
> > > build/CMakeFiles/3.11.0/CMakeRCCompiler.cmake:set(CMAKE_RC_COMPILER
> >
> > > "/usr/bin/i686-w64-mingw32-windres")
> >
> > >
> >
> > > But it doesn't seem to get used anywhere.
> >
> > >
> >
> > > I guess all we need to do now is figure out where and how to invoke this
> >
> > > to build a resource file from /development/cmake/lyx.rc. The link that
> >
> > > Jürgen found suggests we need somthing like:
> >
> > >
> >
> > > ${CMAKE_RC_COMPILER} -O coff -i development/cmake/lyx.rc -o lyx.coff
> >
> > >
> >
> > > and then to link the lyx.coff file into the executable.
> >
> > >
> >
> > > Riki
> >
> > >
> >
> >  
> >
> > I found it too, but unfortunately it is not working.
> >
> > 1.) The RC-compiler grumbles about not able to find "config.h".
> >
> > 2.) Copying this file to '.' does not help either. This time because
> > of undefined resource.
> >
> > 3.) /usr/bin/i686-w64-mingw32-windres --help does not give me a clue
> > about the correct
> >
> > settings to be used.
> >
> >  
> >
> > I gave up.
> >
> 
> I had to change the lyx.rc file to use "/" instead of "\". Otherwise, of
> course, it fails to find the icon file. But then I do get lyx.coff
> (which I'm attaching in case you need to use it for testing). Now how to
> link it into the main executable? (Well, and longer term, how to build
> it automatically, though we could just put lyx.coff into
> development/cmake/, too.)
> 
> Riki
> 

I still get
i686-w64-mingw32-windres: no resources
src/CMakeFiles/LyX.dir/build.make:1531: recipe for target 
'src/CMakeFiles/LyX.dir/__/development/cmake/lyx.rc.res' failed

What is this file 'lyx.coff' you write about, and how is it created?

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/21/2018 11:47 AM, Kornel Benko wrote:
>
> Am Montag, 21. Mai 2018 11:21:30 CEST schrieb Richard Kimberly Heck
> :
>
> > On 05/19/2018 01:48 PM, Kornel Benko wrote:
>
> > >
>
> > > Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller
>
> > > :
>
> > >
>
> > > > Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
>
> > >
>
> > > > > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen
> Spitzmüller 
> > >
>
> > > > > i...@lyx.org>:
>
> > >
>
> > > > > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
>
> > >
>
> > > > > > > No, it does not. For windows it is using
>
> > >
>
> > > > > 'development/cmake/lyx.rc'.
>
> > >
>
> > > > > > > But, for reason I don't
>
> > >
>
> > > > > > > understand, the icon creation is explicitly disabled if using
>
> > >
>
> > > > > mingw.
>
> > >
>
> > > > > > > See src/CMakeLists.txt:97
>
> > >
>
> > > > > > > if(WIN32 AND NOT MINGW)
>
> > >
>
> > > > > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
>
> > >
>
> > > > > > > message(STATUS "Using icon defined in resource file:
>
> > >
>
> > > > > > > ${FILE_RC}")
>
> > >
>
> > > > > > > endif()
>
> > >
>
> > > > > >
>
> > >
>
> > > > > > Is this relevant?
>
> > >
>
> > > > > >
>
> > >
>
> > > > > > https://stackoverflow.com/questions/3526794/
>
> > >
>
> > > > > >
>
> > >
>
> > > > > > Jürgen
>
> > >
>
> > > > > >
>
> > >
>
> > > > > > > Kornel
>
> > >
>
> > > > >
>
> > >
>
> > > > > It is. Since we are compiling with mingw, both WIN32 and MINGW are
>
> > >
>
> > > > > set.
>
> > >
>
> > > > > In this case is FILE_RC not set, so that LyX.exe is not
> dependent on
>
> > >
>
> > > > > lyx.rc.
>
> > >
>
> > > >
>
> > >
>
> > > > I meant whether the stackexchange threat I posted was relevant,
> since
>
> > >
>
> > > > it deals with some setting that needs to be done for windres
> with MinGW
>
> > >
>
> > > > and cmake.
>
> > >
>
> > > >
>
> > >
>
> > > > Jürgen
>
> > >
>
> > >  
>
> > >
>
> > > Ah, OK. Should be doable that way. Provided one has windres. In my
>
> > > case, although ubuntu is based on debian,
>
> > >
>
> > > I don't get it through standard package sources.
>
> > >
>
> >
>
> > I seem to have windres, actually, though under a slightly different
>
> > name. It's part of the mingw32-binutils package, but is installed as
>
> > /usr/bin/i686-w64-mingw32-windres. There is code in CMakeLists.txt to
>
> > set this, and it seems to work:
>
> >
>
> > build/CMakeFiles/3.11.0/CMakeRCCompiler.cmake:set(CMAKE_RC_COMPILER
>
> > "/usr/bin/i686-w64-mingw32-windres")
>
> >
>
> > But it doesn't seem to get used anywhere.
>
> >
>
> > I guess all we need to do now is figure out where and how to invoke this
>
> > to build a resource file from /development/cmake/lyx.rc. The link that
>
> > Jürgen found suggests we need somthing like:
>
> >
>
> > ${CMAKE_RC_COMPILER} -O coff -i development/cmake/lyx.rc -o lyx.coff
>
> >
>
> > and then to link the lyx.coff file into the executable.
>
> >
>
> > Riki
>
> >
>
>  
>
> I found it too, but unfortunately it is not working.
>
> 1.) The RC-compiler grumbles about not able to find "config.h".
>
> 2.) Copying this file to '.' does not help either. This time because
> of undefined resource.
>
> 3.) /usr/bin/i686-w64-mingw32-windres --help does not give me a clue
> about the correct
>
> settings to be used.
>
>  
>
> I gave up.
>

I had to change the lyx.rc file to use "/" instead of "\". Otherwise, of
course, it fails to find the icon file. But then I do get lyx.coff
(which I'm attaching in case you need to use it for testing). Now how to
link it into the main executable? (Well, and longer term, how to build
it automatically, though we could just put lyx.coff into
development/cmake/, too.)

Riki





>  
>
> Kornel
>
>  
>


lyx.coff
Description: Binary data

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Montag, 21. Mai 2018 11:21:30 CEST schrieb Richard Kimberly Heck 
:
> On 05/19/2018 01:48 PM, Kornel Benko wrote:
> >
> > Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller
> > :
> >
> > > Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
> >
> > > > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen Spitzmüller  >
> > > > i...@lyx.org>:
> >
> > > > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> >
> > > > > > No, it does not. For windows it is using
> >
> > > > 'development/cmake/lyx.rc'.
> >
> > > > > > But, for reason I don't
> >
> > > > > > understand, the icon creation is explicitly disabled if using
> >
> > > > mingw.
> >
> > > > > > See src/CMakeLists.txt:97
> >
> > > > > > if(WIN32 AND NOT MINGW)
> >
> > > > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> >
> > > > > > message(STATUS "Using icon defined in resource file:
> >
> > > > > > ${FILE_RC}")
> >
> > > > > > endif()
> >
> > > > >
> >
> > > > > Is this relevant?
> >
> > > > >
> >
> > > > > https://stackoverflow.com/questions/3526794/
> >
> > > > >
> >
> > > > > Jürgen
> >
> > > > >
> >
> > > > > > Kornel
> >
> > > >
> >
> > > > It is. Since we are compiling with mingw, both WIN32 and MINGW are
> >
> > > > set.
> >
> > > > In this case is FILE_RC not set, so that LyX.exe is not dependent on
> >
> > > > lyx.rc.
> >
> > >
> >
> > > I meant whether the stackexchange threat I posted was relevant, since
> >
> > > it deals with some setting that needs to be done for windres with MinGW
> >
> > > and cmake.
> >
> > >
> >
> > > Jürgen
> >
> >  
> >
> > Ah, OK. Should be doable that way. Provided one has windres. In my
> > case, although ubuntu is based on debian,
> >
> > I don't get it through standard package sources.
> >
> 
> I seem to have windres, actually, though under a slightly different
> name. It's part of the mingw32-binutils package, but is installed as
> /usr/bin/i686-w64-mingw32-windres. There is code in CMakeLists.txt to
> set this, and it seems to work:
> 
> build/CMakeFiles/3.11.0/CMakeRCCompiler.cmake:set(CMAKE_RC_COMPILER
> "/usr/bin/i686-w64-mingw32-windres")
> 
> But it doesn't seem to get used anywhere.
> 
> I guess all we need to do now is figure out where and how to invoke this
> to build a resource file from /development/cmake/lyx.rc. The link that
> Jürgen found suggests we need somthing like:
> 
> ${CMAKE_RC_COMPILER} -O coff -i development/cmake/lyx.rc -o lyx.coff
> 
> and then to link the lyx.coff file into the executable.
> 
> Riki
> 

I found it too, but unfortunately it is not working.
1.) The RC-compiler grumbles about not able to find "config.h".
2.) Copying this file to '.' does not help either. This time because of 
undefined resource.
3.) /usr/bin/i686-w64-mingw32-windres --help does not give me a clue about the 
correct
settings to be used.

I gave up.

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/19/2018 01:48 PM, Kornel Benko wrote:
>
> Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller
> :
>
> > Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
>
> > > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen Spitzmüller 
> > > i...@lyx.org>:
>
> > > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
>
> > > > > No, it does not. For windows it is using
>
> > > 'development/cmake/lyx.rc'.
>
> > > > > But, for reason I don't
>
> > > > > understand, the icon creation is explicitly disabled if using
>
> > > mingw.
>
> > > > > See src/CMakeLists.txt:97
>
> > > > > if(WIN32 AND NOT MINGW)
>
> > > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
>
> > > > > message(STATUS "Using icon defined in resource file:
>
> > > > > ${FILE_RC}")
>
> > > > > endif()
>
> > > >
>
> > > > Is this relevant?
>
> > > >
>
> > > > https://stackoverflow.com/questions/3526794/
>
> > > >
>
> > > > Jürgen
>
> > > >
>
> > > > > Kornel
>
> > >
>
> > > It is. Since we are compiling with mingw, both WIN32 and MINGW are
>
> > > set.
>
> > > In this case is FILE_RC not set, so that LyX.exe is not dependent on
>
> > > lyx.rc.
>
> >
>
> > I meant whether the stackexchange threat I posted was relevant, since
>
> > it deals with some setting that needs to be done for windres with MinGW
>
> > and cmake.
>
> >
>
> > Jürgen
>
>  
>
> Ah, OK. Should be doable that way. Provided one has windres. In my
> case, although ubuntu is based on debian,
>
> I don't get it through standard package sources.
>

I seem to have windres, actually, though under a slightly different
name. It's part of the mingw32-binutils package, but is installed as
/usr/bin/i686-w64-mingw32-windres. There is code in CMakeLists.txt to
set this, and it seems to work:

build/CMakeFiles/3.11.0/CMakeRCCompiler.cmake:set(CMAKE_RC_COMPILER
"/usr/bin/i686-w64-mingw32-windres")

But it doesn't seem to get used anywhere.

I guess all we need to do now is figure out where and how to invoke this
to build a resource file from /development/cmake/lyx.rc. The link that
Jürgen found suggests we need somthing like:

${CMAKE_RC_COMPILER} -O coff -i development/cmake/lyx.rc -o lyx.coff

and then to link the lyx.coff file into the executable.

Riki

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Samstag, 19. Mai 2018 17:42:41 CEST schrieb Jürgen Spitzmüller 
:
> Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
> > Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen Spitzmüller  > i...@lyx.org>:
> > > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> > > > No, it does not. For windows it is using
> > 'development/cmake/lyx.rc'.
> > > > But, for reason I don't
> > > > understand, the icon creation is explicitly disabled if using
> > mingw.
> > > > See src/CMakeLists.txt:97
> > > > if(WIN32 AND NOT MINGW)
> > > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> > > > message(STATUS "Using icon defined in resource file:
> > > > ${FILE_RC}")
> > > > endif()
> > > 
> > > Is this relevant?
> > > 
> > > https://stackoverflow.com/questions/3526794/
> > > 
> > > Jürgen
> > > 
> > > > Kornel
> >  
> > It is. Since we are compiling with mingw, both WIN32 and MINGW are
> > set.
> > In this case is FILE_RC not set, so that LyX.exe is not dependent on
> > lyx.rc.
> 
> I meant whether the stackexchange threat I posted was relevant, since
> it deals with some setting that needs to be done for windres with MinGW
> and cmake.
> 
> Jürgen 

Ah, OK. Should be doable that way. Provided one has windres. In my case, 
although ubuntu is based on debian,
I don't get it through standard package sources.

Kornel




signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Jürgen Spitzmüller]

Am Samstag, den 19.05.2018, 17:37 +0200 schrieb Kornel Benko:
> Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen Spitzmüller  i...@lyx.org>:
> > Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> > > No, it does not. For windows it is using
> 'development/cmake/lyx.rc'.
> > > But, for reason I don't
> > > understand, the icon creation is explicitly disabled if using
> mingw.
> > > See src/CMakeLists.txt:97
> > >   if(WIN32 AND NOT MINGW)
> > > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> > > message(STATUS "Using icon defined in resource file:
> > > ${FILE_RC}")
> > >   endif()
> > 
> > Is this relevant?
> > 
> > https://stackoverflow.com/questions/3526794/
> > 
> > Jürgen
> > 
> > >   Kornel
>  
> It is. Since we are compiling with mingw, both WIN32 and MINGW are
> set.
> In this case is FILE_RC not set, so that LyX.exe is not dependent on
> lyx.rc.

I meant whether the stackexchange threat I posted was relevant, since
it deals with some setting that needs to be done for windres with MinGW
and cmake.

Jürgen 

>  
>   Kornel
>  
>  

signature.asc
Description: This is a digitally signed message part

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Samstag, 19. Mai 2018 12:58:37 CEST schrieb Jürgen Spitzmüller 
:
> Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> > No, it does not. For windows it is using 'development/cmake/lyx.rc'.
> > But, for reason I don't
> > understand, the icon creation is explicitly disabled if using mingw.
> > See src/CMakeLists.txt:97
> > if(WIN32 AND NOT MINGW)
> > set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> > message(STATUS "Using icon defined in resource file:
> > ${FILE_RC}")
> > endif()
> 
> Is this relevant?
> 
> https://stackoverflow.com/questions/3526794/
> 
> Jürgen
> 
> > Kornel

It is. Since we are compiling with mingw, both WIN32 and MINGW are set.
In this case is FILE_RC not set, so that LyX.exe is not dependent on lyx.rc.

Kornel




signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/19/2018 07:09 AM, Enrico Forestieri wrote:
> On Sat, May 19, 2018 at 12:10:20PM +0200, Kornel Benko wrote:
>> Am Samstag, 19. Mai 2018 12:07:30 CEST schrieb Kornel Benko :
>>> But, for reason I don't
>>> understand, the icon creation is explicitly disabled if using mingw.
>> Probably, because linux does not have 'winres' command?
> It should be available for cross-builds. For example, Debian has it:
> https://packages.debian.org/search?searchon=contents=windres=path=stable=any
> and autotools look for such names when cross-building.
>

Thanks to everyone for comments. I'm away over the weekend, but will
check all this out early next week. Hopefully, we'll have a 2.3.0
installer by mid-week or so.

Riki

Re: LyX 2.3.0 on Windows

[Enrico Forestieri]

On Sat, May 19, 2018 at 12:10:20PM +0200, Kornel Benko wrote:
> Am Samstag, 19. Mai 2018 12:07:30 CEST schrieb Kornel Benko :
> > But, for reason I don't
> > understand, the icon creation is explicitly disabled if using mingw.
> 
> Probably, because linux does not have 'winres' command?

It should be available for cross-builds. For example, Debian has it:
https://packages.debian.org/search?searchon=contents=windres=path=stable=any
and autotools look for such names when cross-building.

-- 
Enrico

Re: LyX 2.3.0 on Windows

[Jürgen Spitzmüller]

Am Samstag, den 19.05.2018, 12:07 +0200 schrieb Kornel Benko:
> No, it does not. For windows it is using 'development/cmake/lyx.rc'.
> But, for reason I don't
> understand, the icon creation is explicitly disabled if using mingw.
> See src/CMakeLists.txt:97
>   if(WIN32 AND NOT MINGW)
> set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
> message(STATUS "Using icon defined in resource file:
> ${FILE_RC}")
>   endif()

Is this relevant?

https://stackoverflow.com/questions/3526794/

Jürgen

>   Kornel

signature.asc
Description: This is a digitally signed message part

Re: LyX 2.3.0 on Windows

[Jürgen Spitzmüller]

Am Samstag, den 19.05.2018, 12:10 +0200 schrieb Kornel Benko:
> Am Samstag, 19. Mai 2018 12:07:30 CEST schrieb Kornel Benko  yx.org>:
> > But, for reason I don't
> > understand, the icon creation is explicitly disabled if using
> mingw.
>  
> Probably, because linux does not have 'winres' command?

windres, for that matter.

http://www.mingw.org/wiki/MS_resource_compiler

Jürgen

>  
>   Kornel
>  

signature.asc
Description: This is a digitally signed message part

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Samstag, 19. Mai 2018 12:07:30 CEST schrieb Kornel Benko :
> But, for reason I don't
> understand, the icon creation is explicitly disabled if using mingw.

Probably, because linux does not have 'winres' command?

Kornel



signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Kornel Benko]

Am Samstag, 19. Mai 2018 11:24:19 CEST schrieb Enrico Forestieri 
:
> On Fri, May 18, 2018 at 01:12:34PM -0400, Richard Kimberly Heck wrote:
> > 
> > By the way, do you know how to figure out where Windows is trying to
> > find the icon? I've presumably changed something unknowingly about where
> > it's being put.
> 
> On Windows, an application icon is provided through a resource file that
> is compiled by the resource compiler (windres) and then linked to the
> executable in the final linking stage. Using autotools, the resource file
> lyxwinres.rc is compiled and then linked. Maybe the cmake build lacks this
> functionality?

No, it does not. For windows it is using 'development/cmake/lyx.rc'. But, for 
reason I don't
understand, the icon creation is explicitly disabled if using mingw.
See src/CMakeLists.txt:97
if(WIN32 AND NOT MINGW)
set(FILE_RC ${TOP_CMAKE_PATH}/lyx.rc)
message(STATUS "Using icon defined in resource file: ${FILE_RC}")
endif()

Kornel





signature.asc
Description: This is a digitally signed message part.

Re: LyX 2.3.0 on Windows

[Enrico Forestieri]

On Fri, May 18, 2018 at 01:12:34PM -0400, Richard Kimberly Heck wrote:
> 
> By the way, do you know how to figure out where Windows is trying to
> find the icon? I've presumably changed something unknowingly about where
> it's being put.

On Windows, an application icon is provided through a resource file that
is compiled by the resource compiler (windres) and then linked to the
executable in the final linking stage. Using autotools, the resource file
lyxwinres.rc is compiled and then linked. Maybe the cmake build lacks this
functionality?

-- 
Enrico

Re: LyX 2.3.0 on Windows

[Andrew Parsloe]

On 19/05/2018 5:12 a.m., Richard Kimberly Heck wrote:

On 05/18/2018 11:16 AM, Richard Kimberly Heck wrote:

On 05/18/2018 04:32 AM, Andrew Parsloe wrote:

On 18/05/2018 11:27 a.m., Richard Kimberly Heck wrote:

I've fixed the problems reported by people who've tried the new
installers. The question is how now to proceed. Note that these are
questions for 2.3.0 (and probably 2.3.1, since I will turn my attention
to that once this issue is resolved). Larger questions about how to
proceed with the Windows installer can be deferred to 2.3.2 if not
2.4.0.

It's my hope that we can find someone to take over building the
installer, etc, before too long. I'm happy to do it for a bit

So, questions.

1) Should we include any form of the 'update MiKTeX' code, with a dialog
asking for permission to perform the update, or should we not do so?

2) Should we try to get wider testing of these new packages by
advertising the putatively final version on the users' list before doing
an official release?

I have no strong opinion about (1), though I don't think it would be too
difficult to include such a dialog. I gather that the risk is that
updating LyX itself could trigger a partial update (due to packages
being installed at compilation time) that will break MiKTeX. As Pavel
said, the people this might affect seem to be only folks who did some
kind of update between October and January, but who knows. The main
issue would be getting translations of the message in the dialog. I
guess I could write to the relevant folks and ask for quick responses.
There's also Google, if all else fails. I suppose another option would
be for me to contact the MiKTeX maintainer and see what they think.

Regarding (2), I guess I am a bit nervous about these installers, since
I have no idea what I'm doing, and we didn't get THAT much feedback from
my previous messages.

Riki

I've run LyX-230-Installer-103.exe. It has installed and from a very
first glance, LyX is displaying a couple of complex documents
correctly. The only obvious thing at this stage is that the LyX icon
(an irregular LyX in large blue type) is missing and a generic windows
program icon has taken its place (see attached).

I noticed that, but didn't realize what it was. I'll try to figure out
what's wrong.

By the way, do you know how to figure out where Windows is trying to
find the icon? I've presumably changed something unknowingly about where
it's being put.

Riki
I don't know where it hides although I see that the icon is attached to 
pdfview.exe in LyX 2.3/bin and to Uninstall-LyX.exe. (I notice there is 
lyx.png and lyx.svg in LyX 2.2/Resources/images but only lyx.png in LyX 
2.3/Resources/images.)


The windows generic icons are at %SystemRoot%\system32\SHELL32.dll (on 
right clicking on a shortcut, choosing properties and then Change Icon).


Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/18/2018 11:16 AM, Richard Kimberly Heck wrote:
> On 05/18/2018 04:32 AM, Andrew Parsloe wrote:
>> On 18/05/2018 11:27 a.m., Richard Kimberly Heck wrote:
>>> I've fixed the problems reported by people who've tried the new
>>> installers. The question is how now to proceed. Note that these are
>>> questions for 2.3.0 (and probably 2.3.1, since I will turn my attention
>>> to that once this issue is resolved). Larger questions about how to
>>> proceed with the Windows installer can be deferred to 2.3.2 if not
>>> 2.4.0.
>>>
>>> It's my hope that we can find someone to take over building the
>>> installer, etc, before too long. I'm happy to do it for a bit
>>>
>>> So, questions.
>>>
>>> 1) Should we include any form of the 'update MiKTeX' code, with a dialog
>>> asking for permission to perform the update, or should we not do so?
>>>
>>> 2) Should we try to get wider testing of these new packages by
>>> advertising the putatively final version on the users' list before doing
>>> an official release?
>>>
>>> I have no strong opinion about (1), though I don't think it would be too
>>> difficult to include such a dialog. I gather that the risk is that
>>> updating LyX itself could trigger a partial update (due to packages
>>> being installed at compilation time) that will break MiKTeX. As Pavel
>>> said, the people this might affect seem to be only folks who did some
>>> kind of update between October and January, but who knows. The main
>>> issue would be getting translations of the message in the dialog. I
>>> guess I could write to the relevant folks and ask for quick responses.
>>> There's also Google, if all else fails. I suppose another option would
>>> be for me to contact the MiKTeX maintainer and see what they think.
>>>
>>> Regarding (2), I guess I am a bit nervous about these installers, since
>>> I have no idea what I'm doing, and we didn't get THAT much feedback from
>>> my previous messages.
>>>
>>> Riki
>> I've run LyX-230-Installer-103.exe. It has installed and from a very
>> first glance, LyX is displaying a couple of complex documents
>> correctly. The only obvious thing at this stage is that the LyX icon
>> (an irregular LyX in large blue type) is missing and a generic windows
>> program icon has taken its place (see attached).
> I noticed that, but didn't realize what it was. I'll try to figure out
> what's wrong.

By the way, do you know how to figure out where Windows is trying to
find the icon? I've presumably changed something unknowingly about where
it's being put.

Riki

Re: LyX 2.3.0 on Windows

[Richard Kimberly Heck]

On 05/18/2018 04:32 AM, Andrew Parsloe wrote:
> On 18/05/2018 11:27 a.m., Richard Kimberly Heck wrote:
>> I've fixed the problems reported by people who've tried the new
>> installers. The question is how now to proceed. Note that these are
>> questions for 2.3.0 (and probably 2.3.1, since I will turn my attention
>> to that once this issue is resolved). Larger questions about how to
>> proceed with the Windows installer can be deferred to 2.3.2 if not
>> 2.4.0.
>>
>> It's my hope that we can find someone to take over building the
>> installer, etc, before too long. I'm happy to do it for a bit
>>
>> So, questions.
>>
>> 1) Should we include any form of the 'update MiKTeX' code, with a dialog
>> asking for permission to perform the update, or should we not do so?
>>
>> 2) Should we try to get wider testing of these new packages by
>> advertising the putatively final version on the users' list before doing
>> an official release?
>>
>> I have no strong opinion about (1), though I don't think it would be too
>> difficult to include such a dialog. I gather that the risk is that
>> updating LyX itself could trigger a partial update (due to packages
>> being installed at compilation time) that will break MiKTeX. As Pavel
>> said, the people this might affect seem to be only folks who did some
>> kind of update between October and January, but who knows. The main
>> issue would be getting translations of the message in the dialog. I
>> guess I could write to the relevant folks and ask for quick responses.
>> There's also Google, if all else fails. I suppose another option would
>> be for me to contact the MiKTeX maintainer and see what they think.
>>
>> Regarding (2), I guess I am a bit nervous about these installers, since
>> I have no idea what I'm doing, and we didn't get THAT much feedback from
>> my previous messages.
>>
>> Riki
>
> I've run LyX-230-Installer-103.exe. It has installed and from a very
> first glance, LyX is displaying a couple of complex documents
> correctly. The only obvious thing at this stage is that the LyX icon
> (an irregular LyX in large blue type) is missing and a generic windows
> program icon has taken its place (see attached).

I noticed that, but didn't realize what it was. I'll try to figure out
what's wrong.

Riki

Re: LyX 2.3.0 on Windows

[Pavel Sanda]

Richard Kimberly Heck wrote:
> 1) Should we include any form of the 'update MiKTeX' code, with a dialog
> asking for permission to perform the update, or should we not do so?

Unless we also do also bundle with MiKTeX it might be better to stay
distribution agnostic. But no strong opinion either.

> 2) Should we try to get wider testing of these new packages by
> advertising the putatively final version on the users' list before doing
> an official release?

Definitely.

Pavel

Re: LyX 2.3.0 on Windows

[Andrew Parsloe]

On 18/05/2018 11:27 a.m., Richard Kimberly Heck wrote:

I've fixed the problems reported by people who've tried the new
installers. The question is how now to proceed. Note that these are
questions for 2.3.0 (and probably 2.3.1, since I will turn my attention
to that once this issue is resolved). Larger questions about how to
proceed with the Windows installer can be deferred to 2.3.2 if not 2.4.0.

It's my hope that we can find someone to take over building the
installer, etc, before too long. I'm happy to do it for a bit

So, questions.

1) Should we include any form of the 'update MiKTeX' code, with a dialog
asking for permission to perform the update, or should we not do so?

2) Should we try to get wider testing of these new packages by
advertising the putatively final version on the users' list before doing
an official release?

I have no strong opinion about (1), though I don't think it would be too
difficult to include such a dialog. I gather that the risk is that
updating LyX itself could trigger a partial update (due to packages
being installed at compilation time) that will break MiKTeX. As Pavel
said, the people this might affect seem to be only folks who did some
kind of update between October and January, but who knows. The main
issue would be getting translations of the message in the dialog. I
guess I could write to the relevant folks and ask for quick responses.
There's also Google, if all else fails. I suppose another option would
be for me to contact the MiKTeX maintainer and see what they think.

Regarding (2), I guess I am a bit nervous about these installers, since
I have no idea what I'm doing, and we didn't get THAT much feedback from
my previous messages.

Riki
I've run LyX-230-Installer-103.exe. It has installed and from a very 
first glance, LyX is displaying a couple of complex documents correctly. 
The only obvious thing at this stage is that the LyX icon (an irregular 
LyX in large blue type) is missing and a generic windows program icon 
has taken its place (see attached).


Andrew


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: LyX 2.3.0 on Windows

[Andrew Parsloe]

On 18/05/2018 11:27 a.m., Richard Kimberly Heck wrote:

... I guess I am a bit nervous about these installers, since
I have no idea what I'm doing, and we didn't get THAT much feedback from
my previous messages.

Riki

I'm very happy to try your latest version if you can provide a link.

Andrew

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: LyX 2.3.0 on Windows

[Scott Kostyshak]

On Thu, May 17, 2018 at 11:27:37PM +, Richard Kimberly Heck wrote:
> I've fixed the problems reported by people who've tried the new
> installers. The question is how now to proceed. Note that these are
> questions for 2.3.0 (and probably 2.3.1, since I will turn my attention
> to that once this issue is resolved).

Makes sense. It might be nice to release the installer for 2.3.0 anyway,
because that way we might catch issues before the 2.3.1 release.

I'm not sure about my opinions on the two questions. I guess I don't
have strong opinions. I think it would be nice to get more testing
before making official announcement.

Scott


signature.asc
Description: PGP signature