Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

Sent from my iPad

 On 25 Aug 2014, at 07:55, Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 18:01 schrieb Patrick De Visschere pdvissch...@edpnet.be:
 
 On 23 Aug, 2014, at 14:50 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 23:15 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 20 Aug, 2014, at 11:22 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 On 19 Aug, 2014, at 14:12 , Stephan Witt st.w...@gmx.net wrote:
 
 Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
 pdvissch...@edpnet.be:
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake 
 examples -nomake tools -no-framework
 
 You don't build the libraries as frameworks. I'm not sure if this makes 
 no difference.
 
 I'm using the Qt frameworks I've build myself.
 
 Stephan
 
 Stephan,
 
 I was planning to do that. (the qt-debug build does not make a 
 difference as you expected)
 
 I suppose you use the LyX-Mac-binary-release.sh script.
 
 I have never managed to use this script without making changes to it, 
 perhaps because I’m using it the wrong way.
 
 I build qt as a framework separately and would then use the script like:
 
 sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
 --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
 --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
 --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
 
 I think the --with-qt-frameworks=yes is needed to include qt as a 
 framework;
 
 and --with-qt-dir=/… points to the dir where the  qt-framework has been 
 installed (previously).
 
 I’m not sure about the exact meaning of --qt-deployment=yes  but I think 
  I need it too.
 
 What I don’t understand are the lines 260-262
 if [ ${configure_qt_frameworks} != yes ]; then
QtInstallDir=${QTDIR:-/opt/qt4}
 fi
 
 with --with-qt-frameworks=yes, QtInstallDir is not set.
 
 Therefore I uncomment the if/fi so that
 QtInstallDir=${QTDIR:-/opt/qt4”}
 
 is always executed and QtInstallDir points to my qt-install dir.
 
 In addition I must modify some CPPFLAGS= ...
 
 Any idea what I’m doing wrong?
 
 Patrick De Visschere
 
 Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
 anymore
 and it was meant as with the frameworks by Qt (Nokia). The 
 --qt-deployment=yes
 is default and with it the script copies the frameworks to the package. 
 This is
 needed if you want to use the LyX app on another system.
 
 I'd avoid the --with-libiconv-prefix=/opt/local switch.
 
 This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
 
 #!/bin/sh
 ARCH=x86_64
 QtVersion=5.3.1
 QtAPI=-cocoa
 LyXVersion=lyx
 CC=cc CXX=c++ \
 QtConfigureOptions=-debug-and-release QtAPI=${QtAPI} 
 QtVersion=${QtVersion} \
 sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
 --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
 --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH}
  \
 $@
 
 Stephan
 
 I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the 
 menubar appears immediately. Since with XCode I use the macports iconv 
 library that could still theoretically be the culprit. Or maybe it’s just 
 due to Xcode. Anyway this is not very important;
 I tried to build (with Xcode) without aspell and hunspell but somehow 
 cmake doesn’t want that.
 
 This is my script to call cmake for Xcode project generation:
 
 #!/bin/sh
 export PATH=/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}
 LyxSourceDir=$(pwd)/lyx
 LyxUtilDir=/Users/Shared/LyX/utilities
 CMAKE_GENERATOR=Xcode
 LyXVersion=$(grep AC_INIT ${LyxSourceDir}/configure.ac | cut -d, -f2 | tr 
 -d  ())
 LyxBuildDir=lyx-build/cmake/${LyXVersion}
 if [ -f ${LyxSourceDir}/development/cmake/CMakeLists.txt ]; then
 TOPCMAKE=${LyxSourceDir}/development/cmake
 COPYRESOURCES=yes
 else
 TOPCMAKE=${LyxSourceDir}
 fi
 rm -rf ${LyxBuildDir}
 mkdir -p ${LyxBuildDir}
 
 case $(qmake -version) in
 *Using*5.*)
 LYX_USE_QT=-DLYX_USE_QT=QT5
 esac
 
 SPELLER_OPTIONS=-DASPELL_INCLUDE_DIR=${LyxUtilDir}/include \
 -DASPELL_LIBRARY_RELEASE=${LyxUtilDir}/lib/libaspell.dylib \
 -DHUNSPELL_INCLUDE_DIR=${LyxUtilDir}/include \
 -DHUNSPELL_LIBRARY=${LyxUtilDir}/lib/libhunspell.dylib \
 -DMagic_INCLUDE_DIR=${LyxUtilDir}/include \
 -DMagic_LIBRARY=${LyxUtilDir}/lib/libmagic.dylib \
 -DLYX_ASPELL=ON -DLYX_HUNSPELL=ON
 (
 cd ${LyxBuildDir}  \
 cmake -G ${CMAKE_GENERATOR} ${TOPCMAKE} \
-DLYX_NLS=OFF \
-DLYX_DEVEL_VERSION=ON -DLYX_DEBUG=ON -DLYX_RELEASE=OFF \
-DLYX_DEBUG_GLIBC=OFF -DLYX_DEBUG_GLIBC_PEDANTIC=OFF \
-DLYX_PACKAGE_SUFFIX=OFF -DLYX_PROGRAM_SUFFIX=OFF \

Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph

[Jürgen Spitzmüller]

Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
 This commit seems ('git bisect run' tells me. I have not confirmed) to
 have broken export of the Japanese beamer manual to DVI. I think it
 also breaks two other tests:
 3632 - export/examples/ja/beamer_pdf (Failed)
 3634 - export/examples/ja/beamer_pdf3 (Failed)

Thanks. Could you file a new report for this? I am quite busy ATM but will have 
a look at it eventually.

Jürgen

QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.

My question now is: should we simply replace all Q_WS_ macros with the 
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?

The first patch does this for all platforms - in case someone wants to test it 
too.
The second one is for Mac OS X only. I'll plan to commit the second one if I 
don't
get enough encouraging feedback for the first one.

With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.

Stephan



2014-08-25-Qt5-all-platforms.patch
Description: Binary data


2014-08-25-Qt5-mac-platform.patch
Description: Binary data

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 15:53 schrieb Stephan Witt st.w...@gmx.net:

 Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
 The reasoning is to disable all platform specific code and force the Qt users
 like us to review all code guarded by Q_WS_ macros. This means all code in LyX
 inside these ifdef's is not compiled and executed anymore with Qt5.
 
 My question now is: should we simply replace all Q_WS_ macros with the 
 corresponding Q_OS_ macro for all platforms or should this be done for every
 platform in separate steps?
 
 The first patch does this for all platforms - in case someone wants to test 
 it too.
 The second one is for Mac OS X only. I'll plan to commit the second one if I 
 don't
 get enough encouraging feedback for the first one.
 
 With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
 
 Stephan
 
 2014-08-25-Qt5-all-platforms.patch2014-08-25-Qt5-mac-platform.patch

Sorry for the noise regarding X11 - I see now Q_WS_X11 shouldn't be replaced.

Since only a limited count of lyx devs is able to compile and run windows
I'd guess I stick with the second patch - change it for Mac OS only.

Stephan

Re: QUESTION: How to enable Qt5 for LyX master

[Kornel Benko]

Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko kor...@lyx.org
 Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt st.w...@gmx.net
  Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
  The reasoning is to disable all platform specific code and force the Qt 
  users
  like us to review all code guarded by Q_WS_ macros. This means all code in 
  LyX
  inside these ifdef's is not compiled and executed anymore with Qt5.
  
  My question now is: should we simply replace all Q_WS_ macros with the 
  corresponding Q_OS_ macro for all platforms or should this be done for every
  platform in separate steps?
  
  The first patch does this for all platforms - in case someone wants to test 
  it too.
  The second one is for Mac OS X only. I'll plan to commit the second one if 
  I don't
  get enough encouraging feedback for the first one.
  
  With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
  
  Stephan
 
 At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
 compilation.
 

To be more specific

FindQt4.cmake:
We should check for Q_WS_X11, but assign variable Q_OS_X11.

Kornel

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

Re: QUESTION: How to enable Qt5 for LyX master

[Kornel Benko]

Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt st.w...@gmx.net
 Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
 The reasoning is to disable all platform specific code and force the Qt users
 like us to review all code guarded by Q_WS_ macros. This means all code in LyX
 inside these ifdef's is not compiled and executed anymore with Qt5.
 
 My question now is: should we simply replace all Q_WS_ macros with the 
 corresponding Q_OS_ macro for all platforms or should this be done for every
 platform in separate steps?
 
 The first patch does this for all platforms - in case someone wants to test 
 it too.
 The second one is for Mac OS X only. I'll plan to commit the second one if I 
 don't
 get enough encouraging feedback for the first one.
 
 With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
 
 Stephan

At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
compilation.

Kornel

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

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 16:12 schrieb Kornel Benko kor...@lyx.org:

 Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko kor...@lyx.org
 Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt 
 st.w...@gmx.net
 Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
 The reasoning is to disable all platform specific code and force the Qt 
 users
 like us to review all code guarded by Q_WS_ macros. This means all code in 
 LyX
 inside these ifdef's is not compiled and executed anymore with Qt5.
 
 My question now is: should we simply replace all Q_WS_ macros with the 
 corresponding Q_OS_ macro for all platforms or should this be done for every
 platform in separate steps?
 
 The first patch does this for all platforms - in case someone wants to test 
 it too.
 The second one is for Mac OS X only. I'll plan to commit the second one if 
 I don't
 get enough encouraging feedback for the first one.
 
 With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
 
 Stephan
 
 At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
 compilation.
 
 
 To be more specific
 
 FindQt4.cmake:
 We should check for Q_WS_X11, but assign variable Q_OS_X11.

Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 
either.

Stephan

Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph

[Scott Kostyshak]

On Mon, Aug 25, 2014 at 8:28 AM, Jürgen Spitzmüller sp...@lyx.org wrote:
 Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
 This commit seems ('git bisect run' tells me. I have not confirmed) to
 have broken export of the Japanese beamer manual to DVI. I think it
 also breaks two other tests:
 3632 - export/examples/ja/beamer_pdf (Failed)
 3634 - export/examples/ja/beamer_pdf3 (Failed)

 Thanks. Could you file a new report for this? I am quite busy ATM but will 
 have
 a look at it eventually.

Sure, I created it at #9250. Let me know if you cannot get to it
before 2.1.2 and I will fix the document manually.

Scott

Warnings due to x***arrow commit

[Richard Heck]

CXX InsetMathXArrow.o


../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void 
lyx::InsetMathXArrow::mathmlize(lyx::MathStream) const':


../../src/mathed/InsetMathXArrow.cpp:116:8: warning: 'arrow' may be used 
uninitialized in this function [-Wmaybe-uninitialized]


 arrow  cell(1)  cell(0)

^

../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void 
lyx::InsetMathXArrow::htmlize(lyx::HtmlStream) const':


../../src/mathed/InsetMathXArrow.cpp:157:43: warning: 'arrow' may be 
used uninitialized in this function [-Wmaybe-uninitialized]


 MTag(span, class='xabottom')  arrow  ETag(span)

Re: QUESTION: How to enable Qt5 for LyX master

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:

 
 Am 25.08.2014 um 16:12 schrieb Kornel Benko kor...@lyx.org:
 
  Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
  kor...@lyx.org
  At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
  compilation.
  
  
  To be more specific
  
  FindQt4.cmake:
  We should check for Q_WS_X11, but assign variable Q_OS_X11.
 
 Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5
 either.

Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.

Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken...

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote:

 commit 565260126eb106ab00049285627417e73736bb96
 Author: Enrico Forestieri for...@lyx.org
 Date:   Mon Aug 25 18:35:15 2014 +0200
 
 Fix the -geometry command line argument for Windows.
 
 The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF
 specifies a preferred size and location for the main window.
 Currently, this is semi-broken on Windows. Indeed, only
 specifying WIDTH and HEIGHT places the main window such that
 the left and top borders are invisible such that the window cannot
 be moved. Moreover, the XOFF and YOFF parts (when present) are
 used to specify the distance of the window from the left and top
 or right and bottom edges of the screen, when using '+' or '-',
 respectively. However, -geometry 800x600-20-20, instead of placing
 the window such that its bottom and right edges are at a distance
 of 20 pixels from the corresponding screen edges, places the
 window such that its left and top borders are out of the screen.
 This is corrected by this commit, which also addresses the fact
 that Qt5 does not define Q_WS_WIN anymore.

Richard, may I apply this to the stable branch?
(Minus the Qt5 part, of course)

 diff --git a/src/frontends/qt4/GuiApplication.cpp 
 b/src/frontends/qt4/GuiApplication.cpp
 index 56cbd60..64c645d 100644
 --- a/src/frontends/qt4/GuiApplication.cpp
 +++ b/src/frontends/qt4/GuiApplication.cpp
 @@ -87,6 +87,7 @@
  #include QByteArray
  #include QClipboard
  #include QDateTime
 +#include QDesktopWidget
  #include QDir
  #include QEvent
  #include QEventLoop
 @@ -2193,16 +2194,40 @@ void GuiApplication::createView(QString const  
 geometry_arg, bool autoShow,
   }
  
   if (!geometry_arg.isEmpty()) {
 -#ifdef Q_WS_WIN
 +#if defined(Q_OS_WIN) || defined(Q_CYGWIN_WIN)
   int x, y;
   int w, h;
 - QRegExp re( [=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[ 
 ]*(?:([+-][0-9]*)([+-][0-9]*)){0,1} );
 + QChar sx, sy;
 + QRegExp re( [=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[ 
 ]*(?:([+-][0-9]*)){0,1}(?:([+-][0-9]*)){0,1} );
   re.indexIn(geometry_arg);
   w = re.cap(1).toInt();
   h = re.cap(2).toInt();
   x = re.cap(3).toInt();
   y = re.cap(4).toInt();
 + sx = re.cap(3).isEmpty() ? '+' : re.cap(3).at(0);
 + sy = re.cap(4).isEmpty() ? '+' : re.cap(4).at(0);
 + // Set initial geometry such that we can get the frame size.
   view-setGeometry(x, y, w, h);
 + int framewidth = view-geometry().x() - view-x();
 + int titleheight = view-geometry().y() - view-y();
 + // Negative displacements must be interpreted as distances
 + // from the right or bottom screen borders.
 + if (sx == '-' || sy == '-') {
 + QRect rec = QApplication::desktop()-screenGeometry();
 + if (sx == '-')
 + x += rec.width() - w - framewidth;
 + if (sy == '-')
 + y += rec.height() - h - titleheight;
 + view-setGeometry(x, y, w, h);
 + }
 + // Make sure that the left and top frame borders are visible.
 + if (view-x()  0 || view-y()  0) {
 + if (view-x()  0)
 + x = framewidth;
 + if (view-y()  0)
 + y = titleheight;
 + view-setGeometry(x, y, w, h);
 + }
  #endif
   }
   view-setFocus();

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Richard Heck]

On 08/25/2014 01:01 PM, Enrico Forestieri wrote:

On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote:


commit 565260126eb106ab00049285627417e73736bb96
Author: Enrico Forestieri for...@lyx.org
Date:   Mon Aug 25 18:35:15 2014 +0200

 Fix the -geometry command line argument for Windows.
 
 The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF

 specifies a preferred size and location for the main window.
 Currently, this is semi-broken on Windows. Indeed, only
 specifying WIDTH and HEIGHT places the main window such that
 the left and top borders are invisible such that the window cannot
 be moved. Moreover, the XOFF and YOFF parts (when present) are
 used to specify the distance of the window from the left and top
 or right and bottom edges of the screen, when using '+' or '-',
 respectively. However, -geometry 800x600-20-20, instead of placing
 the window such that its bottom and right edges are at a distance
 of 20 pixels from the corresponding screen edges, places the
 window such that its left and top borders are out of the screen.
 This is corrected by this commit, which also addresses the fact
 that Qt5 does not define Q_WS_WIN anymore.

Richard, may I apply this to the stable branch?


We are string frozen at the moment. No string changes here?

Richard

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote:
 
 We are string frozen at the moment. No string changes here?

Yes, no string is changed.

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Richard Heck]

On 08/25/2014 01:09 PM, Enrico Forestieri wrote:

On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote:

We are string frozen at the moment. No string changes here?

Yes, no string is changed.


OK, then.

rh

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 17:54 schrieb Enrico Forestieri for...@lyx.org:

 On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
 
 
 Am 25.08.2014 um 16:12 schrieb Kornel Benko kor...@lyx.org:
 
 Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
 kor...@lyx.org
 At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
 compilation.
 
 
 To be more specific
 
 FindQt4.cmake:
 We should check for Q_WS_X11, but assign variable Q_OS_X11.
 
 Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5
 either.
 
 Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
 othewise it will not compile with Qt5. For example, the QWindowsMime class
 is not available anymore and, until they make it available again, that
 guard should not be replaced. So, I suggest to replace the guards only
 if you are able to check the result.

Ok, I'll do it then this way. Thanks.

 Another side effect is that my Qt5 port for cygwin will require its own
 guard now that Q_WS_WIN is not available anymore. I wonder what they were
 drinking when that decision was taken…

+1

Stephan

 
 -- 
 Enrico

Re: QUESTION: How to enable Qt5 for LyX master

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote:

 On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
 
  
  Am 25.08.2014 um 16:12 schrieb Kornel Benko kor...@lyx.org:
  
   Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
   kor...@lyx.org
   At least on QT4 there is no symbol Q_OS_X11. So this patch would break 
   QT4
   compilation.
   
   
   To be more specific
   
   FindQt4.cmake:
   We should check for Q_WS_X11, but assign variable Q_OS_X11.
  
  Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within 
  Qt5
  either.
 
 Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
 othewise it will not compile with Qt5. For example, the QWindowsMime class
 is not available anymore and, until they make it available again, that
 guard should not be replaced. So, I suggest to replace the guards only
 if you are able to check the result.
 
 Another side effect is that my Qt5 port for cygwin will require its own
 guard now that Q_WS_WIN is not available anymore. I wonder what they were
 drinking when that decision was taken...

I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
for Qt5. The remaining ones are those related to code that doesn't compile
on Qt5, ATM.

-- 
Enrico

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 19:58 schrieb Enrico Forestieri for...@lyx.org:

 On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote:
 
 On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
 
 
 Am 25.08.2014 um 16:12 schrieb Kornel Benko kor...@lyx.org:
 
 Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
 kor...@lyx.org
 At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
 compilation.
 
 
 To be more specific
 
 FindQt4.cmake:
 We should check for Q_WS_X11, but assign variable Q_OS_X11.
 
 Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within 
 Qt5
 either.
 
 Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
 othewise it will not compile with Qt5. For example, the QWindowsMime class
 is not available anymore and, until they make it available again, that
 guard should not be replaced. So, I suggest to replace the guards only
 if you are able to check the result.
 
 Another side effect is that my Qt5 port for cygwin will require its own
 guard now that Q_WS_WIN is not available anymore. I wonder what they were
 drinking when that decision was taken...
 
 I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
 for Qt5. The remaining ones are those related to code that doesn't compile
 on Qt5, ATM.

Ok, I did it for Q_WS_MACX now.

Stephan

Changing key bindings in the GUI

[Maria Gouskova]

Hi all,

I want to check whether this is a bug or I'm just missing something. I
am using a custom bindings file that calls two other files. The file
looks like this:
##

\bind_file aqua.bind
\bind_file mac.bind

\bind C-ylayout Numbered Examples (consecutive)
\bindC-~S-alayout Subexample
\bindC-/inset-vspace-bigskip


##

These three custom key bindings work without a problem. The problem is
with the daughter bindings files, and I tried to change it through the
GUI but to no avail.

One of the key bindings in the mac.bind file in the lyx.app folder
defines the depth-decrement key binding as:

\bind M-C-Rightdepth-increment

But this does not show up when I look in the LyX: Preferences editing
shortcuts. There, depth-decrement is not shown to have any key
bindings associated with it, and when I clicked on 'modify', the cell
for entering the key binding is grayed out. I thought it was a key
combination conflict between the aqua and mac bindings files, but I
don't see one when I inspect the files.

So, I guess I wonder why the mac.bind definition is not working, and
why the GUI menu for changing the key bindings is not available.

Maria

Re: [LyX/master] On Linux show in crash message box the backtrace

[Scott Kostyshak]

On Sat, Jun 14, 2014 at 5:26 AM, Peter Kümmel kuem...@lyx.org wrote:
 commit 2f17858115247a1f2b9e341e7cbe96148911c1ad
 Author: Peter Kümmel syntheti...@gmx.net
 Date:   Sat Jun 7 11:12:31 2014 +0200

 On Linux show in crash message box the backtrace

Would this be easy to extend to show the backtrace on assertions also?

Scott

Re: LyX+Qt5 build (CMake+XCode) on OS X

[Patrick De Visschere]

Sent from my iPad

> On 25 Aug 2014, at 07:55, Stephan Witt  wrote:
> 
>> Am 23.08.2014 um 18:01 schrieb Patrick De Visschere :
>> 
>>> On 23 Aug, 2014, at 14:50 , Stephan Witt  wrote:
>>> 
 Am 23.08.2014 um 12:01 schrieb Patrick De Visschere 
 :
 
> On 20 Aug, 2014, at 23:15 , Stephan Witt  wrote:
> 
>> Am 20.08.2014 um 22:45 schrieb Patrick De Visschere 
>> :
>> 
>>> On 20 Aug, 2014, at 11:22 , Stephan Witt  wrote:
>>> 
 Am 19.08.2014 um 22:41 schrieb Patrick De Visschere 
 :
 
> On 19 Aug, 2014, at 14:12 , Stephan Witt  wrote:
> 
> Am 17.08.2014 um 20:13 schrieb Patrick De Visschere 
> :
 
 My environment
 
 * Mac OS X 10.9.4
 * Darwin Kernel Version 13.3.0
 * Qt 5.3.1 (stable branch) (default Cocoa)
 ./configure -opensource -silent -shared -release -no-dbus -nomake 
 examples -nomake tools -no-framework
>>> 
>>> You don't build the libraries as frameworks. I'm not sure if this makes 
>>> no difference.
>>> 
>>> I'm using the Qt frameworks I've build myself.
>>> 
>>> Stephan
>> 
>> Stephan,
>> 
>> I was planning to do that. (the qt-debug build does not make a 
>> difference as you expected)
>> 
>> I suppose you use the LyX-Mac-binary-release.sh script.
>> 
>> I have never managed to use this script without making changes to it, 
>> perhaps because I’m using it the wrong way.
>> 
>> I build qt as a framework separately and would then use the script like:
>> 
>> sh development/LyX-Mac-binary-release.sh  --with-qt-frameworks=yes  
>> --with-qt-dir=/Users/pdv/Developer/public/Trolltech/Qt-5.3.1 
>> --qt-deployment=yes --with-macosx-target=10.8 --with-sdkroot=10.8 
>> --with-arch=x86_64 --with-libiconv-prefix=/opt/local --enable-debug
>> 
>> I think the --with-qt-frameworks=yes is needed to include qt as a 
>> framework;
>> 
>> and --with-qt-dir=/… points to the dir where the  qt-framework has been 
>> installed (previously).
>> 
>> I’m not sure about the exact meaning of --qt-deployment=yes  but I think 
>>  I need it too.
>> 
>> What I don’t understand are the lines 260-262
>> if [ "${configure_qt_frameworks}" != "yes" ]; then
>>QtInstallDir=${QTDIR:-"/opt/qt4"}
>> fi
>> 
>> with --with-qt-frameworks=yes, QtInstallDir is not set.
>> 
>> Therefore I uncomment the if/fi so that
>> QtInstallDir=${QTDIR:-"/opt/qt4”}
>> 
>> is always executed and QtInstallDir points to my qt-install dir.
>> 
>> In addition I must modify some CPPFLAGS= ...
>> 
>> Any idea what I’m doing wrong?
>> 
>> Patrick De Visschere
> 
> Perhaps I should remove the --with-qt-frameworks switch. I don't use it 
> anymore
> and it was meant as "with the frameworks by Qt (Nokia)". The 
> --qt-deployment=yes
> is default and with it the script copies the frameworks to the package. 
> This is
> needed if you want to use the LyX app on another system.
> 
> I'd avoid the --with-libiconv-prefix=/opt/local switch.
> 
> This is the shell script I'm using for calling LyX-Mac-binary-release.sh:
> 
> #!/bin/sh
> ARCH=x86_64
> QtVersion=5.3.1
> QtAPI=-cocoa
> LyXVersion=lyx
> CC=cc CXX=c++ \
> QtConfigureOptions="-debug-and-release" QtAPI=${QtAPI} 
> QtVersion=${QtVersion} \
> sh ${MKFLAGS} ${LyXVersion}/development/LyX-Mac-binary-release.sh \
> --with-sdkroot=10.8 --with-macosx-target=10.6 --with-arch=${ARCH} \
> --with-qt-dir=/Users/Shared/LyX/qt-${QtVersion}-frameworks${QtAPI}-${ARCH}
>  \
> "$@"
> 
> Stephan
 
 I’ve build LyX+Qt5 with the LyX-Mac-binary-release.sh script and the 
 menubar appears immediately. Since with XCode I use the macports iconv 
 library that could still theoretically be the culprit. Or maybe it’s just 
 due to Xcode. Anyway this is not very important;
 I tried to build (with Xcode) without aspell and hunspell but somehow 
 cmake doesn’t want that.
>>> 
>>> This is my script to call cmake for Xcode project generation:
>>> 
>>> #!/bin/sh
>>> export PATH="/Users/Shared/LyX/qt-5.3.1-frameworks-cocoa-x86_64/bin:${PATH}"
>>> LyxSourceDir="$(pwd)/lyx"
>>> LyxUtilDir="/Users/Shared/LyX/utilities"
>>> CMAKE_GENERATOR="Xcode"
>>> LyXVersion=$(grep AC_INIT "${LyxSourceDir}"/configure.ac | cut -d, -f2 | tr 
>>> -d " ()")
>>> LyxBuildDir=lyx-build/cmake/"${LyXVersion}"
>>> if [ -f "${LyxSourceDir}/development/cmake/CMakeLists.txt" ]; then
>>> TOPCMAKE="${LyxSourceDir}/development/cmake"
>>> COPYRESOURCES="yes"
>>> else
>>> 

Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph

[Jürgen Spitzmüller]

Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
> This commit seems ('git bisect run' tells me. I have not confirmed) to
> have broken export of the Japanese beamer manual to DVI. I think it
> also breaks two other tests:
> 3632 - export/examples/ja/beamer_pdf (Failed)
> 3634 - export/examples/ja/beamer_pdf3 (Failed)

Thanks. Could you file a new report for this? I am quite busy ATM but will have 
a look at it eventually.

Jürgen

QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
The reasoning is to disable all platform specific code and force the Qt users
like us to review all code guarded by Q_WS_ macros. This means all code in LyX
inside these ifdef's is not compiled and executed anymore with Qt5.

My question now is: should we simply replace all Q_WS_ macros with the 
corresponding Q_OS_ macro for all platforms or should this be done for every
platform in separate steps?

The first patch does this for all platforms - in case someone wants to test it 
too.
The second one is for Mac OS X only. I'll plan to commit the second one if I 
don't
get enough encouraging feedback for the first one.

With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.

Stephan



2014-08-25-Qt5-all-platforms.patch
Description: Binary data


2014-08-25-Qt5-mac-platform.patch
Description: Binary data

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 15:53 schrieb Stephan Witt :

> Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
> The reasoning is to disable all platform specific code and force the Qt users
> like us to review all code guarded by Q_WS_ macros. This means all code in LyX
> inside these ifdef's is not compiled and executed anymore with Qt5.
> 
> My question now is: should we simply replace all Q_WS_ macros with the 
> corresponding Q_OS_ macro for all platforms or should this be done for every
> platform in separate steps?
> 
> The first patch does this for all platforms - in case someone wants to test 
> it too.
> The second one is for Mac OS X only. I'll plan to commit the second one if I 
> don't
> get enough encouraging feedback for the first one.
> 
> With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
> 
> Stephan
> 
> <2014-08-25-Qt5-all-platforms.patch><2014-08-25-Qt5-mac-platform.patch>

Sorry for the noise regarding X11 - I see now Q_WS_X11 shouldn't be replaced.

Since only a limited count of lyx devs is able to compile and run windows
I'd guess I stick with the second patch - change it for Mac OS only.

Stephan

Re: QUESTION: How to enable Qt5 for LyX master

[Kornel Benko]

Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
> Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt 
> > Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
> > The reasoning is to disable all platform specific code and force the Qt 
> > users
> > like us to review all code guarded by Q_WS_ macros. This means all code in 
> > LyX
> > inside these ifdef's is not compiled and executed anymore with Qt5.
> > 
> > My question now is: should we simply replace all Q_WS_ macros with the 
> > corresponding Q_OS_ macro for all platforms or should this be done for every
> > platform in separate steps?
> > 
> > The first patch does this for all platforms - in case someone wants to test 
> > it too.
> > The second one is for Mac OS X only. I'll plan to commit the second one if 
> > I don't
> > get enough encouraging feedback for the first one.
> > 
> > With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
> > 
> > Stephan
> 
> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
> compilation.
> 

To be more specific

FindQt4.cmake:
We should check for Q_WS_X11, but assign variable Q_OS_X11.

Kornel

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

Re: QUESTION: How to enable Qt5 for LyX master

[Kornel Benko]

Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt 
> Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
> The reasoning is to disable all platform specific code and force the Qt users
> like us to review all code guarded by Q_WS_ macros. This means all code in LyX
> inside these ifdef's is not compiled and executed anymore with Qt5.
> 
> My question now is: should we simply replace all Q_WS_ macros with the 
> corresponding Q_OS_ macro for all platforms or should this be done for every
> platform in separate steps?
> 
> The first patch does this for all platforms - in case someone wants to test 
> it too.
> The second one is for Mac OS X only. I'll plan to commit the second one if I 
> don't
> get enough encouraging feedback for the first one.
> 
> With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
> 
> Stephan

At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
compilation.

Kornel

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

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 16:12 schrieb Kornel Benko :

> Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
>> Am Montag, 25. August 2014 um 15:53:14, schrieb Stephan Witt 
>> 
>>> Since Qt5 the Qt developers decided to not define the Q_WS_ macros anymore.
>>> The reasoning is to disable all platform specific code and force the Qt 
>>> users
>>> like us to review all code guarded by Q_WS_ macros. This means all code in 
>>> LyX
>>> inside these ifdef's is not compiled and executed anymore with Qt5.
>>> 
>>> My question now is: should we simply replace all Q_WS_ macros with the 
>>> corresponding Q_OS_ macro for all platforms or should this be done for every
>>> platform in separate steps?
>>> 
>>> The first patch does this for all platforms - in case someone wants to test 
>>> it too.
>>> The second one is for Mac OS X only. I'll plan to commit the second one if 
>>> I don't
>>> get enough encouraging feedback for the first one.
>>> 
>>> With one of them applied I'm able to use LyX with Qt5.3.1 on a Mac 10.8.6.
>>> 
>>> Stephan
>> 
>> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4 
>> compilation.
>> 
> 
> To be more specific
> 
> FindQt4.cmake:
> We should check for Q_WS_X11, but assign variable Q_OS_X11.

Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5 
either.

Stephan

Re: [LyX/master] Fix bug with wrong baseline calculation in last paragraph

[Scott Kostyshak]

On Mon, Aug 25, 2014 at 8:28 AM, Jürgen Spitzmüller  wrote:
> Am Samstag 23 August 2014, 08:10:45 schrieb Scott Kostyshak:
>> This commit seems ('git bisect run' tells me. I have not confirmed) to
>> have broken export of the Japanese beamer manual to DVI. I think it
>> also breaks two other tests:
>> 3632 - export/examples/ja/beamer_pdf (Failed)
>> 3634 - export/examples/ja/beamer_pdf3 (Failed)
>
> Thanks. Could you file a new report for this? I am quite busy ATM but will 
> have
> a look at it eventually.

Sure, I created it at #9250. Let me know if you cannot get to it
before 2.1.2 and I will fix the document manually.

Scott

Warnings due to x***arrow commit

[Richard Heck]

CXX InsetMathXArrow.o


../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void 
lyx::InsetMathXArrow::mathmlize(lyx::MathStream&) const':


../../src/mathed/InsetMathXArrow.cpp:116:8: warning: 'arrow' may be used 
uninitialized in this function [-Wmaybe-uninitialized]


<< arrow << cell(1) << cell(0)

^

../../src/mathed/InsetMathXArrow.cpp: In member function 'virtual void 
lyx::InsetMathXArrow::htmlize(lyx::HtmlStream&) const':


../../src/mathed/InsetMathXArrow.cpp:157:43: warning: 'arrow' may be 
used uninitialized in this function [-Wmaybe-uninitialized]


<< MTag("span", "class='xabottom'") << arrow << ETag("span")

Re: QUESTION: How to enable Qt5 for LyX master

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:

> 
> Am 25.08.2014 um 16:12 schrieb Kornel Benko :
> 
> > Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
> > 
> >> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
> >> compilation.
> >> 
> > 
> > To be more specific
> > 
> > FindQt4.cmake:
> > We should check for Q_WS_X11, but assign variable Q_OS_X11.
> 
> Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5
> either.

Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
othewise it will not compile with Qt5. For example, the QWindowsMime class
is not available anymore and, until they make it available again, that
guard should not be replaced. So, I suggest to replace the guards only
if you are able to check the result.

Another side effect is that my Qt5 port for cygwin will require its own
guard now that Q_WS_WIN is not available anymore. I wonder what they were
drinking when that decision was taken...

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote:

> commit 565260126eb106ab00049285627417e73736bb96
> Author: Enrico Forestieri 
> Date:   Mon Aug 25 18:35:15 2014 +0200
> 
> Fix the -geometry command line argument for Windows.
> 
> The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF
> specifies a preferred size and location for the main window.
> Currently, this is semi-broken on Windows. Indeed, only
> specifying WIDTH and HEIGHT places the main window such that
> the left and top borders are invisible such that the window cannot
> be moved. Moreover, the XOFF and YOFF parts (when present) are
> used to specify the distance of the window from the left and top
> or right and bottom edges of the screen, when using '+' or '-',
> respectively. However, -geometry 800x600-20-20, instead of placing
> the window such that its bottom and right edges are at a distance
> of 20 pixels from the corresponding screen edges, places the
> window such that its left and top borders are out of the screen.
> This is corrected by this commit, which also addresses the fact
> that Qt5 does not define Q_WS_WIN anymore.

Richard, may I apply this to the stable branch?
(Minus the Qt5 part, of course)

> diff --git a/src/frontends/qt4/GuiApplication.cpp 
> b/src/frontends/qt4/GuiApplication.cpp
> index 56cbd60..64c645d 100644
> --- a/src/frontends/qt4/GuiApplication.cpp
> +++ b/src/frontends/qt4/GuiApplication.cpp
> @@ -87,6 +87,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2193,16 +2194,40 @@ void GuiApplication::createView(QString const & 
> geometry_arg, bool autoShow,
>   }
>  
>   if (!geometry_arg.isEmpty()) {
> -#ifdef Q_WS_WIN
> +#if defined(Q_OS_WIN) || defined(Q_CYGWIN_WIN)
>   int x, y;
>   int w, h;
> - QRegExp re( "[=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[ 
> ]*(?:([+-][0-9]*)([+-][0-9]*)){0,1}" );
> + QChar sx, sy;
> + QRegExp re( "[=]*(?:([0-9]+)[xX]([0-9]+)){0,1}[ 
> ]*(?:([+-][0-9]*)){0,1}(?:([+-][0-9]*)){0,1}" );
>   re.indexIn(geometry_arg);
>   w = re.cap(1).toInt();
>   h = re.cap(2).toInt();
>   x = re.cap(3).toInt();
>   y = re.cap(4).toInt();
> + sx = re.cap(3).isEmpty() ? '+' : re.cap(3).at(0);
> + sy = re.cap(4).isEmpty() ? '+' : re.cap(4).at(0);
> + // Set initial geometry such that we can get the frame size.
>   view->setGeometry(x, y, w, h);
> + int framewidth = view->geometry().x() - view->x();
> + int titleheight = view->geometry().y() - view->y();
> + // Negative displacements must be interpreted as distances
> + // from the right or bottom screen borders.
> + if (sx == '-' || sy == '-') {
> + QRect rec = QApplication::desktop()->screenGeometry();
> + if (sx == '-')
> + x += rec.width() - w - framewidth;
> + if (sy == '-')
> + y += rec.height() - h - titleheight;
> + view->setGeometry(x, y, w, h);
> + }
> + // Make sure that the left and top frame borders are visible.
> + if (view->x() < 0 || view->y() < 0) {
> + if (view->x() < 0)
> + x = framewidth;
> + if (view->y() < 0)
> + y = titleheight;
> + view->setGeometry(x, y, w, h);
> + }
>  #endif
>   }
>   view->setFocus();

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Richard Heck]

On 08/25/2014 01:01 PM, Enrico Forestieri wrote:

On Mon, Aug 25, 2014 at 06:54:05PM +0200, Enrico Forestieri wrote:


commit 565260126eb106ab00049285627417e73736bb96
Author: Enrico Forestieri 
Date:   Mon Aug 25 18:35:15 2014 +0200

 Fix the -geometry command line argument for Windows.
 
 The command line argument -geometry WIDTHxHEIGHT±XOFF±YOFF

 specifies a preferred size and location for the main window.
 Currently, this is semi-broken on Windows. Indeed, only
 specifying WIDTH and HEIGHT places the main window such that
 the left and top borders are invisible such that the window cannot
 be moved. Moreover, the XOFF and YOFF parts (when present) are
 used to specify the distance of the window from the left and top
 or right and bottom edges of the screen, when using '+' or '-',
 respectively. However, -geometry 800x600-20-20, instead of placing
 the window such that its bottom and right edges are at a distance
 of 20 pixels from the corresponding screen edges, places the
 window such that its left and top borders are out of the screen.
 This is corrected by this commit, which also addresses the fact
 that Qt5 does not define Q_WS_WIN anymore.

Richard, may I apply this to the stable branch?


We are string frozen at the moment. No string changes here?

Richard

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote:
> 
> We are string frozen at the moment. No string changes here?

Yes, no string is changed.

-- 
Enrico

Re: [LyX/master] Fix the -geometry command line argument for Windows.

[Richard Heck]

On 08/25/2014 01:09 PM, Enrico Forestieri wrote:

On Mon, Aug 25, 2014 at 01:06:34PM -0400, Richard Heck wrote:

We are string frozen at the moment. No string changes here?

Yes, no string is changed.


OK, then.

rh

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 17:54 schrieb Enrico Forestieri :

> On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
> 
>> 
>> Am 25.08.2014 um 16:12 schrieb Kornel Benko :
>> 
>>> Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
>>> 
 At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
 compilation.
 
>>> 
>>> To be more specific
>>> 
>>> FindQt4.cmake:
>>> We should check for Q_WS_X11, but assign variable Q_OS_X11.
>> 
>> Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within Qt5
>> either.
> 
> Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
> othewise it will not compile with Qt5. For example, the QWindowsMime class
> is not available anymore and, until they make it available again, that
> guard should not be replaced. So, I suggest to replace the guards only
> if you are able to check the result.

Ok, I'll do it then this way. Thanks.

> Another side effect is that my Qt5 port for cygwin will require its own
> guard now that Q_WS_WIN is not available anymore. I wonder what they were
> drinking when that decision was taken…

+1

Stephan

> 
> -- 
> Enrico

Re: QUESTION: How to enable Qt5 for LyX master

[Enrico Forestieri]

On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote:

> On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
> 
> > 
> > Am 25.08.2014 um 16:12 schrieb Kornel Benko :
> > 
> > > Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
> > > 
> > >> At least on QT4 there is no symbol Q_OS_X11. So this patch would break 
> > >> QT4
> > >> compilation.
> > >> 
> > > 
> > > To be more specific
> > > 
> > > FindQt4.cmake:
> > > We should check for Q_WS_X11, but assign variable Q_OS_X11.
> > 
> > Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within 
> > Qt5
> > either.
> 
> Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
> othewise it will not compile with Qt5. For example, the QWindowsMime class
> is not available anymore and, until they make it available again, that
> guard should not be replaced. So, I suggest to replace the guards only
> if you are able to check the result.
> 
> Another side effect is that my Qt5 port for cygwin will require its own
> guard now that Q_WS_WIN is not available anymore. I wonder what they were
> drinking when that decision was taken...

I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
for Qt5. The remaining ones are those related to code that doesn't compile
on Qt5, ATM.

-- 
Enrico

Re: QUESTION: How to enable Qt5 for LyX master

[Stephan Witt]

Am 25.08.2014 um 19:58 schrieb Enrico Forestieri :

> On Mon, Aug 25, 2014 at 05:54:08PM +0200, Enrico Forestieri wrote:
> 
>> On Mon, Aug 25, 2014 at 04:18:02PM +0200, Stephan Witt wrote:
>> 
>>> 
>>> Am 25.08.2014 um 16:12 schrieb Kornel Benko :
>>> 
 Am Montag, 25. August 2014 um 16:08:27, schrieb Kornel Benko 
 
> At least on QT4 there is no symbol Q_OS_X11. So this patch would break QT4
> compilation.
> 
 
 To be more specific
 
 FindQt4.cmake:
 We should check for Q_WS_X11, but assign variable Q_OS_X11.
>>> 
>>> Yes, my fault, Q_OS_X11 is not defined. But Q_WS_X11 doesn't exist within 
>>> Qt5
>>> either.
>> 
>> Not only that. Some of the Q_WS_WIN guards should not be replaced at all,
>> othewise it will not compile with Qt5. For example, the QWindowsMime class
>> is not available anymore and, until they make it available again, that
>> guard should not be replaced. So, I suggest to replace the guards only
>> if you are able to check the result.
>> 
>> Another side effect is that my Qt5 port for cygwin will require its own
>> guard now that Q_WS_WIN is not available anymore. I wonder what they were
>> drinking when that decision was taken...
> 
> I went ahead and replaced almost all occurrences of Q_WS_WIN as appropriate
> for Qt5. The remaining ones are those related to code that doesn't compile
> on Qt5, ATM.

Ok, I did it for Q_WS_MACX now.

Stephan

Changing key bindings in the GUI

[Maria Gouskova]

Hi all,

I want to check whether this is a bug or I'm just missing something. I
am using a custom bindings file that calls two other files. The file
looks like this:
##

\bind_file aqua.bind
\bind_file mac.bind

\bind "C-y""layout Numbered Examples (consecutive)"
\bind"C-~S-a""layout Subexample"
\bind"C-/""inset-vspace-bigskip"


##

These three custom key bindings work without a problem. The problem is
with the daughter bindings files, and I tried to change it through the
GUI but to no avail.

One of the key bindings in the mac.bind file in the lyx.app folder
defines the depth-decrement key binding as:

\bind "M-C-Right""depth-increment"

But this does not show up when I look in the LyX: Preferences editing
shortcuts. There, depth-decrement is not shown to have any key
bindings associated with it, and when I clicked on 'modify', the cell
for entering the key binding is grayed out. I thought it was a key
combination conflict between the aqua and mac bindings files, but I
don't see one when I inspect the files.

So, I guess I wonder why the mac.bind definition is not working, and
why the GUI menu for changing the key bindings is not available.

Maria

Re: [LyX/master] On Linux show in crash message box the backtrace

[Scott Kostyshak]

On Sat, Jun 14, 2014 at 5:26 AM, Peter Kümmel  wrote:
> commit 2f17858115247a1f2b9e341e7cbe96148911c1ad
> Author: Peter Kümmel 
> Date:   Sat Jun 7 11:12:31 2014 +0200
>
> On Linux show in crash message box the backtrace

Would this be easy to extend to show the backtrace on assertions also?

Scott