Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.

[pdv]

On 29/03/2024 22:40, pdv wrote:

On 29/03/2024 11:31, Jean-Marc Lasgouttes wrote:

Le 28/03/2024 à 23:04, pdv a écrit :

I submitted the following bug report

https://bugreports.qt.io/browse/QTBUG-123848

pdv


Hi Patrick,

Thanks for doing that!
Frankly I don't use shortcuts very often and I never use asian 
languages, but I cannot resist a challenge. Therefore I gave it a try 
and came to the conclusion that there is no easy way out.


An alternative idea I had was be to install a
global event filter at GuiApplication level that would detect and 
handle shortcut. Does this seem possible to you? And if yes, does this 
seem like a good idea or a kludge?


I have indeed only looked to the key handling at the Widget level.
Is there a possibility to receive all key events at the application 
level? If yes then maybe your proposal might work.

But shouldn't key handling be done preferentially by the widget involved?

With the qt5 behavior lyx could handle all situations correctly and 
AquaSKK should have done something similar.


We'll see what the qt-developers think about it. They may have had other 
reasons for switching the behavior.


pdv



JMarc




Tor Arne Vestbø posted a qt-patch solving this issue.
See: https://bugreports.qt.io/browse/QTBUG-123848

pdv

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

Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.

[pdv]

On 29/03/2024 11:31, Jean-Marc Lasgouttes wrote:

Le 28/03/2024 à 23:04, pdv a écrit :

I submitted the following bug report

https://bugreports.qt.io/browse/QTBUG-123848

pdv


Hi Patrick,

Thanks for doing that!
Frankly I don't use shortcuts very often and I never use asian 
languages, but I cannot resist a challenge. Therefore I gave it a try 
and came to the conclusion that there is no easy way out.


An alternative idea I had was be to install a
global event filter at GuiApplication level that would detect and handle 
shortcut. Does this seem possible to you? And if yes, does this seem 
like a good idea or a kludge?


I have indeed only looked to the key handling at the Widget level.
Is there a possibility to receive all key events at the application 
level? If yes then maybe your proposal might work.

But shouldn't key handling be done preferentially by the widget involved?

With the qt5 behavior lyx could handle all situations correctly and 
AquaSKK should have done something similar.


We'll see what the qt-developers think about it. They may have had other 
reasons for switching the behavior.


pdv



JMarc



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

Re: Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.

[pdv]

I submitted the following bug report

https://bugreports.qt.io/browse/QTBUG-123848

pdv

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

Comment on ticket 12641 regarding handling of some short cuts on macos with qt6.

[pdv]

This contains a report on an issue discussed in 
https://www.lyx.org/trac/ticket/12641. I have also looked at it and this 
is my conclusion. At this time the only feasible partial remedy I see 
would be to switch IM on/off depending on the language input selected by 
the user. This would solve the problem for roman languages and limit it 
to asian languages. Of course it would be better if qt6's switch of 
behaviour was reversed.
If there are no objections I would like to send the following to a 
relevant qt-forum.


pdv



Since qt commit https://github.com/qt/qtbase/commit/9e1875483ceaf90 the 
handling of some short cuts by LyX (https://www.lyx.org/) on macos 
doesn't work anymore.


In that commit the default handling of key events was reversed. Before 
this commit key events were send for all key presses unless they were 
handled by the "input method" (IM) system primarely used by complex 
(asian) languages. After this commit. IM became the default system and 
key events are only send in 2 cases: simple text and commands involving 
a single modifier key. In a later commit a cancel operation was added as 
a third exception. The only way to revert to the former behaviour is to 
switch IM off by setting WA_InputMethodEnabled=false.


Before this change of behaviour LyX could deal with both systems with 
the IM switched on by default. After the switch the issuing of commands 
involving 2 modifier keys (e.g. ^CmdE to switch emphasis) did no longer 
work.


A very similar problem was reported in QTBUG-106516 and contains this 
comment, by Tor Arne Vestbø:


"... Input methods should only be enabled for controls that are doing 
"text input", where you want the text input system of the OS to play a 
part (for example in composing characters for languages like Korean or 
Japanese). In your case you are not doing text input, you are processing 
"raw" key events, so disabling IM makes sense, including on Windows and 
Linux."


Since the user might input asian language text, switching the IM off is 
not a solution. LyX could switch IM on or off depending on the keyboad 
input chosen by the user (asian or roman). This would solve the problem 
for roman languages but not for asian languages. After all I suppose 
that al least some 2-modifier commands also make sense for an asian 
language.


The question arises why the behaviour of qt has been reversed. This was 
to remedy QTDEBUG-46300. AquaSKK is an IM to input Japanese and it uses 
^I to switch the language on/off. In other words when inputting japanese 
characters AquaSKK still expects that ^I is handled regularly, and 
therefore the behaviour was reversed. (of course AquaSKK could easily 
have filtered out this one command). But the change was justified as 
follows:


"... The reason for this is that Qt's IM protocol was designed to handle 
composited text, so sending non-composited (but IM-initiated) text input 
as IM events is unexpected"


Fair enough, but I suppose that commands involving 2 modifier keys (or 
even more) also fall in this category and should also be handled as 
oridinary key events and not by the IM. But this may just be the 
beginning of an endless list of exceptions.
Was this reversion really the best possible solution for handling the 
initial bug?


Sources and references:

qt commits

   https://github.com/qt/qtbase/commit/9e1875483ceaf90

https://github.com/qt/qtbase/commit/60caec953f76b1c63ff526c84cc968b5f83eabdf

https://github.com/qt/qtbase/commit/57e99441102f96dd0180a6ead84d8e8b3bd6b6f0

qt bug reports

   https://bugreports.qt.io/browse/QTBUG-46300
   https://bugreports.qt.io/browse/QTBUG-71394
   https://bugreports.qt.io/browse/QTBUG-106516

=

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

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 20/03/2024 11:26, Pavel Sanda wrote:

On Tue, Mar 19, 2024 at 04:02:34PM +0100, pdv wrote:

These steps have been added to my previous patch (new patch included) and I
also derived the QT_PLUGINS_DIR and QT_LIBRARY_DIRS variables from the
existing Qt6_DIR/Qt5_DIR variable, so they must not longer be supplied.


I see there is some very old bug related to osx budles, pehaps it should be 
closed?
https://www.lyx.org/trac/ticket/9018


I only tested this with Qt6.


Unf we are staying out of Qt6 for mac because of serious issues we were not 
able to solve
(see bug https://www.lyx.org/trac/ticket/12641 ).

Pavel


That will not be so easy (with cmake).
The signing issue also holds for Qt5.

I've done my homework again.
I realized that my previous solution (although it worked for me) was not 
ideal. I can't remember why anymore but for Qt6 I copied just all the 
plugins, which of course worked but was ineffective.


It's clear now that (for installing a bundle on macos with cmake) there 
is no difference between Qt5 (supposed the version is GTE 5.10) and Qt6.


This makes things much simpler.

But at least with the latest macos tools (Sonoma and XCode15) a bundle 
refuses to run if it 's not signed properly.


Both issues are solved with the patch included and have now been tested 
with Qt5.15 and Qt6.7.


For completeness: I've checked the font-emph shortcut issue and, as 
reported in the ticket mentioned, ^CmdE works with Qt5.15 but not with 
Qt6.7. However the sequence ^C E does work. I don't know whether this is 
intended as a workaround for this issue or was already implemented.


pdvdiff --git a/development/cmake/post_install/CMakeLists.txt 
b/development/cmake/post_install/CMakeLists.txt
index 52a2f782af..b2346cac44 100644
--- a/development/cmake/post_install/CMakeLists.txt
+++ b/development/cmake/post_install/CMakeLists.txt
@@ -26,18 +26,28 @@ if(LYX_BUNDLE)
 set(qtplugin_dest_dir "${LYX_BUNDLE_NAME}.app/Contents")
 set(qt_conf_path "${LYX_BUNDLE_NAME}.app/Contents/Resources/qt.conf")
 endif()
-
-if(Qt5Core_FOUND)
-   file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/imageformats")
-   install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime REGEX "\\_debug\\.dylib$" 
EXCLUDE)
-   if(APPLE)
-   if(Qt5Core_VERSION VERSION_GREATER_EQUAL 5.10.0)
-   install_qt_plugin("Qt5::QMacStylePlugin")
-   endif()
-install_qt_plugin("Qt5::QCocoaIntegrationPlugin")
+
+if(${LYX_USE_QT} STREQUAL "QT5")
+   set(QtScope "Qt5")
+elseif(${LYX_USE_QT} STREQUAL "QT6")
+   set(QtScope "Qt6")
+endif()
+
+get_target_property( MyLoc "${QtScope}::QSvgPlugin" LOCATION)
+get_filename_component(MyDir ${MyLoc} PATH)
+set(QT_PLUGINS_DIR ${MyDir}/..)
+set(QT_LIBRARY_DIRS ${QT_PLUGINS_DIR}/../lib)
+
+file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/imageformats")
+install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime REGEX "\\_debug\\.dylib$" 
EXCLUDE)
+
+if(APPLE)
+   if(Qt6Core_FOUND OR (Qt5Core_FOUND AND (Qt5Core_VERSION 
VERSION_GREATER_EQUAL 5.10.0)))
+  install_qt_plugin("${QtScope}::QMacStylePlugin")
endif()
+   install_qt_plugin("${QtScope}::QCocoaIntegrationPlugin")
 endif()
-
+
 # Install code does the following:
 # - Creates the qt.conf file
 # - install the platform specific plugins (with Qt5)
@@ -50,7 +60,13 @@ if(LYX_BUNDLE)
 
fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/${installed_lyx_path}\" 
\"\${QTPLUGINS}\" \"${QT_LIBRARY_DIRS}\")" 
 COMPONENT Runtime
 )
-
+
+if(APPLE)
+   # fixup_bundle invalidates the codesign, so the app must be signed 
again.
+   add_custom_target(sign_install WORKING_DIRECTORY ${CMAKE_INSTALL_PREFIX}
+   COMMAND /usr/bin/codesign --deep --force --sign 
"${CPACK_BUNDLE_APPLE_CERT_APP}" "LyX2.4.app" VERBATIM)
+endif()
+
 if (APPLE AND LYX_DMG)
 # Setup the disk image layout
 install(CODE "
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 07/11/2023 17:42, pdv wrote:

On 06/11/2023 19:17, pdv wrote:

On 04/11/2023 20:35, Kornel Benko wrote:

Am Sat, 4 Nov 2023 18:05:42 +0100
schrieb pdv :


On 04/11/2023 17:55, pdv wrote:

On 21/03/2023 19:27, Kornel Benko wrote:

Am Tue, 21 Mar 2023 15:27:41 +0100
schrieb pdv :


On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :
It's within the first if() else(), that's thus for qt6(see 
below). I
suppose this should work for all platforms, but I checked it on 
macos
only. Your patch is limited to APPLE and also works for me; If 
this
problem doesn't occur for other platforms, it's ok for me of 
course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be 
interested

if it works for
you too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

 Kornel






Good, so I will disable this option for lyx2.5 then.

 Kornel


I have build the latest lyx-master and I still need my (previous) 
patch
to build a LyX.app which includes all required Qt6 frameworks (I 
want a

stand-alone app).

I'm using a recent version of CMake and apparently versions older than
3.5 will not longer be supported. To get rid of the annoying warnings
I've upped the minimum version from 3.1 to 3.5 (new patch included).

pdv


Sorry, forgot to include the patch.


Will be done for 2.4.x versions. Also for other CMakeLists.txt's in 
the lyx-sources.


Kornel



OK, thanks.

Regarding the original issue, I'm still largely in the dark.

I've build qt-6.2 (-debug-and-release option), installed cmake3.26 and 
I'm using macos 10.14 and xcode. lyx has been updated to a very recent 
master-version.


Building a complete (qt frameworks included) debuggable LyX2.4.app 
with cmake does not work for me; the plug-ins are not copied into the 
bundle and cmake's fixup_bundle step subsequently fails.


When I apply my patch (see first message) the plugins are copied but 
the fixup_bundle step still fails.


Only the QtCore, ... frameworks have been copied to the bundle 
(probably by the install command in my patch), but not the 
QtCore_debug, ... versions, although no error is reported by 
fixup_bundle at copy time.


That's because they are copied to a folder named /@rpath/ in my 
build-folder instead of into the bundle.
Apparently the @rpath used in the qt libraries is not handled properly 
by the cmake scripts.


Can anyone confirm that a stand-alone LyX2.4.app can be build with 
cmake on macos or have any other suggestion?


pdv



The problem with the _debug libraries is obvious. As for qt5 no _debug 
libraries should be copied for qt6 either. I adapted my patch (included) 
accordingly.


I once more tested a number of configurations and this is my conclusion.
I can build a bundle with LYX_DMG=off and LYX_BUNDLE=on, the latter sets 
also LYX_CPACK=on.


These are my resulting settings after cmake configure:

LYX_ENABLE_BUILD_TYPE:STRING   = AUTO   : Allows to tweak the 
compiled code (AUTO release prerelease development gprof)
     LYX_CPACK:BOOL = ON : Use the CPack 
management (Implies LYX_INSTALL option)
     LYX_LOCALVERSIONING:BOOL   = ON : Add version info to 
created package name (only used if LYX_CPACK option set)
     LYX_INSTALL:BOOL   = OFF    : Build install 
projects/rules (implies a bunch of other options)
     LYX_NLS:BOOL   = ON : Enable Native 
Language Support (NLS)
     LYX_REQUIRE_SPELLCHECK:BOOL    = OFF    : Abort if no 
spellchecker available

     LYX_ASPELL:BOOL    = ON : Require aspell
     LYX_ENCHANT:BOOL   = OFF    : Require Enchant
     LYX_HUNSPELL:BOOL  = ON : Require Hunspell
     LYX_RELEASE:BOOL   = ON : Build release 
version, build debug when disabled

     LYX_DEBUG:BOOL = OFF    : Enforce debug build
     LYX_NO_OPTIMIZE:BOOL   = OFF    : Don't use any 
optimization/debug flags
     LYX_ENABLE_ASSERTIONS:BOOL = ON : Run sanity checks in 
the program
     LYX_PACKAGE_SUFFIX:BOOL    = ON : Use version suffix 
for packaging
     LYX_SUFFIX_VALUE:STRING    =    : Use this string as 
suffix

     LYX_PCH:BOOL   = OFF    : Use precompiled headers
     LYX_MERGE_FILES:BOOL   = OFF    : Merge source files 
into one compilation unit
     LYX_MERGE_REBUILD:BOOL = OFF    : Rebuild generated 
files from merged files build
     LYX_QUIET:BOOL = ON : Don't generate 
verbose makefiles

     LYX_INSTALL_PREFIX:BOOL    = OFF    : Install path for LyX
     LYX_BUNDLE:BOOL    = ON : Build bundle 
(experimental)

     LYX_ENABLE_URLTESTS:BOOL   = OFF    : Enable for URL tests

cmake build on macos (Sonoma, XCode) fails and remedy

[pdv]

Using the latest commit and building lyx with cmake on macos-sonoma with 
xcode fails with multiple error messages like this one:


--
CMake Error in po/CMakeLists.txt:
  The custom command generating

/po/LyX2.4.cat.pot

  is attached to multiple targets:

translations
update-gmo

 but none of these is a common dependency of the other(s).  This is not
 allowed by the Xcode "new build system".
---

These issues are solved by adding the following target dependencies 
(patch included)


add_dependencies(update-gmo translations)
add_dependencies(update-gmo update-po)

add_dependencies(cleanupdatetex2lyxtests updatetex2lyxtests)


pdvdiff --git a/po/CMakeLists.txt b/po/CMakeLists.txt
index 065448e6e5..280b3535eb 100755
--- a/po/CMakeLists.txt
+++ b/po/CMakeLists.txt
@@ -271,4 +271,5 @@ ADD_CUSTOM_TARGET(update-gmo DEPENDS 
${LYX_UPDATED_GMO_FILES})
 ADD_CUSTOM_TARGET(update-po DEPENDS ${LYX_UPDATED_PO_FILES} 
${LYX_UPDATED_GMO_FILES})
 set_target_properties(update-po update-gmo PROPERTIES FOLDER "i18n")
 add_dependencies(update-po translations)
-
+add_dependencies(update-gmo translations)
+add_dependencies(update-gmo update-po)
\ No newline at end of file
diff --git a/src/tex2lyx/test/CMakeLists.txt b/src/tex2lyx/test/CMakeLists.txt
index e620e067c4..7be27f9a13 100644
--- a/src/tex2lyx/test/CMakeLists.txt
+++ b/src/tex2lyx/test/CMakeLists.txt
@@ -105,3 +105,4 @@ add_custom_command(
 
 add_custom_target(cleanupdatetex2lyxtests DEPENDS UpdateFilesRemoved)
 set_target_properties(cleanupdatetex2lyxtests PROPERTIES FOLDER 
"tests/tex2lyx")
+add_dependencies(cleanupdatetex2lyxtests updatetex2lyxtests)
\ No newline at end of file
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 06/11/2023 19:17, pdv wrote:

On 04/11/2023 20:35, Kornel Benko wrote:

Am Sat, 4 Nov 2023 18:05:42 +0100
schrieb pdv :


On 04/11/2023 17:55, pdv wrote:

On 21/03/2023 19:27, Kornel Benko wrote:

Am Tue, 21 Mar 2023 15:27:41 +0100
schrieb pdv :


On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :
It's within the first if() else(), that's thus for qt6(see 
below). I
suppose this should work for all platforms, but I checked it on 
macos

only. Your patch is limited to APPLE and also works for me; If this
problem doesn't occur for other platforms, it's ok for me of 
course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be interested
if it works for
you too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

 Kornel






Good, so I will disable this option for lyx2.5 then.

 Kornel



I have build the latest lyx-master and I still need my (previous) patch
to build a LyX.app which includes all required Qt6 frameworks (I want a
stand-alone app).

I'm using a recent version of CMake and apparently versions older than
3.5 will not longer be supported. To get rid of the annoying warnings
I've upped the minimum version from 3.1 to 3.5 (new patch included).

pdv


Sorry, forgot to include the patch.


Will be done for 2.4.x versions. Also for other CMakeLists.txt's in 
the lyx-sources.


Kornel



OK, thanks.

Regarding the original issue, I'm still largely in the dark.

I've build qt-6.2 (-debug-and-release option), installed cmake3.26 and 
I'm using macos 10.14 and xcode. lyx has been updated to a very recent 
master-version.


Building a complete (qt frameworks included) debuggable LyX2.4.app with 
cmake does not work for me; the plug-ins are not copied into the bundle 
and cmake's fixup_bundle step subsequently fails.


When I apply my patch (see first message) the plugins are copied but the 
fixup_bundle step still fails.


Only the QtCore, ... frameworks have been copied to the bundle (probably 
by the install command in my patch), but not the QtCore_debug, ... 
versions, although no error is reported by fixup_bundle at copy time.


That's because they are copied to a folder named /@rpath/ in my 
build-folder instead of into the bundle.
Apparently the @rpath used in the qt libraries is not handled properly 
by the cmake scripts.


Can anyone confirm that a stand-alone LyX2.4.app can be build with cmake 
on macos or have any other suggestion?


pdv



The problem with the _debug libraries is obvious. As for qt5 no _debug 
libraries should be copied for qt6 either. I adapted my patch (included) 
accordingly.


I once more tested a number of configurations and this is my conclusion.
I can build a bundle with LYX_DMG=off and LYX_BUNDLE=on, the latter sets 
also LYX_CPACK=on.


These are my resulting settings after cmake configure:

LYX_ENABLE_BUILD_TYPE:STRING   = AUTO   : Allows to tweak the 
compiled code (AUTO release prerelease development gprof)
LYX_CPACK:BOOL = ON : Use the CPack 
management (Implies LYX_INSTALL option)
LYX_LOCALVERSIONING:BOOL   = ON : Add version info to 
created package name (only used if LYX_CPACK option set)
LYX_INSTALL:BOOL   = OFF: Build install 
projects/rules (implies a bunch of other options)
LYX_NLS:BOOL   = ON : Enable Native 
Language Support (NLS)
LYX_REQUIRE_SPELLCHECK:BOOL= OFF: Abort if no 
spellchecker available

LYX_ASPELL:BOOL= ON : Require aspell
LYX_ENCHANT:BOOL   = OFF: Require Enchant
LYX_HUNSPELL:BOOL  = ON : Require Hunspell
LYX_RELEASE:BOOL   = ON : Build release 
version, build debug when disabled

LYX_DEBUG:BOOL = OFF: Enforce debug build
LYX_NO_OPTIMIZE:BOOL   = OFF: Don't use any 
optimization/debug flags
LYX_ENABLE_ASSERTIONS:BOOL = ON : Run sanity checks in 
the program
LYX_PACKAGE_SUFFIX:BOOL= ON : Use version suffix 
for packaging

LYX_SUFFIX_VALUE:STRING=: Use this string as suffix
LYX_PCH:BOOL   = OFF: Use precompiled headers
LYX_MERGE_FILES:BOOL   = OFF: Merge source files 
into one compilation unit
LYX_MERGE_REBUILD:BOOL = OFF: Rebuild generated 
files from merged files build
LYX_QUIET:BOOL = ON : Don't generate 
verbose makefiles

LYX_INSTALL_PREFIX:BOOL= OFF: Install path for LyX
LYX_BUNDLE:BOOL= ON : Build bundle 
(experimental)

LYX_ENABLE_URLTESTS:BOOL   = OFF: Enable for URL tests
LYX_ENABLE_EXPORT_TESTS:BOOL   = OFF: Enable for export tests

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 04/11/2023 20:35, Kornel Benko wrote:

Am Sat, 4 Nov 2023 18:05:42 +0100
schrieb pdv :


On 04/11/2023 17:55, pdv wrote:

On 21/03/2023 19:27, Kornel Benko wrote:

Am Tue, 21 Mar 2023 15:27:41 +0100
schrieb pdv :


On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :

It's within the first if() else(), that's thus for qt6(see below). I
suppose this should work for all platforms, but I checked it on macos
only. Your patch is limited to APPLE and also works for me; If this
problem doesn't occur for other platforms, it's ok for me of course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be interested
if it works for
you too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

 Kornel






Good, so I will disable this option for lyx2.5 then.

 Kornel



I have build the latest lyx-master and I still need my (previous) patch
to build a LyX.app which includes all required Qt6 frameworks (I want a
stand-alone app).

I'm using a recent version of CMake and apparently versions older than
3.5 will not longer be supported. To get rid of the annoying warnings
I've upped the minimum version from 3.1 to 3.5 (new patch included).

pdv


Sorry, forgot to include the patch.


Will be done for 2.4.x versions. Also for other CMakeLists.txt's in the 
lyx-sources.

Kornel



OK, thanks.

Regarding the original issue, I'm still largely in the dark.

I've build qt-6.2 (-debug-and-release option), installed cmake3.26 and 
I'm using macos 10.14 and xcode. lyx has been updated to a very recent 
master-version.


Building a complete (qt frameworks included) debuggable LyX2.4.app with 
cmake does not work for me; the plug-ins are not copied into the bundle 
and cmake's fixup_bundle step subsequently fails.


When I apply my patch (see first message) the plugins are copied but the 
fixup_bundle step still fails.


Only the QtCore, ... frameworks have been copied to the bundle (probably 
by the install command in my patch), but not the QtCore_debug, ... 
versions, although no error is reported by fixup_bundle at copy time.


That's because they are copied to a folder named /@rpath/ in my 
build-folder instead of into the bundle.
Apparently the @rpath used in the qt libraries is not handled properly 
by the cmake scripts.


Can anyone confirm that a stand-alone LyX2.4.app can be build with cmake 
on macos or have any other suggestion?


pdv



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

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 04/11/2023 17:55, pdv wrote:

On 21/03/2023 19:27, Kornel Benko wrote:

Am Tue, 21 Mar 2023 15:27:41 +0100
schrieb pdv :


On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :

It's within the first if() else(), that's thus for qt6(see below). I
suppose this should work for all platforms, but I checked it on macos
only. Your patch is limited to APPLE and also works for me; If this
problem doesn't occur for other platforms, it's ok for me of course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be interested 
if it works for

you too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

Kornel






Good, so I will disable this option for lyx2.5 then.

Kornel


I have build the latest lyx-master and I still need my (previous) patch 
to build a LyX.app which includes all required Qt6 frameworks (I want a 
stand-alone app).


I'm using a recent version of CMake and apparently versions older than 
3.5 will not longer be supported. To get rid of the annoying warnings 
I've upped the minimum version from 3.1 to 3.5 (new patch included).


pdv


Sorry, forgot to include the patch.diff --git a/3rdparty/dtl/CMakeLists.txt b/3rdparty/dtl/CMakeLists.txt
index f757b26b17..9b78cf4c0f 100644
--- a/3rdparty/dtl/CMakeLists.txt
+++ b/3rdparty/dtl/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 3.1)
+cmake_minimum_required(VERSION 3.5)
 
 set(LYX_IPO_SUPPORTED FALSE)
 if (POLICY CMP0069)
diff --git a/3rdparty/mythes/CMakeLists.txt b/3rdparty/mythes/CMakeLists.txt
index 869bee7c93..d2175d4167 100644
--- a/3rdparty/mythes/CMakeLists.txt
+++ b/3rdparty/mythes/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 3.1)
+cmake_minimum_required(VERSION 3.5)
 
 set(LYX_IPO_SUPPORTED FALSE)
 if (POLICY CMP0069)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 38e11b8a0b..c4c19ed17c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -4,7 +4,7 @@
 # Copyright (c) 2006-2011 Peter Kümmel, 
 # Copyright (c) 2008-2020 Kornel Benko, 
 
-cmake_minimum_required(VERSION 3.1.0)
+cmake_minimum_required(VERSION 3.5.0)
 
 set(LYX_PROJECT LyX)
 # Instruct cmake to not use gnu extensions,
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 21/03/2023 19:27, Kornel Benko wrote:

Am Tue, 21 Mar 2023 15:27:41 +0100
schrieb pdv :


On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :
   

It's within the first if() else(), that's thus for qt6(see below). I
suppose this should work for all platforms, but I checked it on macos
only. Your patch is limited to APPLE and also works for me; If this
problem doesn't occur for other platforms, it's ok for me of course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be interested if it 
works for
you too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

Kornel

   





Good, so I will disable this option for lyx2.5 then.

Kornel


I have build the latest lyx-master and I still need my (previous) patch 
to build a LyX.app which includes all required Qt6 frameworks (I want a 
stand-alone app).


I'm using a recent version of CMake and apparently versions older than 
3.5 will not longer be supported. To get rid of the annoying warnings 
I've upped the minimum version from 3.1 to 3.5 (new patch included).


pdv

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

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 21/03/2023 11:00, Kornel Benko wrote:

Am Mon, 20 Mar 2023 20:05:32 +0100
schrieb pdv :


It's within the first if() else(), that's thus for qt6(see below). I
suppose this should work for all platforms, but I checked it on macos
only. Your patch is limited to APPLE and also works for me; If this
problem doesn't occur for other platforms, it's ok for me of course.


Probably no one else is using the bundle option (-DLYX_BUNDLE=ON).

If you could try to use cmake without this option, I'd be interested if it 
works for you
too.


Apparently no problem. -DLYX_BUNDLE=OFF works too for me.


In this case we could get rid of it (probably).

Kornel





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

Re: cmake build with qt6 (macos) does not include "plugins"

[pdv]

On 20/03/2023 10:50, Kornel Benko wrote:

Am Sun, 19 Mar 2023 20:45:55 +0100
schrieb pdv :


The merge branch killqt4 (commit 9376... on nov 28) broke the cmake
install build on macos.

The "development/cmake/post_install/CMakeLists.txt' SCRIPT checks for
qt5 and copies all plugins if different. This did work for qt4 but also
for qt6.

The killqt4 branch removed this else part for qt4 but also for qt6.

The included patch restores this else clause and only the comment has
been adapted (qt6 instead of qt4).

Since I don't know which plugins are actually needed I copied them all.

Regards,

P. De Visschere


But your patch is inside of
if(LYX_BUNDLE)
if(Qt5Core_FOUND
and outside of
 if(APPLE)

so I wonder, why is it working for QT6?

Maybe the attached is what you want?

Kornel


It's within the first if() else(), that's thus for qt6(see below). I 
suppose this should work for all platforms, but I checked it on macos 
only. Your patch is limited to APPLE and also works for me; If this 
problem doesn't occur for other platforms, it's ok for me of course.




if(Qt5Core_FOUND)
file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/imageformats")
install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime REGEX "\\_debug\\.dylib$" 
EXCLUDE)
   if(APPLE)
if(Qt5Core_VERSION VERSION_GREATER_EQUAL 5.10.0)
install_qt_plugin("Qt5::QMacStylePlugin")
endif()
install_qt_plugin("Qt5::QCocoaIntegrationPlugin")
   endif()
else()
# With QT6, just copy all the plugins
file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/*")
install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime)
endif()



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

cmake build with qt6 (macos) does not include "plugins"

[pdv]

The merge branch killqt4 (commit 9376... on nov 28) broke the cmake 
install build on macos.


The "development/cmake/post_install/CMakeLists.txt' SCRIPT checks for 
qt5 and copies all plugins if different. This did work for qt4 but also 
for qt6.


The killqt4 branch removed this else part for qt4 but also for qt6.

The included patch restores this else clause and only the comment has 
been adapted (qt6 instead of qt4).


Since I don't know which plugins are actually needed I copied them all.

Regards,

P. De Visscherediff --git a/development/cmake/post_install/CMakeLists.txt 
b/development/cmake/post_install/CMakeLists.txt
index 52a2f782af..dbd210d412 100644
--- a/development/cmake/post_install/CMakeLists.txt
+++ b/development/cmake/post_install/CMakeLists.txt
@@ -36,6 +36,10 @@ if(LYX_BUNDLE)
endif()
 install_qt_plugin("Qt5::QCocoaIntegrationPlugin")
endif()
+else()
+# With QT6, just copy all the plugins
+file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/*")
+install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime)
 endif()
 
 # Install code does the following:
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Error when compiling LyX under macOS

[pdv]

On 12/10/2021 21:36, Enrico Forestieri wrote:

On Tue, Oct 12, 2021 at 01:15:52PM +0200, Christoph Schmitz wrote:


macOS Monterey Version 12.0 Beta (21A5543b) and Qt 6.2.0

The problem, which first appeared about two weeks ago, still exists. I compile 
LyX once a day to see if it is fixed, but it is not. I still can't compile LyX 
under macOS anymore. I have the same issue on two computers (one with Intel 
processor, the other with M1 processor).

The compiler does not find QSvgWidget, although the class is not deprecated in Qt6: 
https://doc.qt.io/qt-6/qsvgwidget.html 
. I have reinstalled Qt and pulled a 
new LyX repository several times, but that does not solve the problem.

The file qsvgwidget.h is present. It can be found on the Intel Mac in the 
directory 
/usr/local/Cellar/qt/6.2.0/lib/QtSvgWidgets.framework/Versions/A/Headers. But 
even setting a path to this directory does not solve the problem. Does anybody 
understand what has happened?

Since attachments are deleted, I copy the last lines of the output below.

--
/Applications/Xcode-beta.app/Contents/Developer/usr/bin/make  all-recursive
Making all in support
/Applications/Xcode-beta.app/Contents/Developer/usr/bin/make  all-am
make[5]: Nothing to be done for `all-am'.
Making all in frontends
Making all in qt
/Applications/Xcode-beta.app/Contents/Developer/usr/bin/make  all-am
   CXX  Dialog.o
In file included from Dialog.cpp:15:
./GuiView.h:24:10: fatal error: 'QSvgWidget' file not found
#include 
  ^~~~
1 error generated.
make[6]: *** [Dialog.o] Error 1
make[5]: *** [all] Error 2
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


Please, try again after 47f1fec9



A similar modification is needed when building with CMake on MacOS.

I've included module SvgWidgets with qt6 and MacExtras with previous 
versions (I have checked builds on MacOS with qt6 and qt5, but not with 
qt4). (patch included)
I have also not touched the windows code which will probably show the 
same problem.


Patrickdiff --git a/src/frontends/qt/CMakeLists.txt b/src/frontends/qt/CMakeLists.txt
index 282db37ff7..cd07f84f27 100644
--- a/src/frontends/qt/CMakeLists.txt
+++ b/src/frontends/qt/CMakeLists.txt
@@ -43,8 +43,12 @@ else()
 endif()
 set_target_properties(frontend_qt PROPERTIES FOLDER "applications/LyX" 
QT_NO_UNICODE_DEFINES TRUE)
 
-if(Qt5Core_FOUND AND APPLE)
-   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg MacExtras)
+if(${QtVal}Core_FOUND AND APPLE)
+   if(Qt6Core_FOUND)
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg 
SvgWidgets)
+   else()
+   qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg 
MacExtras)
+   endif()
 else()
if (Qt5WinExtras_FOUND)
qt_use_modules(frontend_qt Core Gui Widgets Concurrent Svg 
WinExtras)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Check for the -Wno-deprecacted-copy compiler option in cmake build

[pdv]

On 03/04/2021 19:50, Kornel Benko wrote:

Am Sat, 3 Apr 2021 18:13:17 +0200
schrieb pdv :


The Apple Clang compiler does not recognize the -Wno-deprecated-copy
compiler option. See thread "Re: warning: unknown warning option
'-Wno-deprecated-copy'" (8/10/2020) in this list.

This was solved for the autotools build with commit 4aee447af1 (13/10/2020).

I've implemented a similar check for the cmake build.

As is stands the patch unsets the test-variable from the cache and the
test is performed for each cmake-run.
I don't know what's the preferred policy and one should remove that line
to use the cached result instead.

P. De Visschere


Why was
+   unset(CHECK_WNODEPRECATEDCOPY_FLAG CACHE)
necessary?

Kornel



I inserted it just to be able to check that it worked; the test is logged:

Performing Test CHECK_WNODEPRECATEDCOPY_FLAG
Performing Test CHECK_WNODEPRECATEDCOPY_FLAG - Failed

Otherwise after running cmake once the check is never run again, until 
one throws away the cmakecache.txt, which I try to avoid.


I suppose that after time this check will be forgotten and if the issue 
is solved (by an upgrade of the Apple clang compiler) this will pass 
unnoticed.


Probably the check takes little time and I thought it might be safer to 
do it each time again.



P. De Visschere

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

Check for the -Wno-deprecacted-copy compiler option in cmake build

[pdv]

The Apple Clang compiler does not recognize the -Wno-deprecated-copy 
compiler option. See thread "Re: warning: unknown warning option 
'-Wno-deprecated-copy'" (8/10/2020) in this list.


This was solved for the autotools build with commit 4aee447af1 (13/10/2020).

I've implemented a similar check for the cmake build.

As is stands the patch unsets the test-variable from the cache and the 
test is performed for each cmake-run.
I don't know what's the preferred policy and one should remove that line 
to use the cached result instead.


P. De Visschere
diff --git a/CMakeLists.txt b/CMakeLists.txt
index e4ed8cfc11..c3eed1a52d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -699,7 +699,14 @@ else()
# The following setting with LYX_GCC11_MODE is needed because cmake 
does not honor
# CMAKE_CXX_STANDARD while performing tests like
# check_cxx_source_compiles("..." HAVE_DEF_MAKE_UNIQUE)
-   set(LYX_CXX_FLAGS "-Wall -Wextra -Wno-deprecated-copy 
${LYX_GCC11_MODE}${LYX_CXX_FLAGS}")
+   include(CheckCXXCompilerFlag)
+   unset(CHECK_WNODEPRECATEDCOPY_FLAG CACHE)
+   CHECK_CXX_COMPILER_FLAG("-Wno-deprecated-copy" 
CHECK_WNODEPRECATEDCOPY_FLAG)
+   if(${CHECK_WNODEPRECATEDCOPY_FLAG})
+   set(LYX_CXX_FLAGS "-Wall -Wextra -Wno-deprecated-copy 
${LYX_GCC11_MODE}${LYX_CXX_FLAGS}")
+   else()
+   set(LYX_CXX_FLAGS "-Wall -Wextra 
${LYX_GCC11_MODE}${LYX_CXX_FLAGS}")
+   endif()
if(LYX_STDLIB_DEBUG)
  set(LYX_CXX_FLAGS "${LYX_CXX_FLAGS} -D_GLIBCXX_DEBUG 
-D_GLIBCXX_DEBUG_PEDANTIC")
 else()
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Error when compiling with Qt6 on macOS

[pdv]

On 25/03/2021 17:31, Kornel Benko wrote:

Am Thu, 25 Mar 2021 14:50:20 +0100
schrieb Christoph Schmitz :


One library is obviously not installed by Homebrew: Qt6MacExtrasConfig. I 
searched for
the two files manually, but without success.

-- CMake error message:

TOP_SRC_DIR = /Users/chris/Git/LyX

Building out-of-source
Selecting build type defaults from configure.ac

CXX11_FLAG_DETECTED = "--std=c++17 -Wno-deprecated-register"
Compiler supports std_regex
Using clang
CMake Error at CMakeLists.txt:793 (find_package):
Could not find a package configuration file provided by "Qt6MacExtras" with
any of the following names:

Qt6MacExtrasConfig.cmake
qt6macextras-config.cmake

Add the installation prefix of "Qt6MacExtras" to CMAKE_PREFIX_PATH or set
"Qt6MacExtras_DIR" to a directory containing one of the above files. If
"Qt6MacExtras" provides a separate development package or SDK, be sure it
has been installed.


OK, I will ignore Qt6MacExtras for Qt6. (commit 9b03680a)


Configuring incomplete, errors occurred!
See also "/Users/chris/Git/LyX/build/CMakeFiles/CMakeOutput.log".
See also "/Users/chris/Git/LyX/build/CMakeFiles/CMakeError.log".

Chris



Kornel




I also must exclude the QMacPasteboardMimeGraphics class in 
GuiApplication.cpp since QMacPasteboard is not available anymore with qt6.


and add an #include  in support/Package.cpp (I suppose 
this will pose no problem for qt5 but have not checked it, it's only 
needed with USE_MACOSX_PACKAGING)


(patch included)

P. De Visschere
diff --git a/src/frontends/qt/GuiApplication.cpp 
b/src/frontends/qt/GuiApplication.cpp
index e6964edfb2..aaff335266 100644
--- a/src/frontends/qt/GuiApplication.cpp
+++ b/src/frontends/qt/GuiApplication.cpp
@@ -153,7 +153,7 @@
 #endif
 #endif
 
-#ifdef Q_OS_MAC
+#if defined(Q_OS_MAC) && (QT_VERSION < 0x06)
 #include 
 #endif // Q_OS_MAC
 
@@ -752,7 +752,7 @@ public:
 //
 
 
-#ifdef Q_OS_MAC
+#if defined(Q_OS_MAC) && (QT_VERSION < 0x06)
 // QMacPasteboardMimeGraphics can only be compiled on Mac.
 
 class QMacPasteboardMimeGraphics : public QMacPasteboardMime
@@ -1048,7 +1048,7 @@ struct GuiApplication::Private
Qt::ApplicationState last_state_;
 #endif
 
-#ifdef Q_OS_MAC
+#if defined(Q_OS_MAC) && (QT_VERSION < 0x06)
/// Linkback mime handler for MacOSX.
QMacPasteboardMimeGraphics mac_pasteboard_mime_;
 #endif
diff --git a/src/support/Package.cpp b/src/support/Package.cpp
index a349a5e755..a779544f99 100644
--- a/src/support/Package.cpp
+++ b/src/support/Package.cpp
@@ -43,6 +43,7 @@
 # include "support/qstring_helpers.h"
 # include 
 # include 
+# include 
 #endif
 
 using namespace std;
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: Error when compiling with Qt6 on macOS

[pdv]

On 25/03/2021 15:05, pdv wrote:

On 25/03/2021 11:27, Christoph Schmitz wrote:
I have tried to compile LyX with Qt6 on macOS. The compiler stops 
quickly after a series of error messages. I attach a complete log file 
of my configure and make run.


Compiling LyX with Qt5 works with charm (thanks to the help of Marcus 
Mikulcak).


Chris




I have build successfully with the latest LyX and with Qt6 and cmake. 
There are a few issues to take into account:


1) there is an incompatibility between the moc_ files generated with qt5 
and qt6; you must remove these files manually if you switch; a "Clean" 
within XCode is not enough.


2) qtmacextras is not included in qt6 (it's not clear whether it ever 
will). You must remove 2 steps in the cmake files and the 
QMacPasteboardMimeGraphics code in GuiApplication.cpp.


3) I had to add one #include  in support/Package.cpp.

I believe the qtmacextras is needed for copy/paste (and dragging) .pdf 
content.


P. De Visschere



I found this in the qt-wiki:


Qt Mac Extras

Not included in Qt 6.0. Will find new home in the more relevant modules 
over time, and the remaining APIs considered included in later 6.x releases.



So, some time qt6macextras should be back.

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

Re: Error when compiling with Qt6 on macOS

[pdv]

On 25/03/2021 11:27, Christoph Schmitz wrote:

I have tried to compile LyX with Qt6 on macOS. The compiler stops quickly after 
a series of error messages. I attach a complete log file of my configure and 
make run.

Compiling LyX with Qt5 works with charm (thanks to the help of Marcus Mikulcak).

Chris




I have build successfully with the latest LyX and with Qt6 and cmake. 
There are a few issues to take into account:


1) there is an incompatibility between the moc_ files generated with qt5 
and qt6; you must remove these files manually if you switch; a "Clean" 
within XCode is not enough.


2) qtmacextras is not included in qt6 (it's not clear whether it ever 
will). You must remove 2 steps in the cmake files and the 
QMacPasteboardMimeGraphics code in GuiApplication.cpp.


3) I had to add one #include  in support/Package.cpp.

I believe the qtmacextras is needed for copy/paste (and dragging) .pdf 
content.


P. De Visschere

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

Re: macos-xcode-cmake build fails with --std=c++17 SOLVED

[pdv]

On 13/11/2020 17:14, Kornel Benko wrote:

Am Fri, 13 Nov 2020 17:04:18 +0100
schrieb Kornel Benko :


Am Fri, 13 Nov 2020 15:27:36 +0100
schrieb pdv :


I suppose HAVE_DEF_MAKE_UNIQUE should have been set to one but it wasn't.
Removing HAVE_DEF_MAKE_UNIQUE from cmake's cache didn't help.
The check_cxx_source_compiles() in ConfigureChecks.cmake was never
executed and HAVE_DEF_MAKE_UNIQUE was never set.

In the end I started from scratch and then the check ran and
HAVE_DEF_MAKE_UNIQUE=1.

P. De Visschere


You should remove CMakeCache.txt, so that cmake is forced to recheck everything.

It can also be that while checking, some other header files are used than at 
compile
time. Possible are also different compiler settings.

Kornel


I had a similar problem with some left-over header files in the _build_ 
directory.
So starting from scratch has to mean 'with empty build dir'.

Kornel




Yes, that's what I did: out-of-source build in an empty dir.

But I found out that this was not really needed: when emptying 
cmakecache.txt as much as possible (removing all 'internal cache 
entries' and 'external cache entries' generated by cmake) the problem is 
also solved.

In this way I could have saved my manual settings.

P. De Visschere
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: macos-xcode-cmake build fails with --std=c++17 SOLVED

[pdv]

I suppose HAVE_DEF_MAKE_UNIQUE should have been set to one but it wasn't.
Removing HAVE_DEF_MAKE_UNIQUE from cmake's cache didn't help.
The check_cxx_source_compiles() in ConfigureChecks.cmake was never 
executed and HAVE_DEF_MAKE_UNIQUE was never set.


In the end I started from scratch and then the check ran and 
HAVE_DEF_MAKE_UNIQUE=1.


P. De Visschere
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

macos-xcode-cmake build fails with --std=c++17

[pdv]

Since commit 2ec243 (28/10) cmake builds defaults apparently to --std=c++17.

Building with Xcode (11.3) on macos (10.14.6) then fails with message 
"call to 'make_unique' is ambiguous"


make_unique() is in lyx/.../support/unique_ptr.h and in Xcode.app/.../memory

This is the full error message:

 .../lyx-22-qt5/src/graphics/GraphicsCacheItem.cpp:445:15: error: call 
to 'make_unique' is ambiguous

 converter_ = make_unique(doc_file_, filename,
  ^~
 In file included from 
.../lyx-22-qt5/src/graphics/GraphicsCacheItem.cpp:15:

 In file included from .../lyx-22-qt5/src/graphics/GraphicsCacheItem.h:31:
 In file included from .../lyx-22-qt5/src/graphics/GraphicsTypes.h:18:
 In file included from .../lyx-22-qt5/src/support/strfwd.h:42:
 In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string:505:
 In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/string_view:176:
 In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__string:57:
 In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:644:


/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:3130:1: 
note: candidate function [with _Tp = lyx::graphics::Converter, _Args = 
std::__1::basic_string, std::__1::basic_string &, 
std::__1::basic_string &>]

 make_unique(_Args&&... __args)
 ^
 In file included from 
.../lyx-22-qt5/src/graphics/GraphicsCacheItem.cpp:17:

 In file included from .../lyx-22-qt5/src/Buffer.h:17:
 .../lyx-22-qt5/src/support/unique_ptr.h:55:1: note: candidate function 
[with T = lyx::graphics::Converter, Args = &, lyx::support::FileName &, std::__1::basic_string, 
std::__1::basic_string &, std::__1::basic_string &>]

 make_unique(Args&&... args) {
 ^
 1 error generated.

Regards,

P. De Visschere

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

Re: CMake install (of LyX) on MacOS

[pdv]

On 30/11/2019 11:03, Kornel Benko wrote:

Am Fri, 29 Nov 2019 19:46:13 +0100
schrieb pdv :


I wonder if someone uses CMake on MacOS to make a LyX application
bundle.


Don't know. At the moment you are the only one who cares.


One has at least to switch `LYX_INSTALL` ON but it did not work
right away for me. Basically all icons were missing.
With some changes I could get it to work (patch included). One will also
have to define the locations of the Qt5-plugins and Qt5-libs folders
(`QT5_PLUGINS_DIR` and `QT5_LIBRARY_DIRS`).


I had the impression that we want to discard the use of 'LYX_BUNDLE=ON'.
Is that needed for XCode?


I have it switched on.




Maybe not all plugins/imageformats are used/needed by lyx, but they are
all copied now, except for `_debug` versions which are excluded.
Starting with Qt-5.12 it seems not possible anymore (or at least not
easy) to link to the `_debug` versions of the qt5-frameworks (with
cmake). And installing them into the bundle also does not work. So right
now this is not a big loss.

Patrick


Is the patch safe for Qt-versions < 5.12?


I think so; It may also work with 5.9.



Kornel





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

CMake install (of LyX) on MacOS

[pdv]

I wonder if someone uses CMake on MacOS to make a LyX application 
bundle. One has at least to switch `LYX_INSTALL` ON but it did not work 
right away for me. Basically all icons were missing.


With some changes I could get it to work (patch included). One will also 
have to define the locations of the Qt5-plugins and Qt5-libs folders 
(`QT5_PLUGINS_DIR` and `QT5_LIBRARY_DIRS`).


Maybe not all plugins/imageformats are used/needed by lyx, but they are 
all copied now, except for `_debug` versions which are excluded.
Starting with Qt-5.12 it seems not possible anymore (or at least not 
easy) to link to the `_debug` versions of the qt5-frameworks (with 
cmake). And installing them into the bundle also does not work. So right 
now this is not a big loss.


Patrick
diff --git a/development/cmake/post_install/CMakeLists.txt 
b/development/cmake/post_install/CMakeLists.txt
index 7e4cb64517..f0eea8452d 100644
--- a/development/cmake/post_install/CMakeLists.txt
+++ b/development/cmake/post_install/CMakeLists.txt
@@ -28,13 +28,15 @@ if(LYX_BUNDLE)
 endif()
 
 if(Qt5Core_FOUND)
-install_qt_plugin("Qt5::QJpegPlugin")
-install_qt_plugin("Qt5::QGifPlugin")
-install_qt_plugin("Qt5::QICOPlugin")
-if(APPLE)
-install_qt_plugin("Qt5::QCocoaIntegrationPlugin")
-endif()
-else()
+   file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/imageformats")
+   install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime REGEX "\\_debug\\.dylib$" 
EXCLUDE)
+   if(APPLE)
+   if(Qt5Core_VERSION VERSION_GREATER_EQUAL 5.10.0)
+   install_qt_plugin("Qt5::QMacStylePlugin")
+   endif()
+install_qt_plugin("Qt5::QCocoaIntegrationPlugin")
+   endif()
+   else()
 # With QT4, just copy all the plugins
 file(GLOB QT_PLUGIN_DIRECTORIES "${QT_PLUGINS_DIR}/*")
 install(DIRECTORY ${QT_PLUGIN_DIRECTORIES} DESTINATION 
"${qtplugin_dest_dir}/plugins/" COMPONENT Runtime)
@@ -45,7 +47,7 @@ if(LYX_BUNDLE)
 # - install the platform specific plugins (with Qt5)
 # - Fixup the bundle
 install(CODE "include(BundleUtilities)
-file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qt_conf_path}\" 
\"\")
+file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qt_conf_path}\" 
\"[Paths]\\rPlugins = PlugIns\\rTranslations = translations\")
 file(GLOB_RECURSE QTPLUGINS
 
\"\${CMAKE_INSTALL_PREFIX}/${qtplugin_dest_dir}/plugins/*/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
 message(STATUS \"QT plugins 
[\${CMAKE_INSTALL_PREFIX}/${qtplugin_dest_dir}/plugins/*/*${CMAKE_SHARED_LIBRARY_SUFFIX}]:
 \${QTPLUGINS}\")
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake FindPythonInterp deprecated

[pdv]

On 29/11/2019 15:22, Kornel Benko wrote:

Am Fri, 29 Nov 2019 14:39:23 +0100
schrieb pdv :


On 28/11/2019 13:36, Kornel Benko wrote:

Yes I see. At 2) one could drop the LYX_PYTHON_EXECUTABLE.
Are the LYX_ variables not supposed to be set by the developer/user?


Good point. LYX_ prefix is used only to distinguish with any other variables
used in e.g. underlying projects like 3rdparty ...
But one could see it differently.
   

Patrick


Kornel

   


My only concern is that there is no way then to select another python
version if there should be a problem with the latest installed one.
With macports one can install different versions and select an active
one. But cmake's FindPython3 seems not to honor that choice and returns
always the latest one installed.

I've tried to find out which version is actually used by LyX.
On MacOS LyX does not use the version found by CMake; At least not for
running the reconfigure script. This uses the python3 command which is
set by macports and which can be different from the one returned by
FindPython3.

Maybe there are other locations in lyx where another python is used?


Patrick



You will always have such problems. Create a package configured with python2.
Use this package on a different computer. The lyx-executable will use a python
found on this new computer.

The executables used on compile time (by make or cmake) may of course be
different from the executables used later by lyx.
FindPython3 is only responsive for python used at compile time.

Kornel



Seems obvious now. Thanks for clearing this up.

Patrick

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

Re: CMake FindPythonInterp deprecated

[pdv]

On 28/11/2019 13:36, Kornel Benko wrote:

Yes I see. At 2) one could drop the LYX_PYTHON_EXECUTABLE.
Are the LYX_ variables not supposed to be set by the developer/user?


Good point. LYX_ prefix is used only to distinguish with any other variables
used in e.g. underlying projects like 3rdparty ...
But one could see it differently.


Patrick


Kornel




My only concern is that there is no way then to select another python 
version if there should be a problem with the latest installed one.
With macports one can install different versions and select an active 
one. But cmake's FindPython3 seems not to honor that choice and returns 
always the latest one installed.


I've tried to find out which version is actually used by LyX.
On MacOS LyX does not use the version found by CMake; At least not for 
running the reconfigure script. This uses the python3 command which is 
set by macports and which can be different from the one returned by 
FindPython3.


Maybe there are other locations in lyx where another python is used?


Patrick

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

Re: Check for hunspell.hxx always fails

[pdv]

On 28/11/2019 14:22, Kornel Benko wrote:

Am Thu, 28 Nov 2019 13:38:26 +0100
schrieb pdv :


Right now the check for the presence of hunspell.hxx in
ConfigureChecks.cmake always fails for me (MacOS10.14, master build)
with the result `HAVE_HUNSPELL_CXXABI = FALSE`, although hunspell.hxx is
available. That's a minor issue since hunspell works anyway, but the
check seems useless now.


Where is it available? Here, on ubuntu, it is under 
/usr/include/hunspell/hunspell.hxx


I use the macports one /opt/local/include/hunspell
but it also works with the 3thparty one included with lyx.




To proceed the check should include a `LINK_LIBRARIES` entry in the
try_compile() step.


No, not needed, see below ...


Also the `hunspell` in the `#include
` instruction in the test file should be removed.
It should be included in the `HUNSPELL_INCLUDE_DIR` definition.


Good point.


With these changes `HAVE_HUNSPELL_CXXABI = TRUE` (supposed hunspell.hxx
is present).

I don't understand the
"-DCMAKE_CXX_LINK_EXECUTABLE='${CMAKE_COMMAND} echo not linking now...'"
entry which contained a typo anyway. It sounds like one wanted to avoid
the linking in which case the LINK_LIBRARIES is indeed not needed.



The try_compile() normally creates an executable (e.g. compile + link)
and we want to compile only here.


I thought so (and I suppose libhunspell is then also not needed by LyX, 
which I did not realize), but that doesn't work for me; without the 
LINK_LIBRARIES the build fails:


Undefined symbols for architecture x86_64:
  "Hunspell::stem(std::__1::basic_stringstd::__1::char_traits, std::__1::allocator > const&)", 
referenced from:

  _main in hunspelltest.o
  "Hunspell::Hunspell(char const*, char const*, char const*)", 
referenced from:

  _main in hunspelltest.o
  "Hunspell::~Hunspell()", referenced from:
  _main in hunspelltest.o
ld: symbol(s) not found for architecture x86_64

It has been reported that this trick does not work with XCode:
https://cmake.org/pipermail/cmake/2010-May/037132.html





Patrick


Kornel





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

Check for hunspell.hxx always fails

[pdv]

Right now the check for the presence of hunspell.hxx in 
ConfigureChecks.cmake always fails for me (MacOS10.14, master build) 
with the result `HAVE_HUNSPELL_CXXABI = FALSE`, although hunspell.hxx is 
available. That's a minor issue since hunspell works anyway, but the 
check seems useless now.


To proceed the check should include a `LINK_LIBRARIES` entry in the 
try_compile() step. Also the `hunspell` in the `#include 
` instruction in the test file should be removed. 
It should be included in the `HUNSPELL_INCLUDE_DIR` definition.


With these changes `HAVE_HUNSPELL_CXXABI = TRUE` (supposed hunspell.hxx 
is present).


I don't understand the
"-DCMAKE_CXX_LINK_EXECUTABLE='${CMAKE_COMMAND} echo not linking now...'"
entry which contained a typo anyway. It sounds like one wanted to avoid 
the linking in which case the LINK_LIBRARIES is indeed not needed.




Patrick
diff --git a/development/cmake/ConfigureChecks.cmake 
b/development/cmake/ConfigureChecks.cmake
index 4b126776ea..b78d8ef14e 100644
--- a/development/cmake/ConfigureChecks.cmake
+++ b/development/cmake/ConfigureChecks.cmake
@@ -77,7 +77,7 @@ if(HUNSPELL_FOUND)
   set(HunspellTestFile "${CMAKE_BINARY_DIR}/hunspelltest.cpp")
   file(WRITE "${HunspellTestFile}"
   "
-  #include 
+  #include 
 
   int main()
   {
@@ -93,7 +93,9 @@ if(HUNSPELL_FOUND)
 "${HunspellTestFile}"
 CMAKE_FLAGS
   "-DINCLUDE_DIRECTORIES:STRING=${HUNSPELL_INCLUDE_DIR}"
-  "-DCMAKE_CXX_LINK_EXECUTABLE='${CMAKE_COMMAD} echo not linking now...'"
+  "-DCMAKE_CXX_LINK_EXECUTABLE='${CMAKE_COMMAND} echo not linking now...'"
+LINK_LIBRARIES
+  "${HUNSPELL_LIBRARY}"
   OUTPUT_VARIABLE  LOG2)
 
   message(STATUS "HAVE_HUNSPELL_CXXABI = ${HAVE_HUNSPELL_CXXABI}")
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: CMake FindPythonInterp deprecated

[pdv]

On 28/11/2019 10:43, Kornel Benko wrote:

Am Wed, 27 Nov 2019 22:25:16 +0100
schrieb pdv :


BTW, I never saw any deprecated message ... only looking into 
FindPythonInterp.cmake
there is a hint.

Kornel

   

I thought that a user might want to define LYX_PYTHON_EXECUTABLE and
this will now be overwritten.


It was intended. Imagine following scenario:
1.) A user has installed python2 and uses cmake to compile lyx
2.) Any time later after installing python3, cmake would still use python2

Kornel



Yes I see. At 2) one could drop the LYX_PYTHON_EXECUTABLE.
Are the LYX_ variables not supposed to be set by the developer/user?

Patrick

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

Re: CMake FindPythonInterp deprecated

[pdv]

On 27/11/2019 19:54, Kornel Benko wrote:

Am Wed, 27 Nov 2019 18:09:44 +0100
schrieb pdv :


find_package(PythonInterp ...) is deprecated since CMake 3.12.

With the current master build on MacOS CMake returns
`Python3_EXECUTABLE=Python3.5` although Python3.7 is selected with macports.

Using the recommended find_package(Python3 ...) CMake returns
`Python3_EXECUTABLE=Python3.7`. (patch included)

Patrick


No need to query for LYX_PYTHON_EXECUTABLE  before calling the find_package().
Therefore the patch could be as in the attached.

BTW, I never saw any deprecated message ... only looking into 
FindPythonInterp.cmake
there is a hint.

Kornel


I thought that a user might want to define LYX_PYTHON_EXECUTABLE and 
this will now be overwritten.


It's indeed just a hint in the docs: 
https://cmake.org/cmake/help/v3.15/module/FindPythonInterp.html?highlight=findpythoninterp


Patrick

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

CMake FindPythonInterp deprecated

[pdv]

find_package(PythonInterp ...) is deprecated since CMake 3.12.

With the current master build on MacOS CMake returns 
`Python3_EXECUTABLE=Python3.5` although Python3.7 is selected with macports.


Using the recommended find_package(Python3 ...) CMake returns 
`Python3_EXECUTABLE=Python3.7`. (patch included)


Patrick
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 779d9e932d..5b8b215bb2 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -786,22 +786,26 @@ if(GNUWIN32_DIR)
list(APPEND CMAKE_PROGRAM_PATH "${GNUWIN32_DIR}/Python" )
 endif()
 
-# Search for python default version first
-unset(PYTHON_EXECUTABLE CACHE)
-unset(LYX_PYTHON_EXECUTABLE CACHE)
-unset(PYTHON_VERSION_MAJOR)
-unset(PYTHON_VERSION_MINOR)
-unset(PYTHON_VERSION_STRING)
-find_package(PythonInterp 3.5 QUIET)
-if(NOT PYTHONINTERP_FOUND)
-  unset(PYTHON_EXECUTABLE CACHE)
-  find_package(PythonInterp 2.0 REQUIRED)
-  if(NOT PYTHON_VERSION_STRING VERSION_LESS 2.8)
-message(FATAL_ERROR "Python interpreter found, but is not suitable")
-  endif()
-endif()
+# Search for python default version if not yet defined
+if(NOT DEFINED LYX_PYTHON_EXECUTABLE)
+   unset(PYTHON_EXECUTABLE CACHE)
+   unset(LYX_PYTHON_EXECUTABLE CACHE)
+   unset(PYTHON_VERSION_MAJOR)
+   unset(PYTHON_VERSION_MINOR)
+   unset(PYTHON_VERSION_STRING)
+   find_package(Python3 3.5 QUIET)
+   if(NOT Python3_Interpreter_FOUND)
+ unset(PYTHON_EXECUTABLE CACHE)
+ find_package(Python2 2.0 QUIET)
+ if(NOT PYTHON_VERSION_STRING VERSION_LESS 2.8)
+   message(FATAL_ERROR "Python interpreter found, but is not suitable")
+ else()
+  set(LYX_PYTHON_EXECUTABLE ${Python2_EXECUTABLE} CACHE FILEPATH 
"Python to be used by LyX")
+ endif()
+   endif()
 
-set(LYX_PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE} CACHE FILEPATH "Python to be 
used by LyX")
+   set(LYX_PYTHON_EXECUTABLE ${Python3_EXECUTABLE} CACHE FILEPATH "Python 
to be used by LyX")
+endif()
 
 if(LYX_NLS)
find_package(LyXGettext)
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: lyxeditor not executable when installed with cmake

[pdv]

On 26/11/2019 21:04, Kornel Benko wrote:

Am Tue, 26 Nov 2019 20:57:22 +0100
schrieb Kornel Benko :


Am Tue, 26 Nov 2019 19:52:15 +0100
schrieb pdv :


When installing with the latest CMake on MacOS the lyxeditor, inkscape
and maxima files, copied into the bundle, are not longer executable.
This is in particular a nuisance for the "reverse search" feature which
calls lyxeditor.

In the "install(FILES ...)" command (in development/cmake/install.cmake)
the PERMISSIONS should be mentioned explicitly. See enclosed patch.

Patrick


Looks good. Will do it for master. Candidate for branch.

Kornel


Too fast. What about
install(PROGRAMS ...)
instead of 'install(FILES ...)?

Kornel



Agreed, that's shorter.

Patrick

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

lyxeditor not executable when installed with cmake

[pdv]

When installing with the latest CMake on MacOS the lyxeditor, inkscape 
and maxima files, copied into the bundle, are not longer executable. 
This is in particular a nuisance for the "reverse search" feature which 
calls lyxeditor.


In the "install(FILES ...)" command (in development/cmake/install.cmake) 
the PERMISSIONS should be mentioned explicitly. See enclosed patch.


Patrick
diff --git a/development/cmake/Install.cmake b/development/cmake/Install.cmake
index 08a6107aa6..434f1ac920 100755
--- a/development/cmake/Install.cmake
+++ b/development/cmake/Install.cmake
@@ -136,7 +136,7 @@ if(APPLE)
   endif()
 
   foreach(_i lyxeditor maxima inkscape)
-install(FILES "${TOP_SRC_DIR}/development/MacOSX/${_i}" DESTINATION 
"${LYX_UTILITIES_INSTALL_PATH}")
+install(FILES "${TOP_SRC_DIR}/development/MacOSX/${_i}" DESTINATION 
"${LYX_UTILITIES_INSTALL_PATH}" PERMISSIONS OWNER_EXECUTE OWNER_READ 
OWNER_WRITE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE)
   endforeach()
   install(FILES "${TOP_SRC_DIR}/development/MacOSX/LyX.icns" DESTINATION 
"${LYX_DATA_SUBDIR}")
   set(program_suffix ${PROGRAM_SUFFIX})
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: LyX crashes when handling selected databases in the BibTeX Bibliography dialog.

[pdv]

On 19/11/2019 13:49, Jürgen Spitzmüller wrote:

Am Montag, den 18.11.2019, 10:10 +0100 schrieb pdv:

It works without and when I put it back in, I got immediately a
crash.


Tested and committed.

Thanks!

Jürgen




Jürgen

I just found out another issue.

In the dialog for adding a citation, when selecting an item in the list 
on the left, the detail-view is not updated. It's only updated when 
selecting an item in the list on the right.


Can you confirm that?

To be on the safe side I've inserted the 2 selectionChanged() calls 
again but it's not related to that.


Patrick

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

Re: LyX crashes when handling selected databases in the BibTeX Bibliography dialog.

[pdv]

On 18/11/2019 09:55, Jürgen Spitzmüller wrote:

Am Sonntag, den 17.11.2019, 19:50 +0100 schrieb pdv:

In addPB_clicked() the idx is only used in one place and it’s
definition
can be moved. In upPB_clicked() and downPB_clicked() I first made idx
of
type QPersistentModelIndex and this avoids the crashes but the
selection
is lost when moving an item up/down.

I then redefined idx before the 2nd use and removed the
selectionChanged() signals and this avoids the crashes and keeps the
selection intact (patch included).


Thanks. Are you sure the selectionChanged() signal does not need to be
emitted?

Jürgen



P. De Visschere



It works without and when I put it back in, I got immediately a crash.

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

LyX crashes when handling selected databases in the BibTeX Bibliography dialog.

[pdv]

On macos and with the LyX2.4 master:

In the BibTeX Bibliography dialog: when handling items in the selected 
databases list (moving items up/down or adding items) LyX crashes with 
an EXC_BAD_ACCESS.

(LyX2.3.1 does not show this problem.)

Possible solution:

In GuiSelectionManager.cpp the routines addPB_clicked(), upPB_clicked() 
and downPB_clicked() define a QModelIndex idx, then make changes to the 
model and use idx again. According to the qt5 documentation a 
QPersistentModelIndex should be used:


	 Note: Model indexes should be used immediately and then discarded. You 
should not rely on indexes to remain valid after calling model functions 
that change the structure of the model or delete items. If you need to 
keep a model index over time use a QPersistentModelIndex.


In addPB_clicked() the idx is only used in one place and it’s definition 
can be moved. In upPB_clicked() and downPB_clicked() I first made idx of 
type QPersistentModelIndex and this avoids the crashes but the selection 
is lost when moving an item up/down.


I then redefined idx before the 2nd use and removed the 
selectionChanged() signals and this avoids the crashes and keeps the 
selection intact (patch included).


P. De Visschere
diff --git a/src/frontends/qt/GuiSelectionManager.cpp 
b/src/frontends/qt/GuiSelectionManager.cpp
index 4a735ed2d6..d77acbadc6 100644
--- a/src/frontends/qt/GuiSelectionManager.cpp
+++ b/src/frontends/qt/GuiSelectionManager.cpp
@@ -285,14 +285,14 @@ void GuiSelectionManager::addPB_clicked()
return;
 
QModelIndex const idxToAdd = selIdx.first();
-   QModelIndex const idx = selectedLV->currentIndex();
int const srows = selectedModel->rowCount();
 
QMap qm = availableModel->itemData(idxToAdd);
insertRowToSelected(srows, qm);
 
selectionChanged(); //signal
-
+   
+   QModelIndex const idx = selectedLV->currentIndex();
if (idx.isValid())
selectedLV->setCurrentIndex(idx);
 
@@ -344,8 +344,7 @@ void GuiSelectionManager::upPB_clicked()
selectedModel->removeRow(pos);
insertRowToSelected(pos - 1, qms);
 
-   selectionChanged(); //signal
-
+   idx = selIdx.first();
selectedLV->setCurrentIndex(idx.sibling(idx.row() - 1, idx.column()));
selectedHasFocus_ = true;
updateHook();
@@ -372,8 +371,7 @@ void GuiSelectionManager::downPB_clicked()
selectedModel->removeRow(pos);
insertRowToSelected(pos + 1, qms);
 
-   selectionChanged(); //signal
-
+   idx = selIdx.first();
selectedLV->setCurrentIndex(idx.sibling(idx.row() + 1, idx.column()));
selectedHasFocus_ = true;
updateHook();
-- 
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: linking error due to missing boost::assertion_failed_msg()

[pdv]

On 08/09/2019 20:47, pdv wrote:

On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De 
Visschere:
In the source files (ConverterCache.cpp, Application.cpp, 
FileName.cpp and GuiClipboard.cpp) I don’t see macro’s which could 
optionally include the relevant code which is probably in the 
boost::crc module. I suppose boost::crc uses boost::array where the 
BOOST_ASSERT_MSG macro is activated, triggering the error.


LyX includes a 3thparty boost-version (1.68), but I don’t find any 
references to it in my XCode project and I think I’m actually using 
my macports boost (which is 1.71).
This might explain it: I’ve upgraded my macports boost and this 
breaks my lyx-build.





There isn't any, if you don't use GCC. See CMakeLists.txt:162

Kornel



XCode uses clang and I believe that indeed the internal (3thparty) boost 
is used. But this contains only the regex (and signals) source code, 
besides (all) the headers. The code involved #includes  
and I suppose this code is found in the system (macports) boost.


Patrick



That was stupid. Boost is mostly header-only with the regex and signals 
modules being exceptions.


Patrick

Re: linking error due to missing boost::assertion_failed_msg()

[pdv]

On 09/09/2019 11:49, pdv wrote:

On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:

Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any 
references to it in my XCode project and I think I’m actually using 
my macports boost (which is 1.71).
This might explain it: I’ve upgraded my macports boost and this 
breaks my lyx-build.


I had started to update our boost to 1.70, but I gave up because of 
issues related to this and having other things to do with my time.


I will have to try again.

Patrick, you should be able to force LyX to use the included boost 
versions.


JMarc



No problem.

So far I have not found out how I can use macports aspell, magic , ... 
and not boost.


But all I have to do to get macports boost1.71 working is to define the 
missing assertion_failed_msg(). So, it's not really a problem for me.


Patrick



I've realized that in cmake I must specify the header files themselves 
for the external libs, that is

ASPELL_INCLUDE_DIR=/opt/local/include/aspell.h
etc and not just specify the include directory
ASPELL_INCLUDE_DIR=/opt/local/include

The cmake variable name ASPELL_INCLUDE_DIR is somewhat misleading. 
ASPELL_HEADER (like ICONV_HEADER) would be more appropriate.


This solves it.

Patrick

Re: linking error due to missing boost::assertion_failed_msg()

[pdv]

On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:

Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any 
references to it in my XCode project and I think I’m actually using my 
macports boost (which is 1.71).
This might explain it: I’ve upgraded my macports boost and this breaks 
my lyx-build.


I had started to update our boost to 1.70, but I gave up because of 
issues related to this and having other things to do with my time.


I will have to try again.

Patrick, you should be able to force LyX to use the included boost 
versions.


JMarc



No problem.

So far I have not found out how I can use macports aspell, magic , ... 
and not boost.


But all I have to do to get macports boost1.71 working is to define the 
missing assertion_failed_msg(). So, it's not really a problem for me.


Patrick

Re: linking error due to missing boost::assertion_failed_msg()

[pdv]

On 08/09/2019 17:47, Kornel Benko wrote:

Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:

In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and 
GuiClipboard.cpp) I don’t see macro’s which could optionally include the 
relevant code which is probably in the boost::crc module. I suppose boost::crc 
uses boost::array where the BOOST_ASSERT_MSG macro is activated, triggering the 
error.

LyX includes a 3thparty boost-version (1.68), but I don’t find any references 
to it in my XCode project and I think I’m actually using my macports boost 
(which is 1.71).
This might explain it: I’ve upgraded my macports boost and this breaks my 
lyx-build.




There isn't any, if you don't use GCC. See CMakeLists.txt:162

Kornel



XCode uses clang and I believe that indeed the internal (3thparty) boost 
is used. But this contains only the regex (and signals) source code, 
besides (all) the headers. The code involved #includes  
and I suppose this code is found in the system (macports) boost.


Patrick

linking error due to missing boost::assertion_failed_msg()

[pdv]

LyX fails to build on macos (Mojave, CMake, XCode) with the latest 
commit (01ee3bf1f5) with message:


Undefined symbols for architecture x86_64:
  "boost::assertion_failed_msg(char const*, char const*, char const*, 
char const*, long)", referenced from:
  boost::array::operator[](unsigned long) in 
ConverterCache.o
  boost::array::operator[](unsigned long) in 
libfrontend_qt.a(GuiApplication.o)
  boost::array::operator[](unsigned long) in 
libsupport.a(FileName.o)
  boost::array::operator[](unsigned long) in 
libfrontend_qt.a(GuiClipboard.o)


From the boost docs 
(https://www.boost.org/doc/libs/1_68_0/libs/assert/doc/html/assert.html) 
it's clear that boost::assertion_failed_msg() must be defined, ...


If the macro BOOST_ENABLE_ASSERT_HANDLER is defined when 
 is included, BOOST_ASSERT_MSG(expr,msg) expands to


(BOOST_LIKELY(!!(expr))? ((void)0): ::boost::assertion_failed_msg(#expr,
msg, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__))
This is true regardless of whether NDEBUG is defined.

boost::assertion_failed_msg is declared in  as

namespace boost
{
void assertion_failed_msg(char const * expr, char const * msg,
char const * function, char const * file, long line);
}
but it is never defined. The user is expected to supply an appropriate 
definition.


... which is not the case now, and BOOST_ASSERT_MSG is defined in 
boost::array.hpp.


I've defined the additional function assertion_failed_msg()in boost.cpp 
(patch attached) and this resolves the problem.


Two more remarks:

1) I don't understand why this problem surfaces now and not earlier;

2) There are additional definitions of assertion_failed() in 
client/boost.cpp and in tex2lyx/boost.cpp;


Patrick
diff --git a/src/boost.cpp b/src/boost.cpp
index 7ae7433a1b..fd24ef5832 100644
--- a/src/boost.cpp
+++ b/src/boost.cpp
@@ -46,5 +46,19 @@ void assertion_failed(char const * expr, char const * 
function,
// FIXME: do we have a list of exit codes defined somewhere?
lyx::lyx_exit(1);
 }
+   
+void assertion_failed_msg(char const * expr, char const * msg, char const * 
function,
+ char const * file, long line)
+{
+   lyxerr << "Assertion triggered in " << function
+   << " by failing check \"" << expr << "\""
+   << " in file " << file
+   << " with error message \"" << msg << "\":" << line << endl;
+   
+   // FIXME: by default we exit here but we could also inform the user
+   // about the assertion and do the emergency cleanup without exiting.
+   // FIXME: do we have a list of exit codes defined somewhere?
+   lyx::lyx_exit(1);
+}
 
 } // namespace boost

Re: Document Settings dialog partially broken on macos

[pdv]

I've updated my installation of Qt-5.11.2 to the latest available 
version and the problem has gone. Apparently this was a problem in Qt.

Sorry for bothering you about nothing.

P. De Visschere

On 04/10/2018 20:56, Patrick De Visschere wrote:

With “not highlighted” I meant that they are greyed out.
When e.g. I select “Vertical space” in “Text Layout” instead of the default 
“Indentation” the OK, Apply and Reset buttons remain greyed out.
Apparently the problem is that the screen is not updated immediately: when I 
subsequently resize the window (or switch to another app), then the display is 
shown properly.

Since you have no problem with Qt-5.9, I then checked with Qt-5.10.1 and there 
is no problem with that.

So, it seems a problem which occurs with Qt-5.11 only.



On 4 Oct 2018, at 19:17, Stephan Witt  wrote:

Am 04.10.2018 um 14:36 schrieb pdv :


Jean-Marc,

I noticed that the Document Settings dialog is partially broken in macos (build 
with Qt-5.11.2).

When making a change to the settings (with the default document class) the 
buttons (OK, apply, reset) are not highlighted. They seem still active though, 
so you can click on them.
When choosing another document class they become highlighted.

The problem is absent in commit azf... (8/7/2018) and present in commit b21... 
(10/7/2018) and I suppose it's related to the changes in QDialogButtonBox.


If I run current master (as of change 7cb0284a3f) on Mac build with Qt 5.9.4 I 
cannot see what you describe. With highlighted you mean enabled? The buttons 
get enabled on changing something to the settings.

Stephan

Document Settings dialog partially broken on macos

[pdv]

Jean-Marc,

I noticed that the Document Settings dialog is partially broken in macos 
(build with Qt-5.11.2).


When making a change to the settings (with the default document class) 
the buttons (OK, apply, reset) are not highlighted. They seem still 
active though, so you can click on them.

When choosing another document class they become highlighted.

The problem is absent in commit azf... (8/7/2018) and present in commit 
b21... (10/7/2018) and I suppose it's related to the changes in 
QDialogButtonBox.


Regards,

P. De Visschere

Deprecated calls in os_unix.cpp

[pdv]

Enclosed is a patch replacing two calls in os_unix.cpp which have been 
deprecated since MacOS 10.10.


Regards,
P. De Visschere
diff --git a/src/support/os_unix.cpp b/src/support/os_unix.cpp
index 34cfd478a6..c98fe12a26 100644
--- a/src/support/os_unix.cpp
+++ b/src/support/os_unix.cpp
@@ -228,18 +228,28 @@ bool canAutoOpenFile(string const & ext, auto_open_mode 
const mode)
CFStringRef cfs_ext = CFStringCreateWithBytes(kCFAllocatorDefault,
(UInt8 *) ext.c_str(), ext.length(),
kCFStringEncodingISOLatin1, false);
+   // Create UTI for the extension
+   CFStringRef cfs_uti = 
UTTypeCreatePreferredIdentifierForTag(kUTTagClassFilenameExtension, cfs_ext, 
NULL);
// this is what we would like to do but it seems that the
// viewer for PDF is often quicktime...
//LSRolesMask role = (mode == VIEW) ? kLSRolesViewer :  kLSRolesEditor;
(void)mode;
LSRolesMask role = kLSRolesAll;
-   FSRef outAppRef;
-   OSStatus status =
-   LSGetApplicationForInfo(kLSUnknownType, kLSUnknownCreator,
-   cfs_ext, role, , NULL);
+   // Deprecated call starting from 10.10
+   //FSRef outAppRef;
+   //OSStatus status =
+   //  LSGetApplicationForInfo(kLSUnknownType, kLSUnknownCreator,
+   //  cfs_ext, role, , NULL);
+   CFURLRef appRef = LSCopyDefaultApplicationURLForContentType(cfs_uti, 
role, NULL);
CFRelease(cfs_ext);
-
-   return status != kLSApplicationNotFoundErr;
+   CFRelease(cfs_uti);
+   if (!(appRef == NULL) ){
+   CFRelease(appRef);
+   return TRUE;
+   }
+   return FALSE;
+   //return status != kLSApplicationNotFoundErr;
+   
 #else
// silence compiler warnings
(void)ext;
@@ -265,9 +275,12 @@ bool autoOpenFile(string const & filename, auto_open_mode 
const mode,
 
CFURLRef docURL = CFURLCreateFromFileSystemRepresentation(
NULL, (UInt8 *) filename.c_str(), filename.size(), false);
-   CFURLRef appURL;
-   OSStatus status = LSGetApplicationForURL(docURL, role, NULL, );
-   if (status == kLSApplicationNotFoundErr)
+   CFErrorRef error;
+   CFURLRef appURL = LSCopyDefaultApplicationURLForURL(docURL, role, 
);
+   // Deprecated call starting from 10.10
+   //OSStatus status = LSGetApplicationForURL(docURL, role, NULL, );
+   //if (status == kLSApplicationNotFoundErr)
+   if ((appURL == NULL) && (CFErrorGetCode(error) == 
kLSApplicationNotFoundErr))
return false;
 
CFURLRef docURLs[] = { docURL };
@@ -296,7 +309,7 @@ bool autoOpenFile(string const & filename, auto_open_mode 
const mode,
setEnv("BSTINPUTS", newbstinputs);
setEnv("TEXFONTS", newtexfonts);
}
-   status = LSOpenFromURLSpec (, NULL);
+   OSStatus status = LSOpenFromURLSpec (, NULL);
CFRelease(launchItems);
if (!path.empty() && !lyxrc.texinputs_prefix.empty()) {
setEnv("TEXINPUTS", oldtexinputs);
@@ -304,6 +317,7 @@ bool autoOpenFile(string const & filename, auto_open_mode 
const mode,
setEnv("BSTINPUTS", oldbstinputs);
setEnv("TEXFONTS", oldtexfonts);
}
+   CFRelease(appURL);
return status == 0;
 #else
// silence compiler warnings

LinkBack support (on MacOS)

[pdv]

I came across a deprecated call in the LinkBack code, and discovered 
that LinkBack acctually doesn't work (anymore).

Apparently nobody uses this?

When the pasteboard contains linkback-data lyx saves the pdf-data + 
linkback-data in a file with the .linkback extension and adds the size 
of the pdf-data as a uint32.


When reading/rewriting back the size it's converted with 
NSSwapBigLongToHost() and NSSwapHostLongToBig() calls.


I suppose that the "Long" refers to 8 bytes.

Replacing the calls by the similar "Int" calls solves the problem.

LinkBack then works with LateXiT and with Omnigraffle.

Enclosed is a patch for this and for replacing the deprecated call.


Regards,

P. De Visschere
diff --git a/src/support/linkback/LinkBackProxy.m 
b/src/support/linkback/LinkBackProxy.m
index bf150c9ad6..574d5713cf 100644
--- a/src/support/linkback/LinkBackProxy.m
+++ b/src/support/linkback/LinkBackProxy.m
@@ -65,7 +65,7 @@
// The pdf data length are the last 4 bytes.
UInt32 pdfLen = 0;
pdfLen = *(UInt32 const *)(((UInt8 const *)[data bytes]) + 
[data length] - 4);
-   pdfLen = NSSwapBigLongToHost(pdfLen); // make it big endian
+   pdfLen = NSSwapBigIntToHost(pdfLen); // make it big endian
if (pdfLen >= [data length] - 4) {
NSLog(@"Invalid file %@ for LinkBack", fileName);
return NO;
@@ -154,7 +154,7 @@
[file writeData:pdfData];
[file writeData:linkBackData];
 
-   UInt32 pdfLen = NSSwapHostLongToBig([pdfData length]); // big 
endian
+   UInt32 pdfLen = NSSwapHostIntToBig([pdfData length]); // big 
endian
NSData * lenData = [NSData dataWithBytes: length:4];
[file writeData:lenData];
[file closeFile];
diff --git a/src/support/linkback/LinkBackServer.m 
b/src/support/linkback/LinkBackServer.m
index dc8708d66d..38a80e02e6 100644
--- a/src/support/linkback/LinkBackServer.m
+++ b/src/support/linkback/LinkBackServer.m
@@ -154,8 +154,7 @@ NSString* FindLinkBackServer(NSString* bundleIdentifier, 
NSString* serverName, N
 
 void LinkBackRunAppNotFoundPanel(NSString* appName, NSURL* url)
 {
-   int result ;
-
+   
// strings for panel
NSBundle* b = [NSBundle bundleForClass: [LinkBack class]] ;
NSString* title ;
@@ -171,11 +170,17 @@ void LinkBackRunAppNotFoundPanel(NSString* appName, 
NSURL* url)
urlstr = (url) ? NSLocalizedStringFromTableInBundle(@"_GetApplication", 
@"Localized", b, @"Get application") : nil ;
 
title = [NSString stringWithFormat: title, appName] ;
-
-   result = NSRunCriticalAlertPanel(title, @"%@", ok, urlstr, nil, msg) ;
-   if (NSAlertAlternateReturn == result) {
-   [[NSWorkspace sharedWorkspace] openURL: url] ;
-   }
+   
+   NSAlert* alert = [[NSAlert alloc] init];
+   [alert setAlertStyle:NSAlertStyleCritical];
+   [alert setMessageText:title];
+   [alert setInformativeText:[NSString stringWithFormat:@"%@", msg]];
+   [alert addButtonWithTitle:ok];
+   [alert addButtonWithTitle:urlstr];
+   [alert beginSheetModalForWindow:[NSApp mainWindow] 
completionHandler:^(NSModalResponse returnCode) {
+   if (returnCode == NSAlertSecondButtonReturn)
+   [[NSWorkspace sharedWorkspace] openURL: url] ;
+   }];
 }
 
 + (LinkBackServer*)LinkBackServerWithName:(NSString*)aName 
inApplication:(NSString*)bundleIdentifier launchIfNeeded:(BOOL)flag 
fallbackURL:(NSURL*)url appName:(NSString*)appName

Re: LyX-Workarea: Background not shown correctly

[pdv]

On 25/10/2017 16:15, Patrick De Visschere wrote:


I do not like much the idea of just restricting the update area, since it seems 
very fragile. But we can return to it if needed. There are ways to get all the 
coordinates that we need.


I agree. The dimensions passed via update(x,y,w,h) and the actual area painted 
must match exactly. I cannot judge the penalty of the screen redraws. I doesn’t 
seem to hurt very much.
Nevertheless I have now something which works mostly. There are still problems 
when dragging a selection but I believe these can be solved by fine tuning. The 
other problem is that when opening a document the screen stil turns black.



I'm afraid the latter problem cannot (easily) be solved.
When opening a document (I used a simple one with 3 lines with 1 
character each) viewport()->update() is executed 4x.


2x with update_flags_=ForceDraw and update_strategy=FullScreenUpdate
and 2x with update_strategy=SingleParUpdate

Both FullScreenUpdates are initiated by 
TabWorkArea::on_currentTabChanged(), the second one following a 
QEvent::FocusIn.


Although the second call is redundant this is probably not an oversight.

Unfortunately since the screen has already been drawn after the first 
update(), the tm::drawPargraph code does not redraw it the 2nd time, but 
the screen has been erased by qt again after the second update().


pdv

Re: LyX-Workarea: Background not shown correctly

[pdv]

On 17/09/2017 19:48, Stephan Witt wrote:

Hi JMarc,

another problem I’ve seen: after running view-pdflatex e.g.
the work area doesn’t show correct background color.

Stephan


The new code contains twice a viewport()->update() without specification 
of a rectangle. Since > Qt normally erases the widget's area before the 
paintEvent() call
I guess that the whole viewport is erased. Subsequently only part of it 
is redrawn except for the case FullScreenUpdate and in that case there 
is no problem.


P. De Visschere

Re: prefs2prefs.py not compatible with python3 [PATCH]

[pdv]

On 15/01/17 19:28, Stephan Witt wrote:

Am 15.01.2017 um 19:07 schrieb Stephan Witt <st.w...@gmx.net>:


Am 15.01.2017 um 17:10 schrieb Stephan Witt <st.w...@gmx.net>:


Am 15.01.2017 um 13:44 schrieb pdv <pdvissch...@edpnet.be>:


On 15/01/17 00:11, Stephan Witt wrote:

Am 15.01.2017 um 00:05 schrieb Stephan Witt <st.w...@gmx.net>:


Am 14.01.2017 um 17:42 schrieb pdv <pdvissch...@edpnet.be>:


The current master fails to start-up (on macOS) if the default Python is 
Python3.x, because prefs2prefs.py is not compatible with Python3.


This looks strange. The python people say python 2.7 is the default on Mac 
(including the latest OS Sierra).

http://docs.python-guide.org/en/latest/starting/install3/osx/

Stephan



In python23() in os.cpp both Python 2 and Python 3 are accepted.


As a temporarily workaround I've built with PYTHON="/usr/bin/python" which is 
the default apple-python, but that doesn't seem to help.

P. De Visschere


Sorry, I misunderstood - you are trying to force the use of the default 2.7 
python. I think you have to force the use of correct python at run-time. It 
doesn’t matter what your environment is at compile time. This is the correct 
behavior, IMO.

Stephan



I agree but what then is the use of PYTHON at configure time?


Python is used to run the tests. Probably the value of PYTHON is used to force 
a specific python installation if the detected one is not wanted.


And yes python2.7 is the default apple python, but if e.g. one has python 
installed with macports this one (might) take precedence. Before running LyX 
one now has to select a python2 version or none.
Since LyX seems to accept also python3 I thought that one was not aware that 
prefs2prefs.py is not yet compatible.


Yes, you’re right. I forgot that LyX should be able to use python3 now. Sorry.


I’m not a python expert. Nevertheless I tried to solve this issue. What about 
the attached patch?

Stephan




The follow-up patch I’ve attached now should work with python2 too.

Stephan


It does. Thanks.

Patrick

Re: prefs2prefs.py not compatible with python3

[pdv]

On 15/01/17 00:11, Stephan Witt wrote:

Am 15.01.2017 um 00:05 schrieb Stephan Witt <st.w...@gmx.net>:


Am 14.01.2017 um 17:42 schrieb pdv <pdvissch...@edpnet.be>:


The current master fails to start-up (on macOS) if the default Python is 
Python3.x, because prefs2prefs.py is not compatible with Python3.


This looks strange. The python people say python 2.7 is the default on Mac 
(including the latest OS Sierra).

http://docs.python-guide.org/en/latest/starting/install3/osx/

Stephan



In python23() in os.cpp both Python 2 and Python 3 are accepted.


As a temporarily workaround I've built with PYTHON="/usr/bin/python" which is 
the default apple-python, but that doesn't seem to help.

P. De Visschere


Sorry, I misunderstood - you are trying to force the use of the default 2.7 
python. I think you have to force the use of correct python at run-time. It 
doesn’t matter what your environment is at compile time. This is the correct 
behavior, IMO.

Stephan



I agree but what then is the use of PYTHON at configure time?

And yes python2.7 is the default apple python, but if e.g. one has 
python installed with macports this one (might) take precedence. Before 
running LyX one now has to select a python2 version or none.
Since LyX seems to accept also python3 I thought that one was not aware 
that prefs2prefs.py is not yet compatible.


P. De Visschere

prefs2prefs.py not compatible with python3

[pdv]

The current master fails to start-up (on macOS) if the default Python is 
Python3.x, because prefs2prefs.py is not compatible with Python3.


In python23() in os.cpp both Python 2 and Python 3 are accepted.


As a temporarily workaround I've built with PYTHON="/usr/bin/python" 
which is the default apple-python, but that doesn't seem to help.


P. De Visschere

LyX-menu problem on mac OS

[pdv]

Commit 4d99... on august 28 did break the LyX-menu on mac OS;

This is due to the loop counter not being incremented in the for-loop 
starting on line number 1957 in Menus.cpp.


Regards,

P. De Visschere

Bringing a hidden window to the front on a mac.

[pdv]

If one has 2 documents open in LyX 2.2 in 2 separate windows and one 
wants to bring the one in the back to the front via the menu 
View/Hidden/... then (on a mac, OSX 10.11.4) nothing happens. Although 
the window has been activated, it's not brought to the front. [When 
switching to e.g. the Finder and then back to LyX by clicking on the LyX 
icon in the Dock, the hidden window will now be shown in front.]


The problem is solved by adding a raise() call to the activateWindow() 
call in GuiView.cpp (see included patch).


Regards,

P. De Visschere
diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp
index c2101f3..89bff9a 100644
--- a/src/frontends/qt4/GuiView.cpp
+++ b/src/frontends/qt4/GuiView.cpp
@@ -3615,6 +3615,7 @@ void GuiView::dispatch(FuncRequest const & cmd, 
DispatchResult & dr)
for (; i != ids.size(); ++i) {
GuiView & gv = guiApp->view(ids[i]);
if (gv.workArea(*buffer)) {
+   gv.raise();
gv.activateWindow();
gv.setBuffer(buffer);
break;

Re: clang doesn't like -std=c++11 for Objective C files

[pdv]

On 02/02/16 09:05, Jean-Marc Lasgouttes wrote:

Le 01/02/2016 20:13, pdv a écrit :

On 01/02/16 15:49, Jean-Marc Lasgouttes wrote:

What version of Mac OS X is that? I had to add -std=c++11 to CPPFLAGS
because the clang preprocessor needs it to select the proper libc++
stuff. Without it some autoconf tests would fail.


This is with OS X 10.11, but I experienced the same problem before I
upgraded.


Please keep the discussion on the list, I am not the best OS X
specialist here...

JMarc


Sorry, I wasn't aware not replying to the list.
pdv

Re: clang doesn't like -std=c++11 for Objective C files

[pdv]

On 02/02/16 09:19, Stephan Witt wrote:

Am 01.02.2016 um 21:39 schrieb pdv <pdvissch...@edpnet.be>:


On 01/02/16 15:54, Stephan Witt wrote:

Am 01.02.2016 um 15:49 schrieb Jean-Marc Lasgouttes <lasgout...@lyx.org>:


Le 30/01/2016 09:55, pdv a écrit :

Hi,

Build under OS X fails with:

   CXX  userinfo.o
   CXX  unicode.o
   OBJC AppleSpeller.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'


What version of Mac OS X is that? I had to add -std=c++11 to CPPFLAGS because 
the clang preprocessor needs it to select the proper libc++ stuff. Without it 
some autoconf tests would fail.


I had the same question. With clang 7.0.2 from Xcode 7 I have no problem 
without the patch.

Stephan



I'm also using XCode 7 and clang 7.0.2;

When I first experienced this problem I went back to the last commit which did 
build successfully and then moved forward in time in the hope to find the 
commit which introduced the error;
I ended up with the then last available commit without problem.

I've never understood how this is possible, since the script does a clean 
build, no?


Which script are you talking about?

In case you’re referring to development/LyX-Mac-binary-release.sh you’re
right - it does a clean build.

Stephan




I was referring to that one.
And I call it this way:

ARCH=x86_64
QtVersion=5.5.1
QtAPI=-cocoa
LyXVersion=lyx-22-qt5-manual
CC=cc CXX=c++ \
QtAPI=${QtAPI} QtVersion=${QtVersion} \
sh .../LyX-Mac-binary-release.sh \
  --with-sdkroot=10.11 --with-macosx-target=10.10 --with-arch=${ARCH} \
  --with-qt-dir=.../Qt-${QtVersion}-frameworks \
  --qt-deployment=yes --enable-debug \
  "$@"

pdv

Re: clang doesn't like -std=c++11 for Objective C files

[pdv]

On 01/02/16 15:54, Stephan Witt wrote:

Am 01.02.2016 um 15:49 schrieb Jean-Marc Lasgouttes <lasgout...@lyx.org>:


Le 30/01/2016 09:55, pdv a écrit :

Hi,

Build under OS X fails with:

   CXX  userinfo.o
   CXX  unicode.o
   OBJC AppleSpeller.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'


What version of Mac OS X is that? I had to add -std=c++11 to CPPFLAGS because 
the clang preprocessor needs it to select the proper libc++ stuff. Without it 
some autoconf tests would fail.


I had the same question. With clang 7.0.2 from Xcode 7 I have no problem 
without the patch.

Stephan



I'm also using XCode 7 and clang 7.0.2;

When I first experienced this problem I went back to the last commit 
which did build successfully and then moved forward in time in the hope 
to find the commit which introduced the error;

I ended up with the then last available commit without problem.

I've never understood how this is possible, since the script does a 
clean build, no?


pdv




I moved the '-std=c++11' from the CPPFLAGS to the CXXFLAGS and defined
OBJCFLAGS.


Well, it is where it used to be before  commit 39717adf %-|

JMarc

clang doesn't like -std=c++11 for Objective C files

[pdv]

Hi,

Build under OS X fails with:

  CXX  userinfo.o
  CXX  unicode.o
  OBJC AppleSpeller.o
error: invalid argument '-std=c++11' not allowed with 'C/ObjC'

I moved the '-std=c++11' from the CPPFLAGS to the CXXFLAGS and defined 
OBJCFLAGS.


(patch included)

Regards,

Patrick De Visschere
diff --git a/config/lyxinclude.m4 b/config/lyxinclude.m4
index 81e91ca..5d7b666 100644
--- a/config/lyxinclude.m4
+++ b/config/lyxinclude.m4
@@ -366,8 +366,8 @@ if test x$GXX = xyes; then
   clang)
 dnl presumably all clang versions support c++11.
dnl the deprecated-register warning is very annoying with Qt4.x right 
now.
-AM_CPPFLAGS="$AM_CPPFLAGS -std=c++11"
-AM_CXXFLAGS="$AM_CXXFLAGS -Wno-deprecated-register";;
+AM_OBJCFLAGS="$AM_CXXFLAGS"
+AM_CXXFLAGS="$AM_CXXFLAGS -std=c++11 -Wno-deprecated-register";;
   *)
 AS_CASE([$host], [*cygwin*],
 [AM_CPPFLAGS="$AM_CPPFLAGS -std=gnu++11"],
diff --git a/configure.ac b/configure.ac
index 8ae7dcb..7b42065 100644
--- a/configure.ac
+++ b/configure.ac
@@ -241,6 +241,7 @@ VERSION_INFO="Configuration\n\
   Special build flags: ${lyx_flags}\n\
   C++ Compiler:${CXX} ${CXX_VERSION}\n\
   C++ Compiler flags:  ${AM_CPPFLAGS} ${AM_CXXFLAGS}\n\
+  Obj C Compiler flags:${AM_CPPFLAGS} ${AM_OBJCFLAGS}\n\
   C++ Compiler user flags: ${CPPFLAGS} ${CXXFLAGS}\n\
   Linker flags:${AM_LDFLAGS}\n\
   Linker user flags:   ${LDFLAGS}\n\

Exception (basic_string) when saving on OSX.

[pdv]

I've been experiencing several exceptions on OSX, using commit 96f64ac0.
Sofar I've tracked down one of them:

A (basic_string) exception occurs when saving a document with a 
sufficient long filename (more than about 18 characters without the 
extension). Take any .lyx file and add characters to the name. Then open 
and save it.
As far as I can see this has been introduced with commit bb34445, which 
contains many changes, including some of the filetools.


Regards,

P. De Visschere

Re: LyX2.2 build fails on OS X

[pdv]

On 20/09/15 17:10, Guillaume Munch wrote:

Le 20/09/2015 14:40, pdv a écrit :

Hi,

As of commit 9b7ccbf (the introduction of class InsetCaptionable)
building LyX2.2 fails on OS X (with XCode and with autotools).

This is the error message:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40:

Constructor for
'std::__1::__libcpp_compressed_pair_imp<std::__1::allocator, const lyx::Toc, 1>' must explicitly initialize the const
member '__second_'
.../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:14:10: In file included
from .../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:14:
.../lyx-22-qt5/src/frontends/qt4/TocModel.h:15:10: In file included from
.../lyx-22-qt5-cmake-xcode/src/frontends/qt4/../../../../lyx-22-qt5/src/frontends/qt4/TocModel.h:15:


.../lyx-22-qt5/src/support/shared_ptr.h:17:10: In file included from
.../lyx-22-qt5/src/support/shared_ptr.h:17:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2345:11:

In instantiation of member function
'std::__1::__libcpp_compressed_pair_imp<std::__1::allocator, const lyx::Toc, 1>::__libcpp_compressed_pair_imp' requested
here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3727:12:

In instantiation of member function
'std::__1::__compressed_pair<std::__1::allocator, const
lyx::Toc>::__compressed_pair' requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:4308:26:

In instantiation of member function
'std::__1::__shared_ptr_emplace >::__shared_ptr_emplace' requested
here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:4672:29:

In instantiation of function template specialization
'std::__1::shared_ptr::make_shared<>' requested here
.../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:84:28: In instantiation of
function template specialization 'std::__1::make_shared'
requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2063:9:

'__second_' declared here



Apparently there is a bug in c++/v1/memory as reported here
(http://lists.llvm.org/pipermail/llvm-bugs/2015-July/040892.html)

After patching c++/v1/memory the compile error goes away but the link
fails with undefined symbols.

Undefined symbols for architecture x86_64:
   "lyx::InsetCaptionable::updateBuffer(lyx::ParIterator const&,
lyx::UpdateType)", referenced from:
   vtable for lyx::InsetFloat in libinsets.a(InsetFloat.o)
   vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
   lyx::InsetWrap::updateBuffer(lyx::ParIterator const&,
lyx::UpdateType) in libinsets.a(InsetWrap.o)
   "lyx::InsetCaptionable::setCaptionType(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&)",
referenced from:
   lyx::InsetFloat::setCaptionType(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&) in
libinsets.a(InsetFloat.o)
   vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
   lyx::InsetWrap::setCaptionType(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&) in
libinsets.a(InsetWrap.o)
   "lyx::InsetCaptionable::insetAllowed(lyx::InsetCode) const",
referenced from:
   lyx::InsetFloat::insetAllowed(lyx::InsetCode) const in
libinsets.a(InsetFloat.o)
   lyx::InsetWrap::insetAllowed(lyx::InsetCode) const in
libinsets.a(InsetWrap.o)
   "lyx::InsetCaptionable::addToToc(lyx::DocIterator const&, bool)
const", referenced from:
   vtable for lyx::InsetFloat in libinsets.a(InsetFloat.o)
   vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
   vtable for lyx::InsetWrap in libinsets.a(InsetWrap.o)
   "lyx::InsetCaptionable::floatName(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&) const",
referenced from:
   lyx::InsetFloat::setCaptionType(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&) in
libinsets.a(InsetFloat.o)
   lyx::InsetFloat::setNewLabel() in libinsets.a(InsetFloat.o)
   lyx::InsetFloat::plaintext(std::__1::basic_ostringstream<wchar_t,
std::__1::char_traits, std::__1::allocator >&,
lyx::OutputParams const&, unsigned long) const in
libinsets.a(InsetFloat.o)
   lyx::InsetWrap::setCaptionType(std::__1::basic_string<char,
std::__1::char_traits, std::__1::allocator > const&) in
libinsets.a(InsetWrap.o)
   lyx::InsetWrap::plaintext(std::__1::basic_ostringstream<wchar_t,
std::__1::char_traits, std::__1::allocator >&,
lyx::OutputParams const&, unsigned long) const in
libinsets.a(InsetWrap.o)
   "typeinfo for lyx::InsetCaptionable", 

LyX2.2 build fails on OS X

[pdv]

Hi,

As of commit 9b7ccbf (the introduction of class InsetCaptionable) 
building LyX2.2 fails on OS X (with XCode and with autotools).


This is the error message:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2075:40: 
Constructor for 
'std::__1::__libcpp_compressed_pair_imp, const lyx::Toc, 1>' must explicitly initialize the const 
member '__second_'
.../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:14:10: In file included 
from .../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:14:
.../lyx-22-qt5/src/frontends/qt4/TocModel.h:15:10: In file included from 
.../lyx-22-qt5-cmake-xcode/src/frontends/qt4/../../../../lyx-22-qt5/src/frontends/qt4/TocModel.h:15:
.../lyx-22-qt5/src/support/shared_ptr.h:17:10: In file included from 
.../lyx-22-qt5/src/support/shared_ptr.h:17:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2345:11: 
In instantiation of member function 
'std::__1::__libcpp_compressed_pair_imp, const lyx::Toc, 1>::__libcpp_compressed_pair_imp' requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:3727:12: 
In instantiation of member function 
'std::__1::__compressed_pair::__compressed_pair' requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:4308:26: 
In instantiation of member function 
'std::__1::__shared_ptr_emplacestd::__1::allocator >::__shared_ptr_emplace' requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:4672:29: 
In instantiation of function template specialization 
'std::__1::shared_ptr::make_shared<>' requested here
.../lyx-22-qt5/src/frontends/qt4/TocModel.cpp:84:28: In instantiation of 
function template specialization 'std::__1::make_shared' 
requested here
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:2063:9: 
'__second_' declared here




Apparently there is a bug in c++/v1/memory as reported here 
(http://lists.llvm.org/pipermail/llvm-bugs/2015-July/040892.html)


After patching c++/v1/memory the compile error goes away but the link 
fails with undefined symbols.


Undefined symbols for architecture x86_64:
  "lyx::InsetCaptionable::updateBuffer(lyx::ParIterator const&, 
lyx::UpdateType)", referenced from:

  vtable for lyx::InsetFloat in libinsets.a(InsetFloat.o)
  vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
  lyx::InsetWrap::updateBuffer(lyx::ParIterator const&, 
lyx::UpdateType) in libinsets.a(InsetWrap.o)
  "lyx::InsetCaptionable::setCaptionType(std::__1::basic_string const&)", 
referenced from:
  lyx::InsetFloat::setCaptionType(std::__1::basic_string const&) in 
libinsets.a(InsetFloat.o)

  vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
  lyx::InsetWrap::setCaptionType(std::__1::basic_string const&) in 
libinsets.a(InsetWrap.o)
  "lyx::InsetCaptionable::insetAllowed(lyx::InsetCode) const", 
referenced from:
  lyx::InsetFloat::insetAllowed(lyx::InsetCode) const in 
libinsets.a(InsetFloat.o)
  lyx::InsetWrap::insetAllowed(lyx::InsetCode) const in 
libinsets.a(InsetWrap.o)
  "lyx::InsetCaptionable::addToToc(lyx::DocIterator const&, bool) 
const", referenced from:

  vtable for lyx::InsetFloat in libinsets.a(InsetFloat.o)
  vtable for lyx::InsetListings in libinsets.a(InsetListings.o)
  vtable for lyx::InsetWrap in libinsets.a(InsetWrap.o)
  "lyx::InsetCaptionable::floatName(std::__1::basic_string const&) const", 
referenced from:
  lyx::InsetFloat::setCaptionType(std::__1::basic_string const&) in 
libinsets.a(InsetFloat.o)

  lyx::InsetFloat::setNewLabel() in libinsets.a(InsetFloat.o)
  lyx::InsetFloat::plaintext(std::__1::basic_ostringstream&, 
lyx::OutputParams const&, unsigned long) const in libinsets.a(InsetFloat.o)
  lyx::InsetWrap::setCaptionType(std::__1::basic_string const&) in 
libinsets.a(InsetWrap.o)
  lyx::InsetWrap::plaintext(std::__1::basic_ostringstream&, 
lyx::OutputParams const&, unsigned long) const in libinsets.a(InsetWrap.o)

  "typeinfo for lyx::InsetCaptionable", referenced from:
  typeinfo for lyx::InsetFloat in libinsets.a(InsetFloat.o)
  typeinfo for lyx::InsetListings in libinsets.a(InsetListings.o)
  typeinfo for lyx::InsetWrap in libinsets.a(InsetWrap.o)
  

Re: Compilation failure un c++11 mode with gcc 4.6

[pdv]

On 19/05/15 11:25, Jean-Marc Lasgouttes wrote:

Hi Georg,

It is not possible currently to compile with gcc 4.6 in C++11 mode
because lyxalgo.h declares its own next() method. This is because the
code depends on __cplusplus = 201103L, which is not true for this
version of the compiler.

I would propose to replace this test with a test on whether c++11 mode
has been selected by configure. Then it would be our responsibility to
forbid if needed C++11 mode in too old compilers.

The alternative would be to actually check whether the compiler supports
std::next().

JMarc

   CXXCutAndPaste.o
../../master/src/CutAndPaste.cpp: In function
‘lyx::{anonymous}::PasteReturnValue
lyx::{anonymous}::pasteSelectionHelper(const lyx::DocIterator, const
lyx::ParagraphList, lyx::DocumentClassConstPtr, lyx::Buffer*,
lyx::ErrorList)’:
../../master/src/CutAndPaste.cpp:390:37: erreur: call of overloaded
‘next(lyx::RandomAccessListlyx::Paragraph::iterator, lyx::pit_type)’
is ambiguous
../../master/src/CutAndPaste.cpp:390:37: note: candidates are:
../../master/src/support/lyxalgo.h:92:11: note: It lyx::next(It, Diff)
[with It =
__gnu_debug::_Safe_iteratorstd::__cxx1998::_List_iteratorlyx::Paragraph,
std::__debug::listlyx::Paragraph, std::allocatorlyx::Paragraph  ,
Diff = long int]
/usr/include/c++/4.6/bits/stl_iterator_base_funcs.h:182:5: note:
_ForwardIterator std::next(_ForwardIterator, typename
std::iterator_traits_Iter::difference_type) [with _ForwardIterator =
__gnu_debug::_Safe_iteratorstd::__cxx1998::_List_iteratorlyx::Paragraph,
std::__debug::listlyx::Paragraph, std::allocatorlyx::Paragraph  ,
typename std::iterator_traits_Iter::difference_type = long int]



Starting with commit b596330 lyx fails to compile with cmake/xcode.
This seems to be due to boost::next having been replaced by next and 
this generates ambiguous call to 'next' semantic issues, one of the 2 
possibilities being the next in lyxalgo.h mentioned in this message.

So this might be related to this;
I expected LYX_USE_CXX11 to be set (with the later commits that is), but 
that's not the case;
When I manually define LYX_USE_CXX11 the problems with next go away, 
but similar and much more semantic issues surface with bind.


Patrick

Re: Compilation failure un c++11 mode with gcc 4.6

[pdv]

On 19/05/15 11:25, Jean-Marc Lasgouttes wrote:

Hi Georg,

It is not possible currently to compile with gcc 4.6 in C++11 mode
because lyxalgo.h declares its own next() method. This is because the
code depends on __cplusplus >= 201103L, which is not true for this
version of the compiler.

I would propose to replace this test with a test on whether c++11 mode
has been selected by configure. Then it would be our responsibility to
forbid if needed C++11 mode in too old compilers.

The alternative would be to actually check whether the compiler supports
std::next().

JMarc

   CXXCutAndPaste.o
../../master/src/CutAndPaste.cpp: In function
‘lyx::{anonymous}::PasteReturnValue
lyx::{anonymous}::pasteSelectionHelper(const lyx::DocIterator&, const
lyx::ParagraphList&, lyx::DocumentClassConstPtr, lyx::Buffer*,
lyx::ErrorList&)’:
../../master/src/CutAndPaste.cpp:390:37: erreur: call of overloaded
‘next(lyx::RandomAccessList::iterator, lyx::pit_type&)’
is ambiguous
../../master/src/CutAndPaste.cpp:390:37: note: candidates are:
../../master/src/support/lyxalgo.h:92:11: note: It lyx::next(It, Diff)
[with It =
__gnu_debug::_Safe_iterator >,
Diff = long int]
/usr/include/c++/4.6/bits/stl_iterator_base_funcs.h:182:5: note:
_ForwardIterator std::next(_ForwardIterator, typename
std::iterator_traits<_Iter>::difference_type) [with _ForwardIterator =
__gnu_debug::_Safe_iterator >,
typename std::iterator_traits<_Iter>::difference_type = long int]



Starting with commit b596330 lyx fails to compile with cmake/xcode.
This seems to be due to "boost::next" having been replaced by "next" and 
this generates "ambiguous call to 'next'" semantic issues, one of the 2 
possibilities being the "next" in lyxalgo.h mentioned in this message.

So this might be related to this;
I expected LYX_USE_CXX11 to be set (with the later commits that is), but 
that's not the case;
When I manually define LYX_USE_CXX11 the problems with "next" go away, 
but similar and much more semantic issues surface with "bind".


Patrick

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

[pdv]

On 13/8/14, 04:06 , Scott Kostyshak wrote:

On Tue, Aug 12, 2014 at 4:07 PM, pdv pdvissch...@edpnet.be wrote:

As a follow-up on reports in the thread LyX on OS X 10.9 from some months
ago, I build LyX(master) + Qt5(stable) (CMake + XCode).

I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and
observed then (at least) 2 issues:

1) When starting up the menu bar is not visible; One must switch to another
app and then bring lyx to the foreground to make the menu bar appear.
2) When closing the (last) window the menu bar disappears mostly, except for
the LyX menu. This was also reported by Stephan Witt, but I did observe no
crash.

When closing the last window Qt5 should switch to the default menu bar but
apparently it doesn't find one and creates it's own minimal default menu
bar.
The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp)
which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the
Qt docs the first parent-less QMenuBar created will be used as the default
menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a
subclass;

When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is
solved.

GlobalMenuBar() was introduced to override the event() function to handle
QEvent::ShortcutOverride events but shortcuts seem to work without using the
GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work
after first activating one of them via the menu, but the latter also happens
in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms
that GlobalMenuBar's event() is not called when issuing a shortcut with no
window present. I assume that these standard mac-shortcuts are handled
automatically by Qt.

If someone wants to check this, see the attached patch, which includes all
changes (but does not solve issue 1)).


I wonder if this is related to the Ubuntu issue that I and Abdel noticed:
  https://bugs.launchpad.net/ubuntu/+source/appmenu-qt5/+bug/1307619

For 1, does running LyX as lyx -x ui-toggle menubar fix it (or
running that command twice directly in LyX from the command buffer)?
Of course this is just a work around but I wonder if it helps narrow
down the problem.

Scott



It does not help (neither of them).

Patrick De Visschere

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

[pdv]

On 13/8/14, 04:06 , Scott Kostyshak wrote:

On Tue, Aug 12, 2014 at 4:07 PM, pdv <pdvissch...@edpnet.be> wrote:

As a follow-up on reports in the thread "LyX on OS X 10.9" from some months
ago, I build LyX(master) + Qt5(stable) (CMake + XCode).

I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle and
observed then (at least) 2 issues:

1) When starting up the menu bar is not visible; One must switch to another
app and then bring lyx to the foreground to make the menu bar appear.
2) When closing the (last) window the menu bar disappears mostly, except for
the LyX menu. This was also reported by Stephan Witt, but I did observe no
crash.

When closing the last window Qt5 should switch to the "default menu bar" but
apparently it doesn't find one and creates it's own minimal default menu
bar.
The default menu bar is created by GlobalMenuBar() (in GuiApplication.cpp)
which has a constructor GlobalMenuBar() : new QMenuBar(0); according to the
Qt docs the first parent-less QMenuBar created will be used as the default
menu bar. Apparently Qt5 does not detect the QMenuBar(0) created via a
subclass;

When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is
solved.

GlobalMenuBar() was introduced to override the event() function to handle
QEvent::ShortcutOverride events but shortcuts seem to work without using the
GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N and Cmd-O only work
after first activating one of them via the menu, but the latter also happens
in LyX211 and may not be related to Qt5). Building LyX + Qt4.8.6 confirms
that GlobalMenuBar's event() is not called when issuing a shortcut with no
window present. I assume that these standard mac-shortcuts are handled
automatically by Qt.

If someone wants to check this, see the attached patch, which includes all
changes (but does not solve issue 1)).


I wonder if this is related to the Ubuntu issue that I and Abdel noticed:
  https://bugs.launchpad.net/ubuntu/+source/appmenu-qt5/+bug/1307619

For 1, does running LyX as lyx -x "ui-toggle menubar" fix it (or
running that command twice directly in LyX from the command buffer)?
Of course this is just a work around but I wonder if it helps narrow
down the problem.

Scott



It does not help (neither of them).

Patrick De Visschere

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

[pdv]

As a follow-up on reports in the thread LyX on OS X 10.9 from some 
months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).


I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
and observed then (at least) 2 issues:


1) When starting up the menu bar is not visible; One must switch to 
another app and then bring lyx to the foreground to make the menu bar 
appear.
2) When closing the (last) window the menu bar disappears mostly, except 
for the LyX menu. This was also reported by Stephan Witt, but I did 
observe no crash.


When closing the last window Qt5 should switch to the default menu bar 
but apparently it doesn't find one and creates it's own minimal default 
menu bar.
The default menu bar is created by GlobalMenuBar() (in 
GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
created will be used as the default menu bar. Apparently Qt5 does not 
detect the QMenuBar(0) created via a subclass;


When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
solved.


GlobalMenuBar() was introduced to override the event() function to 
handle QEvent::ShortcutOverride events but shortcuts seem to work 
without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N 
and Cmd-O only work after first activating one of them via the menu, but 
the latter also happens in LyX211 and may not be related to Qt5). 
Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not 
called when issuing a shortcut with no window present. I assume that 
these standard mac-shortcuts are handled automatically by Qt.


If someone wants to check this, see the attached patch, which includes 
all changes (but does not solve issue 1)).


Patrick De Visschere
diff --git a/src/frontends/qt4/CategorizedCombo.cpp 
b/src/frontends/qt4/CategorizedCombo.cpp
index 1fd7f35..e8611de 100644
--- a/src/frontends/qt4/CategorizedCombo.cpp
+++ b/src/frontends/qt4/CategorizedCombo.cpp
@@ -455,7 +455,7 @@ bool CategorizedCombo::eventFilter(QObject * o, QEvent * e)
 
 void CategorizedCombo::setIconSize(QSize size)
 {
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
bool small = size.height()  20;
setAttribute(Qt::WA_MacSmallSize, small);
setAttribute(Qt::WA_MacNormalSize, !small);
diff --git a/src/frontends/qt4/FileDialog.cpp b/src/frontends/qt4/FileDialog.cpp
index 8f63d2e..3b75056 100644
--- a/src/frontends/qt4/FileDialog.cpp
+++ b/src/frontends/qt4/FileDialog.cpp
@@ -35,7 +35,7 @@
  *
  * Therefore there is a tradeoff in enabling or disabling this (JMarc)
  */
-#if defined(Q_WS_MACX) || (defined(Q_WS_WIN)  !defined(Q_OS_CYGWIN))
+#if (defined(Q_OS_MACX))  QT_VERSION  0x05 || defined(Q_WS_MACX) || 
(defined(Q_WS_WIN)  !defined(Q_OS_CYGWIN))
 #define USE_NATIVE_FILEDIALOG 1
 #endif
 
diff --git a/src/frontends/qt4/FindAndReplace.cpp 
b/src/frontends/qt4/FindAndReplace.cpp
index 3309803..108e035 100644
--- a/src/frontends/qt4/FindAndReplace.cpp
+++ b/src/frontends/qt4/FindAndReplace.cpp
@@ -613,7 +613,7 @@ void FindAndReplaceWidget::updateGUI()
 Dialog * createGuiSearchAdv(GuiView  lv)
 {
FindAndReplace * gui = new FindAndReplace(lv, Qt::RightDockWidgetArea);
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
// On Mac show and floating
gui-setFloating(true);
 #endif
diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 660b122..b1a6cfe 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -72,7 +72,7 @@
 #include support/Systemcall.h
 #include support/TempFile.h
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
 #include support/AppleScript.h
 #include support/linkback/LinkBackProxy.h
 #endif
@@ -127,9 +127,9 @@
 #include objidl.h
 #endif // Q_WS_WIN
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
 #include QMacPasteboardMime
-#endif // Q_WS_MACX
+#endif // Q_OS_MACX
 
 #include support/bind.h
 #include boost/crc.hpp
@@ -662,7 +662,7 @@ public:
}
 };
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
 // QMacPasteboardMimeGraphics can only be compiled on Mac.
 
 class QMacPasteboardMimeGraphics : public QMacPasteboardMime
@@ -940,9 +940,10 @@ struct GuiApplication::Private
QHashint, GuiView * views_;
 
/// Only used on mac.
-   GlobalMenuBar * global_menubar_;
+   //GlobalMenuBar * global_menubar_;
+   QMenuBar * global_menubar_;
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX)  QT_VERSION  0x05) || defined(Q_WS_MACX)
/// Linkback mime handler for MacOSX.
QMacPasteboardMimeGraphics mac_pasteboard_mime_;
 #endif
@@ -961,7 +962,7 @@ GuiApplication * guiApp;
 
 GuiApplication::~GuiApplication()
 {
-#ifdef Q_WS_MACX
+#if 

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

[pdv]

As a follow-up on reports in the thread "LyX on OS X 10.9" from some 
months ago, I build LyX(master) + Qt5(stable) (CMake + XCode).


I replaced the Q_WS_MACX macro by Q_OS_MACX and QMaxStyle by QProxyStyle 
and observed then (at least) 2 issues:


1) When starting up the menu bar is not visible; One must switch to 
another app and then bring lyx to the foreground to make the menu bar 
appear.
2) When closing the (last) window the menu bar disappears mostly, except 
for the LyX menu. This was also reported by Stephan Witt, but I did 
observe no crash.


When closing the last window Qt5 should switch to the "default menu bar" 
but apparently it doesn't find one and creates it's own minimal default 
menu bar.
The default menu bar is created by GlobalMenuBar() (in 
GuiApplication.cpp) which has a constructor GlobalMenuBar() : new 
QMenuBar(0); according to the Qt docs the first parent-less QMenuBar 
created will be used as the default menu bar. Apparently Qt5 does not 
detect the QMenuBar(0) created via a subclass;


When replacing the GlobalMenuBar() by a base QMenuBar(0) problem 2) is 
solved.


GlobalMenuBar() was introduced to override the event() function to 
handle QEvent::ShortcutOverride events but shortcuts seem to work 
without using the GlobalMenuBar (Cmd-Q and Cmd-, work as expected; Cmd-N 
and Cmd-O only work after first activating one of them via the menu, but 
the latter also happens in LyX211 and may not be related to Qt5). 
Building LyX + Qt4.8.6 confirms that GlobalMenuBar's event() is not 
called when issuing a shortcut with no window present. I assume that 
these standard mac-shortcuts are handled automatically by Qt.


If someone wants to check this, see the attached patch, which includes 
all changes (but does not solve issue 1)).


Patrick De Visschere
diff --git a/src/frontends/qt4/CategorizedCombo.cpp 
b/src/frontends/qt4/CategorizedCombo.cpp
index 1fd7f35..e8611de 100644
--- a/src/frontends/qt4/CategorizedCombo.cpp
+++ b/src/frontends/qt4/CategorizedCombo.cpp
@@ -455,7 +455,7 @@ bool CategorizedCombo::eventFilter(QObject * o, QEvent * e)
 
 void CategorizedCombo::setIconSize(QSize size)
 {
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
bool small = size.height() < 20;
setAttribute(Qt::WA_MacSmallSize, small);
setAttribute(Qt::WA_MacNormalSize, !small);
diff --git a/src/frontends/qt4/FileDialog.cpp b/src/frontends/qt4/FileDialog.cpp
index 8f63d2e..3b75056 100644
--- a/src/frontends/qt4/FileDialog.cpp
+++ b/src/frontends/qt4/FileDialog.cpp
@@ -35,7 +35,7 @@
  *
  * Therefore there is a tradeoff in enabling or disabling this (JMarc)
  */
-#if defined(Q_WS_MACX) || (defined(Q_WS_WIN) && !defined(Q_OS_CYGWIN))
+#if (defined(Q_OS_MACX)) && QT_VERSION > 0x05 || defined(Q_WS_MACX) || 
(defined(Q_WS_WIN) && !defined(Q_OS_CYGWIN))
 #define USE_NATIVE_FILEDIALOG 1
 #endif
 
diff --git a/src/frontends/qt4/FindAndReplace.cpp 
b/src/frontends/qt4/FindAndReplace.cpp
index 3309803..108e035 100644
--- a/src/frontends/qt4/FindAndReplace.cpp
+++ b/src/frontends/qt4/FindAndReplace.cpp
@@ -613,7 +613,7 @@ void FindAndReplaceWidget::updateGUI()
 Dialog * createGuiSearchAdv(GuiView & lv)
 {
FindAndReplace * gui = new FindAndReplace(lv, Qt::RightDockWidgetArea);
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
// On Mac show and floating
gui->setFloating(true);
 #endif
diff --git a/src/frontends/qt4/GuiApplication.cpp 
b/src/frontends/qt4/GuiApplication.cpp
index 660b122..b1a6cfe 100644
--- a/src/frontends/qt4/GuiApplication.cpp
+++ b/src/frontends/qt4/GuiApplication.cpp
@@ -72,7 +72,7 @@
 #include "support/Systemcall.h"
 #include "support/TempFile.h"
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
 #include "support/AppleScript.h"
 #include "support/linkback/LinkBackProxy.h"
 #endif
@@ -127,9 +127,9 @@
 #include 
 #endif // Q_WS_WIN
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
 #include 
-#endif // Q_WS_MACX
+#endif // Q_OS_MACX
 
 #include "support/bind.h"
 #include 
@@ -662,7 +662,7 @@ public:
}
 };
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
 // QMacPasteboardMimeGraphics can only be compiled on Mac.
 
 class QMacPasteboardMimeGraphics : public QMacPasteboardMime
@@ -940,9 +940,10 @@ struct GuiApplication::Private
QHash views_;
 
/// Only used on mac.
-   GlobalMenuBar * global_menubar_;
+   //GlobalMenuBar * global_menubar_;
+   QMenuBar * global_menubar_;
 
-#ifdef Q_WS_MACX
+#if (defined(Q_OS_MACX) && QT_VERSION > 0x05) || defined(Q_WS_MACX)
/// Linkback mime handler for MacOSX.
QMacPasteboardMimeGraphics mac_pasteboard_mime_;
 #endif
@@ -961,7 +962,7 @@ GuiApplication * guiApp;
 
 GuiApplication::~GuiApplication()
 {
-#ifdef Q_WS_MACX
+#if 

Re: LyX + Qt5 + CMake + XCode - attached files (1/1) - RTL.tiff (1/1) - testing LTR.lyx (1/1)

[pdv]

In article 525824a7.8080...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 05/10/2013 11:05, pdv:
  I do the same but English/Dutch marked as Farsi.
  I have attached a screenshot.
 
  Would you have a document too? I cannot reproduce.
  Yes, here it is.
 
 Strange, I do not obtain the same result as you do. I will try on a mac.
 
 JMarc

I tested the str-metrics version (the one dated 25 oct) and the cursor 
positioning is not correct on my mac, but maybe you expect this, since 
the work is not finished.

pdv

Re: LyX + Qt5 + CMake + XCode - attached files (1/1) - RTL.tiff (1/1) - testing LTR.lyx (1/1)

[pdv]

In article <525824a7.8080...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 05/10/2013 11:05, pdv:
> >>> I do the same but English/Dutch marked as Farsi.
> >>> I have attached a screenshot.
> >>
> >> Would you have a document too? I cannot reproduce.
> > Yes, here it is.
> 
> Strange, I do not obtain the same result as you do. I will try on a mac.
> 
> JMarc

I tested the str-metrics version (the one dated 25 oct) and the cursor 
positioning is not correct on my mac, but maybe you expect this, since 
the work is not finished.

pdv

Re: LyX + Qt5 + CMake + XCode - attached files (1/1) - RTL.tiff (1/1) - testing LTR.lyx (1/1)

[pdv]

In article 52443e06.5070...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 24/09/2013 22:01, pdv:
  In article 52399f02.4040...@lyx.org,
Jean-Marc Lasgouttes lasgout...@lyx.org wrote:
 
  14/09/2013 18:41, pdv:
  For checking RTL text I select the Farsi language. Are there RTL
  languages other than Arabic and Hebrew?
  As you mention in the README this doesn't work right  now (text falls of
  the window on the right).
 
  I'd be interested to see screenshots. To be frank, all my testing has
  been done by writing english text marked as hebrew. This is very
  efficient to test RtL issues, but not for ligatures.
 
  I do the same but English/Dutch marked as Farsi.
  I have attached a screenshot.
 
 Would you have a document too? I cannot reproduce.
Yes, here it is.
 
 JMarc

begin 644 testing LTR.lyx
M(TQY6`R+C$@8W)E871E9!T:ES(9I;4N($9OB!M;W)E(EN9F\@V5E
M(AT='`Z+R]W=WN;'EX+F]R9R\*7QY9OFUA=`T-C0*7)E9VEN7V1O
M8W5M96YTEQB96=I;E]H96%D97(*7'1E'1C;%SR!AG1I8VQEEQUV5?
M95F875L=%]O'1I;VYS('1R=64*7UA:6YT86EN7W5N:6YC;'5D961?8VAI
M;1R96X@9F%LV4*7QA;F=U86=E(9AG-IEQL86YG=6%G95]P86-K86=E
M(1E9F%U;'0*7EN'5T96YC;V1I;F@875T;PI9F]N=5N8V]D:6YG(=L
M;V)A;`I9F]N=%]R;VUA;B!D969A=6QTEQF;VYT7W-A;G,@95F875L=`I
M9F]N=%]T7!E=W)I=5R(1E9F%U;'0*79O;G1?;6%T:!A=71OEQF;VYT
M7V1E9F%U;'1?9F%M:6QY(1E9F%U;'0*7'5S95]N;VY?=5X7V9O;G1S(9A
M;'-EEQF;VYT7W-C(9A;'-EEQF;VYT7V]S9B!F86QS90I9F]N=%]S9E]S
M8V%L92`Q,#`*79O;G1?='1?V-A;4@,3`PEQGF%P:ECR!D969A=6QT
MEQD969A=6QT7V]U='!U=%]F;W)M870@95F875L=`I;W5T'5T7W-Y;F,@
M,`I8FEB=5X7V-O;6UA;F0@95F875L=`I:6YD97A?8V]M;6%N9!D969A
M=6QTEQP87!EF9O;G1S:7IE(1E9F%U;'0*7'-P86-I;F@VEN9VQEEQU
MV5?:'EP97)R968@9F%LV4*7'!A5RVEZ92!D969A=6QTEQUV5?9V5O
M;65TGD@9F%LV4*7'5S95]P86-K86=E(%MVUA=@@,0I=7-E7W!A8VMA
M9V4@86USWEM8B`QEQUV5?%C:V%G92!C86YC96P@,`I=7-E7W!A8VMA
M9V4@97-I;G0@,0I=7-E7W!A8VMA9V4@;6%T:1O=',@,0I=7-E7W!A8VMA
M9V4@;6%T:'1O;VQS(#`*7'5S95]P86-K86=E(UH8VAE;2`QEQUV5?%C
M:V%G92!S=%C:W)E;`PEQUV5?%C:V%G92!S=UAGER9`PEQUV5?
M%C:V%G92!U;F1EG1I;1E(#`*7-I=5?96YG:6YE()AVECEQC:71E
M7V5N9VEN95]T7!E(YU;65R:6-A;`I8FEB;EO7W-T6QE('!L86ENEQU
MV5?8FEB=]P:6,@9F%LV4*7'5S95]I;F1I8V5S(9A;'-EEQP87!EF]R
M:65N=%T:6]N('!OG1R86ETEQS=7!PF5SU]D871E(9A;'-EEQJ=7-T
M:69I8V%T:6]N('1R=64*7'5S95]R969S='EL92`QEQI;F1E!);F1E`I
MVAOG1C=70@:61XEQC;VQOB`C,#`X,#`PEQE;F1?:6YD97@*7'-E8VYU
M;61E'1H(#,*7'1O8V1E'1H(#,*7'!AF%GF%P:%]S97!AF%T:6]N('-K
M:7`*71E9G-K:7`@VUA;QS:VEPEQQ=6]T97-?;%N9W5A9V4@96YG;ES
M:`I%P97)C;VQU;6YS(#$*7'!A5RVED97,@,0I%P97)P86=EW1Y
M;4@95F875L=`I=')A8VMI;F=?8VAA;F=ER!F86QS90I;W5T'5T7V-H
M86YG97,@9F%LV4*7AT;6Q?;6%T:%]O=71P=70@,`I:'1M;%]CW-?87-?
M9FEL92`PEQH=UL7V)E7W-TFEC=!F86QS90I96YD7VAE861E@H*7)E
M9VEN7V)O9'D*EQB96=I;E]L87EO=70@4W1A;F1AF0*165N('1EW0@;65T
M($Q44B!L86YG=6%G97,NB!%:6MS+@H@5V5R:W0@9ET/R!-:6X@;V8@;65E
MB`*7)E9VEN7VENV5T($9OFUU;$@)$K8CUC)`I96YD7VENV5T@H@
M;6%AB!D92!C=7)S;W,@:7,@=]C:!N:65T(=O960@9V5P;W-T:6]N965R
M9X*75N9%]L87EO=70*EQB96=I;E]L87EO=70@4W1A;F1AF0*165N(MO
MG1E('II;BX*75N9%]L87EO=70*EQB96=I;E]L87EO=70@4W1A;F1AF0*
M165N(')E9FQO=VEN9R!Z:6XNB!%96X@F5F;]W:6YG('II;BX*($5E;B!R
M969L;W=I;F@FEN+@H@165N(')E9FQO=VEN9R!Z:6XNB!%96X@F5F;]W
M:6YG('II;BX*($5E;B!R969L;W=I;F@FEN+@H@165N(')E9FQO=VEN9R!%
M96XNEQE;F1?;%Y;W5T@I8F5G:6Y?;%Y;W5T(%-T86YD87)DFUM;6UM
M;6UM;6T@;6UM;6UM;6UM;2!M;6UM;6UM;6UM(UM;6UM;6UM;6T@;6UM;6UM
M;6UM;2!M;6UM;6UM;6UM(UM;6UM;6UM;6T*75N9%]L87EO=70*EQE;F1?
38F]D0I96YD7V1O8W5M96YT@==
`
end

Re: LyX + Qt5 + CMake + XCode - attached files (1/1) - RTL.tiff (1/1) - testing LTR.lyx (1/1)

[pdv]

In article <52443e06.5070...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 24/09/2013 22:01, pdv:
> > In article <52399f02.4040...@lyx.org>,
> >   Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:
> >
> >> 14/09/2013 18:41, pdv:
> >>> For checking RTL text I select the "Farsi" language. Are there RTL
> >>> languages other than Arabic and Hebrew?
> >>> As you mention in the README this doesn't work right  now (text falls of
> >>> the window on the right).
> >>
> >> I'd be interested to see screenshots. To be frank, all my testing has
> >> been done by writing english text marked as hebrew. This is very
> >> efficient to test RtL issues, but not for ligatures.
> >
> > I do the same but English/Dutch marked as Farsi.
> > I have attached a screenshot.
> 
> Would you have a document too? I cannot reproduce.
Yes, here it is.
> 
> JMarc

begin 644 testing LTR.lyx
M(TQY6"`R+C$@8W)E871E9"!T:(&9I;&4N($9O<B!M;W)E(\@&9O

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article 52303c42.5010...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 09/09/2013 20:39, pdv:
  Where do I find the features/str-metrics branch?
 
 Following http://wiki.lyx.org/Devel/LyXGit#toc3, here is what I would 
 suggest:
 
 git remote add features git:features.git
 git checkout --track -b features/str-metrics
 
 JMarc

Thanks, I looked at the wiki but apparently not hard enough.

When working on my solution I've collected all problems I've ran into in 
a test document and I see no problems with that document for LTR text.

For checking RTL text I select the Farsi language. Are there RTL 
languages other than Arabic and Hebrew?
As you mention in the README this doesn't work right  now (text falls of 
the window on the right).

For LTR text there is a minor issue when selecting text within a 
paragraph which runs over multiple rows: the selected text jitters while 
selecting. This goes away by removing the conditional break in 
RowPainter::paintChars (lines 271-274), but that code must still be 
adapted I understand. I did also remove the following two conditional 
breaks and haven't experienced any problem until now, so I wonder 
whether it's needed.

The performance right now is similar to my patched version: scrolling 
through the user guide takes about 6-7 sec, whereas with LyX206 it takes 
more than 20s.

Regards,

P. De Visschere

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article <52303c42.5010...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 09/09/2013 20:39, pdv:
> > Where do I find the features/str-metrics branch?
> 
> Following http://wiki.lyx.org/Devel/LyXGit#toc3, here is what I would 
> suggest:
> 
> git remote add features git:features.git
> git checkout --track -b features/str-metrics
> 
> JMarc

Thanks, I looked at the wiki but apparently not hard enough.

When working on my solution I've collected all problems I've ran into in 
a test document and I see no problems with that document for LTR text.

For checking RTL text I select the "Farsi" language. Are there RTL 
languages other than Arabic and Hebrew?
As you mention in the README this doesn't work right  now (text falls of 
the window on the right).

For LTR text there is a minor issue when selecting text within a 
paragraph which runs over multiple rows: the selected text jitters while 
selecting. This goes away by removing the conditional break in 
RowPainter::paintChars (lines 271-274), but that code must still be 
adapted I understand. I did also remove the following two conditional 
breaks and haven't experienced any problem until now, so I wonder 
whether it's needed.

The performance right now is similar to my patched version: scrolling 
through the user guide takes about 6-7 sec, whereas with LyX206 it takes 
more than 20s.

Regards,

P. De Visschere

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article 5225ad48.2050...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 31/08/2013 14:47, pdv:
  Hello,
 
  I've build LyX+Qt5.2 using CMake and XCode and needed to make the
  following changes (see 3 attached patch files):
 
 Hello,
 
 Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
 porting missed the Q_WS_xx defines, that need to be reevaluated one by 
 one. Vincent, what is your take on this?
 
  3) With the changes above the application builds and looks OK (AFAICS)
  but most menus are missing;
  Inserting an updateMenu() in Menus.cpp solves this.
 
 Stephan, did you try Qt5 already?
 
 BTW, pdv, could you have a look at the features/str-metrics branch, 
 where I did something similar to your own patch? I have not really 
 looked at performance right now (the old code runs in parallel with the 
 new one by default), but I try to be as correct as possible. This is 
 code for 2.2 anyway.
 

Where do I find the features/str-metrics branch?

pdv

 JMarc

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article <5225ad48.2050...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 31/08/2013 14:47, pdv:
> > Hello,
> >
> > I've build LyX+Qt5.2 using CMake and XCode and needed to make the
> > following changes (see 3 attached patch files):
> 
> Hello,
> 
> Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
> porting missed the Q_WS_xx defines, that need to be reevaluated one by 
> one. Vincent, what is your take on this?
> 
> > 3) With the changes above the application builds and looks OK (AFAICS)
> > but most menus are missing;
> > Inserting an updateMenu() in Menus.cpp solves this.
> 
> Stephan, did you try Qt5 already?
> 
> BTW, pdv, could you have a look at the features/str-metrics branch, 
> where I did something similar to your own patch? I have not really 
> looked at performance right now (the old code runs in parallel with the 
> new one by default), but I try to be as correct as possible. This is 
> code for 2.2 anyway.
> 

Where do I find the features/str-metrics branch?

pdv

> JMarc

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article 5225ad48.2050...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 31/08/2013 14:47, pdv:
  Hello,
 
  I've build LyX+Qt5.2 using CMake and XCode and needed to make the
  following changes (see 3 attached patch files):
 
 Hello,
 
 Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
 porting missed the Q_WS_xx defines, that need to be reevaluated one by 
 one. Vincent, what is your take on this?

master

pdv

 
  3) With the changes above the application builds and looks OK (AFAICS)
  but most menus are missing;
  Inserting an updateMenu() in Menus.cpp solves this.
 
 Stephan, did you try Qt5 already?
 
 BTW, pdv, could you have a look at the features/str-metrics branch, 
 where I did something similar to your own patch? I have not really 
 looked at performance right now (the old code runs in parallel with the 
 new one by default), but I try to be as correct as possible. This is 
 code for 2.2 anyway.
 
 JMarc

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article 14313d0e-314a-4098-89b3-bfa7990a9...@gmx.net,
 Stephan Witt st.w...@gmx.net wrote:

 Am 03.09.2013 um 11:35 schrieb Jean-Marc Lasgouttes lasgout...@lyx.org:
 
  31/08/2013 14:47, pdv:
  Hello,
  
  I've build LyX+Qt5.2 using CMake and XCode and needed to make the
  following changes (see 3 attached patch files):
  
  Hello,
  
  Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
  porting missed the Q_WS_xx defines, that need to be reevaluated one by one. 
  Vincent, what is your take on this?
  
  3) With the changes above the application builds and looks OK (AFAICS)
  but most menus are missing;
  Inserting an updateMenu() in Menus.cpp solves this.
  
  Stephan, did you try Qt5 already?
 
 Yes, I tried 5.0 and we kind of support it already.
 With 5.1 I gave up because of the missing menus.
 I didn't look for 5.2 until now - is it really released already?

I don't think so. I switched to the dev branch to solve a missing fonts 
issue.

pdv

 
 Stephan
 
  
  BTW, pdv, could you have a look at the features/str-metrics branch, where I 
  did something similar to your own patch? I have not really looked at 
  performance right now (the old code runs in parallel with the new one by 
  default), but I try to be as correct as possible. This is code for 2.2 
  anyway.
  
  JMarc
 

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article <5225ad48.2050...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 31/08/2013 14:47, pdv:
> > Hello,
> >
> > I've build LyX+Qt5.2 using CMake and XCode and needed to make the
> > following changes (see 3 attached patch files):
> 
> Hello,
> 
> Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
> porting missed the Q_WS_xx defines, that need to be reevaluated one by 
> one. Vincent, what is your take on this?

master

pdv

> 
> > 3) With the changes above the application builds and looks OK (AFAICS)
> > but most menus are missing;
> > Inserting an updateMenu() in Menus.cpp solves this.
> 
> Stephan, did you try Qt5 already?
> 
> BTW, pdv, could you have a look at the features/str-metrics branch, 
> where I did something similar to your own patch? I have not really 
> looked at performance right now (the old code runs in parallel with the 
> new one by default), but I try to be as correct as possible. This is 
> code for 2.2 anyway.
> 
> JMarc

Re: LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

In article <14313d0e-314a-4098-89b3-bfa7990a9...@gmx.net>,
 Stephan Witt <st.w...@gmx.net> wrote:

> Am 03.09.2013 um 11:35 schrieb Jean-Marc Lasgouttes <lasgout...@lyx.org>:
> 
> > 31/08/2013 14:47, pdv:
> >> Hello,
> >> 
> >> I've build LyX+Qt5.2 using CMake and XCode and needed to make the
> >> following changes (see 3 attached patch files):
> > 
> > Hello,
> > 
> > Is this for branch 2.0.x or for master? Indeed it seems that the Qt5 
> > porting missed the Q_WS_xx defines, that need to be reevaluated one by one. 
> > Vincent, what is your take on this?
> > 
> >> 3) With the changes above the application builds and looks OK (AFAICS)
> >> but most menus are missing;
> >> Inserting an updateMenu() in Menus.cpp solves this.
> > 
> > Stephan, did you try Qt5 already?
> 
> Yes, I tried 5.0 and we kind of support it already.
> With 5.1 I gave up because of the missing menus.
> I didn't look for 5.2 until now - is it really released already?

I don't think so. I switched to the dev branch to solve a missing fonts 
issue.

pdv

> 
> Stephan
> 
> > 
> > BTW, pdv, could you have a look at the features/str-metrics branch, where I 
> > did something similar to your own patch? I have not really looked at 
> > performance right now (the old code runs in parallel with the new one by 
> > default), but I try to be as correct as possible. This is code for 2.2 
> > anyway.
> > 
> > JMarc
> >

LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

Hello,

I've build LyX+Qt5.2 using CMake and XCode and needed to make the 
following changes (see 3 attached patch files):

1) A few modules must be added to qt_use_modules() in 2 CMakeLists.

2) Q_WS_MACX is no longer supported and was replaced by Q_OS_MACX 
(probably a similar change must be made for windows?).
In addition QMacStyle has been replaced by QProxyStyle.
(There are still some occurrences of Q_WS_MAC in FindQt4.cmake.)

3) With the changes above the application builds and looks OK (AFAICS) 
but most menus are missing;
Inserting an updateMenu() in Menus.cpp solves this.

Regards,

Patrick De Visschere

begin 644 LyXQt5CmakeLists.diff
M9EF9B`M+6=I=!A+W-R8R]FF]N=5N9',O70T+T--86ME3ES=',N='AT
M((OW)C+V9R;VYT96YDR]Q=#0O0TUA:V5,:7-TRYT'0*:6YD97@@,30R
M.#-E82XN-C,S930Y9`Q,#`V-#0*+2TM($OW)C+V9R;VYT96YDR]Q=#0O
M0TUA:V5,:7-TRYT'0**RLK((OW)C+V9R;VYT96YDR]Q=#0O0TUA:V5,
M:7-TRYT'0*0$`@+34T+#@*S4T+#$R($!`(5LV4H*0H@96YD:68H*0H@
MV5T7W1AF=E=%]PF]P97)T:65S*9R;VYT96YD7W%T-!04D]015)42453
M($9/3$1%4B`B87!P;EC871I;VYS+TQY6(IB`*+7%T7W5S95]M;V1U;5S
M*9R;VYT96YD7W%T-!#;W)E($=U:2!7:61G971S($-O;F-UG)E;G0IBMI
M9BA!4%!,12D**PEQ=%]UV5?;6]D=6QERAFF]N=5N9%]Q=#0@0V]R92!'
M=6D@5VED9V5TR!#;VYC=7)R96YT($UA8T5X=')ARD**V5LV4H*0HK7%T
M7W5S95]M;V1U;5S*9R;VYT96YD7W%T-!#;W)E($=U:2!7:61G971S($-O
M;F-UG)E;G0IBME;F1I9B@IBL*('1AF=E=%]L:6YK7VQI8G)AFEERAF
MF]N=5N9%]Q=#0*(`EFF]N=5N9',*(`DDU%47U%40T]215],24)205)9
M?0ID:69F(TM9VET($OW)C+W-U'!OG0O0TUA:V5,:7-TRYT'0@8B]S
MF,OW5P]R=]#36%K94QIW1S+G1X=`II;F1E!E9F1A,C`U+BXU-V-E
M.#`P(#$P,#8T-`HM+2T@82]SF,OW5P]R=]#36%K94QIW1S+G1X=`HK
M*RL@8B]SF,OW5P]R=]#36%K94QIW1S+G1X=`I`0`M-S4L-R`K-S4L
M-R!`0!E;'-E*D*(5N9EF*D*('-E=%]T87)G971?')O5R=EERAS
M=7!P;W)T(%!23U!%4E1)15,@1D],1$52()A'!L:6-A=EO;G,O3'E8(BD*
M(`HM71?=7-E7VUO9'5L97,HW5P]R=!#;W)E*0HK71?=7-E7VUO9'5L
M97,HW5P]R=!#;W)E($=U:2D*(`H@=%R9V5T7VQI;FM?;EBF%R:65S
M*'-U'!OG0@)'M,7A?0F]OW1?3EBF%R:65S?2`DU%47U%40T]215],
;24)205)9?2`DUI,24)?3$E4D%267TIB`*
`
end

begin 644 LyXQt5Menus.diff
M9EF9B`M+6=I=!A+W-R8R]FF]N=5N9',O70T+TUE;G5S+F-P!B+W-R
M8R]FF]N=5N9',O70T+TUE;G5S+F-P`II;F1E!C-V5F,3,P+BXS-#(T
M-(Q(#$P,#8T-`HM+2T@82]SF,O9G)O;G1E;F1S+W%T-]-96YURYC'`*
M*RLK((OW)C+V9R;VYT96YDR]Q=#0O365N=7,N8W!PD!`(TR,C(W+#8@
M*S(R,CL-R!`0!V;VED($UE;G5S.CIF:6QL365N=4)ABA1365N=4)AB`J
M('%M8BP@1W5I5FEE=R`J('9I97L()O;VP@:6YI=EA;D*(`D)365N=2`J
M(UE;G4@/2!N97@365N=2AV:65W+!M+3YS=6)M96YU;F%M92@I+!TG5E
M*3L*(`D);65N=2T^V5T5ET;4H;%B96PH*FTI*3L*(`D)6UB+3YA91-
M96YU*UE;G4I.PHK0EU1A=5-96YU*UE;G4I.PH@B`)60M/FYA;65?
=;6%P7UMV:65W75MN86UE72`](UE;G4[B`)?0H=
`
end

begin 644 LyXQt5Q_WS_MACX.diff
M9EF9B`M+6=I=!A+W-R8R]FF]N=5N9',O70T+T-A=5G;W)IF5D0V]M
M8F\N8W!P((OW)C+V9R;VYT96YDR]Q=#0O0V%T96=OFEZ961#;VUB;RYC
M'`*:6YD97@@,69D-V8S-2XN93@V,3%D92`Q,#`V-#0*+2TM($OW)C+V9R
M;VYT96YDR]Q=#0O0V%T96=OFEZ961#;VUB;RYC'`**RLK((OW)C+V9R
M;VYT96YDR]Q=#0O0V%T96=OFEZ961#;VUB;RYC'`*0$`@+30U-2PW(LT
M-34L-R!`0!B;V]L($-A=5G;W)IF5D0V]M8F\Z.F5V96YT1FEL=5R*%%/
M8FIE8W0@*B!O+!1179E;G0@*B!E*0H@B!V;VED($-A=5G;W)IF5D0V]M
M8F\Z.G-E=$EC;VY3:7IE*%%3:7IE('-IF4IB![BTC:69D968@45]74U]-
M04-8BLC:68@*1E9FEN960H45]/4U]-04-8*2`F)B!15%]615)324].(#X@
M,'@P-3`P,#`I('Q\(1E9FEN960H45]74U]-04-8*0H@6)O;VP@VUA;P@
M/2!S:7IE+FAE:6=H=@I(#P@,C`[B`)V5T071TFEB=71E*%%T.CI705]-
M86-3;6%L;%-IF4L('-M86QL*3L*(`ES971!='1R:6)U=4H470Z.E=!7TUA
M8TYOFUA;%-IF4L(%S;6%L;D[F1I9F8@+2UG:70@82]SF,O9G)O;G1E
M;F1S+W%T-]:6QE1EA;]G+F-P!B+W-R8R]FF]N=5N9',O70T+T9I
M;5$:6%L;VN8W!PFEN95X(#!D-F%B9,N+CDX-F,R.3@,3`P-C0TBTM
M+2!A+W-R8R]FF]N=5N9',O70T+T9I;5$:6%L;VN8W!PBLK*R!B+W-R
M8R]FF]N=5N9',O70T+T9I;5$:6%L;VN8W!PD!`(TS-2PW(LS-2PW
M($!`B`@*@H@(H@5AEF5F;W)E('1H97)E(ES($@=')A95O9F8@:6X@
M96YA8FQI;F@;W(@9ES86)L:6YG('1H:7,@*$I-87)C*0H@(HOBTC:68@
M95F:6YE9A17U=37TU!0U@I('Q\(AD969I;F5D*%%?5U-?5TE.*2`F)B`A
M95F:6YE9A17T]37T-91U=)3BDIBLC:68@*1E9FEN960H45]/4U]-04-8
M*2D@)B8@451?5D524TE/3B`^(#!X,#4P,#`P('Q\(1E9FEN960H45]74U]-
M04-8*2!\?`H95F:6YE9A17U=37U=)3BD@)B8@(61E9FEN960H45]/4U]#
M64=724XI*0H@(V1E9FEN92!54T5?3D%4259%7T9)3$5$24%,3T@,0H@(V5N
M9EFB`*9EF9B`M+6=I=!A+W-R8R]FF]N=5N9',O70T+T9I;F1!;F12
M97!L86-E+F-P!B+W-R8R]FF]N=5N9',O70T+T9I;F1!;F1297!L86-E
M+F-P`II;F1E`Q83,Y,5C+BYD-#=B,#@Y(#$P,#8T-`HM+2T@82]SF,O
M9G)O;G1E;F1S+W%T-]:6YD06YD4F5P;%C92YC'`**RLK((OW)C+V9R
M;VYT96YDR]Q=#0O1FEN9$%N9%)EQA8V4N8W!PD!`(TV,#,L-R`K-C`S
M+#@0$`@=F]I9!:6YD06YD4F5P;%C95=I9=E=#HZ=7!D871E1U5)*D*
M($1I86QO9R`J(-R96%T94=U:5-E87)C:$%D=BA'=6E6:65W(8@;'8IB![
MB`)1FEN9$%N9%)EQA8V4@*B!G=6D@/2!N97@1FEN9$%N9%)EQA8V4H
M;'8L(%%T.CI2:6=H=$1O8VM7:61G971!F5A*3L*+2-I9F1E9B!17U=37TU!
M0U@**R-I9B`H95F:6YE9A17T]37TU!0U@I(8F(%%47U9%4E-)3TX@/B`P
M#`U,#`P,D@?'P@95F:6YE9A17U=37TU!0U@IB`)+R\@3VX@36%C('-H
M;W@86YD(9L;V%T:6YGB`)9W5I+3YS971;]A=EN9RATG5E*3L*(-E
M;F1I9@ID:69F(TM9VET($OW)C+V9R;VYT96YDR]Q=#0O1W5I07!P;EC
M871I;VXN8W!P((OW)C+V9R;VYT96YDR]Q=#0O1W5I07!P;EC871I;VXN
M8W!PFEN95X(#4S9F(Q-S`N+F$W939F-6,@,3`P-C0TBTM+2!A+W-R8R]F
MF]N=5N9',O70T+T=U:4%PQI8V%T:6]N+F-P`HK*RL@8B]SF,O9G)O
M;G1E;F1S+W%T-]'=6E!'!L:6-A=EO;BYC'`*0$`@+3Q+#@*SQ+#@
M0$`*(-I;F-L=61E()S=7!P;W)T+U!A=A#:%N9V5R+F@BB`C:6YC;'5D

LyX + Qt5 + CMake + XCode - attached files (1/1)

[pdv]

Hello,

I've build LyX+Qt5.2 using CMake and XCode and needed to make the 
following changes (see 3 attached patch files):

1) A few modules must be added to qt_use_modules() in 2 CMakeLists.

2) Q_WS_MACX is no longer supported and was replaced by Q_OS_MACX 
(probably a similar change must be made for windows?).
In addition QMacStyle has been replaced by QProxyStyle.
(There are still some occurrences of Q_WS_MAC in FindQt4.cmake.)

3) With the changes above the application builds and looks OK (AFAICS) 
but most menus are missing;
Inserting an updateMenu() in Menus.cpp solves this.

Regards,

Patrick De Visschere

begin 644 LyXQt5CmakeLists.diff
M9`M+6=I="!A+W-R8R]F

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1) - LyXscrollpatch20130509.diff (1/1)

[pdv]

In article 517ee12b.4040...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 28/04/2013 13:06, pdv a écrit :
  OK, here is a new version. Let me know if you experience anymore
  problems.
  For the time being I've left the clean-up step of the map as it was,
  although I realize it's of limited value; when entering the same word
  multiple times, the partial words get included anyway;
 
  The map itself is still defined in the BufferView class, but as a shared
  static map. The reason for this is that when the user makes changes to
  the screen fonts, the map becomes useless and I think the best option is
  to clear it at that point.
  I've added the case LFUN_SCREEN_FONT_UPDATE: to BufferView::dispatch()
  and added a corresponding request in GuiApplication::dispatch();
 
 You should move the code that computes text width to 
 GuiFontMetrics::width(docstring). This is the right place for storing a 
 map, that could be static if you want to keep your current solution or 
 just a member of the GuiFontMetrics object so that you do not have to 
 play tricks with font attributes.
 
 Moreover, if your mùap is in GuiFontMetrics it will be reset 
 automatically by the code in GuiApplication.cpp.
 
 This will be much easier in my opinion.
 
  I noticed then that the map was cleared and rebuild twice ...
  ... because in GuiPreferences::dispatchParams() there is first a call
  dispatch(FuncRequest(LFUN_LYXRC_APPLY, ss.str()))
  later followed by
  dispatch(FuncRequest(LFUN_SCREEN_FONT_UPDATE))
  but the first dispatch runs GuiReset() which also sends a
  LFUN_SCREEN_FONT_UPDATE.
  Therefore I've commented out the 2nd explicit LFUN_SCREEN_FONT_UPDATE
  request.
 
 Not sure about that, but things should become clearer once code is at 
 the right place.
 
 JMarc

I've moved the code to GuiFontMetrics which is indeed much better.
Solved also a remaining issue with smallcaps.

begin 644 LyXscrollpatch20130509.diff
M1G)O;2`W9#)C.3(W,S`W,CW93DX,#(T96,X,C0X83X8F4U,#,Q,5F,68V
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!0871R:6-K($1E(%9I
MW-C:5R92`\1V:7-S8VAEF5`961P;F5T+F)E/@I$871E.B!7960L(#$@
M36%Y(#(P,3,@,C(Z-38Z,3$@*S`R,#`*4W5B:F5C=#H@6U!!5$-(72!-;W9E
M9!T:4@=5X=%=I9'1H*D@9G)O;2!497AT365TFECR!T;R!'=6E;VYT
M365TFECRP*(')E;F%M960@:70@86YD(9I5D('-M86QL8V%PRX*BTM
M+0H@W)C+T)U9F9EE9I97N8W!P(`@(`@(`@(`@(`@(`@('P@(`T
M(LMB!SF,O0G5F9F5R5FEE=RYH(`@(`@(`@(`@(`@(`@(`@?`@
M(#,@*RT*('-R8R]497AT365TFECRYC'`@(`@(`@(`@(`@(`@(!\
M(#(Y,R`K*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RTM+0H@W)C
M+U1E'1-971R:6-S+F@@(`@(`@(`@(`@(`@(`@('P@(#$X(LK+0H@
MW)C+V9R;VYT96YDR];VYT365TFECRYH(`@(`@(`@('P@(`R(L*
M('-R8R]FF]N=5N9',O70T+T=U:49O;G1-971R:6-S+F-P!\(`T.`K
M*RLK*RL*('-R8R]FF]N=5N9',O70T+T=U:49O;G1-971R:6-S+F@@(!\
M(`@-B`KB!SF,O9G)O;G1E;F1S+W%T-]'=6E086EN=5R+F-P`@(`@
M?`@(#(@*PH@W)C+V9R;VYT96YDR]Q=#0O1W5I4')E9G,N8W!P(`@(`@
M('P@(`S(LMB!SF,OF]W%I;G1EBYC'`@(`@(`@(`@(`@(`@
M(`@?`@,S@*RLK*RL*(#$P(9I;5S(-H86YG960L(#,X-2!I;G-EG1I
M;VYS*LI+`S,2!D96QE=EO;G,H+2D*F1I9F8@+2UG:70@82]SF,O0G5F
M9F5R5FEE=RYC'`@8B]SF,O0G5F9F5R5FEE=RYC'`*:6YD97@@9%A,#5A
M-BXN-S4Y-S(V.2`Q,#`V-#0*+2TM($OW)C+T)U9F9EE9I97N8W!PBLK
M*R!B+W-R8R]=69F97)6:65W+F-P`I`0`M.38U+#@*SDV-2PW($!`('9O
M:60@0G5F9F5R5FEE=SHZ=7!D871E1]C=6UE;G1#;%SRA$;V-U;65N=$-L
M87-S0V]NW10='(@;VQD9,IB`*(`EB=69F97)?+F5RF]RR@B0VQAW,@
M4W=I=-H(BD[B!]BT**PD*(`H@+RHJ(%)E='5R;B!T:4@8VAA;F=E('-T
M871UR!A=!C=7)S;W(@]S:71I;VXL('1A:VEN9R!I;B!A8V-O=6YT('1H
M90H@(H@W1A='5S(%T(5A8V@@;5V96P@;V8@=AE(1O8W5M96YT(ET
M97)A=]R(AA('1A8FQE(EN($@95L971E9`I`0`M,38P,PW(LQ-C`P
M+#@0$`@=F]I9!=69F97)6:65W.CID:7-P871C:A=6YC4F5Q=65S=!C
M;VYS=`F(-M9P@1ES%T8VA297-U;'0@)B!DBD*(`EC87-E($Q54Y?
M4T-2145.7U)%0T5.5$52.@H@0ER96-E;G1Eb...@i.ph@0EBF5A:SL*+0HK
M0D)B`)8V%S92!,1E5.7T))0E1%6%]$051!0D%315]!1$0Z('L*(`D)0W5R
MV]R('1M-UB`](-UCL*(`D)9FEN9$ENV5T*'1M-UBP@0DE5$58
M7T-/1$4L(9A;'-E*3L*9EF9B`M+6=I=!A+W-R8R]=69F97)6:65W+F@@
M8B]SF,O0G5F9F5R5FEE=RYHFEN95X(,W9F(T8S$N+C$X9#-A,6,@,3`P
M-C0TBTM+2!A+W-R8R]=69F97)6:65W+F@**RLK((OW)C+T)U9F9EE9I
M97N:`I`0`M,S(P+#@*S,R,PW($!`('!U8FQI8SH*(`EB;V]L(-L:6-K
M86)L94ENV5T*D@8V]NW0[B`)+R\OB`)=F]I9!M86ME1]C=6UE;G1#
M;%Sr...@i.phmBL)B!PFEV871E.@H@2\O+R!N;VYC;W!Y86)L90H@4)U
M9F9EE9I97H0G5F9F5R5FEE=R!C;VYS=`F*3L*0$`@+3,V,2PV(LS-C$L
M-R!`0!PFEV871E.@H@B`)W1R=6-T(%!R:79A=4[B`)4')I=F%T92`J
M(-O;G-T(0[BL)B!].PH@B`O+R\@V]M92!S%C92!F;W(@9')A=VEN
M9R!T:4@)VYEW1E9@;6%R:V5RR`H:6X@EX96PIF1I9F8@+2UG:70@
M82]SF,O55X=$UE=')I8W,N8W!P((OW)C+U1E'1-971R:6-S+F-P`II
M;F1E`T93P9,P+BYD-S0Y-V(Y(#$P,#8T-`HM+2T@82]SF,O55X=$UE
M=')I8W,N8W!PBLK*R!B+W-R8R]497AT365TFECRYC'`*0$`@+30Y+#$P
M(LT.2PQ-B!`0`H@(VEN8VQU94@(F9R;VYT96YDR];VYT365TFECRYH
M(@H@(VEN8VQU94@(F9R;VYT96YDR]086EN=5R+F@BB`**R-I;F-L=61E
M()FF]N=5N9',O70T+T=U:49O;G1,;V%D97(N:(**PH@(VEN8VQU94@
M(G-U'!OG0O95B=6N:(*(-I;F-L=61E()S=7!P;W)T+V1O8W-TFEN
M9U]L:7-T+F@BB`C:6YC;'5D92`BW5P]R=]G971T97AT+F@BB`C:6YC
M;'5D92`BW5P]R=]L87-S97)T+F@BBLC:6YC;'5D92`BW5P]R=]Q
MW1R:6YG7VAE;'!EG,N:(**R-I;F-L=61E()S=7!P;W)T+W1E'1U=EL
MRYH(@HKBLC:6YC;'5D92`\471'=6DO449O;G1-971R:6-S/@H@B`C:6YC
M;'5D92`\8W-T9QI8CX

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article 5186ae01.4080...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 05/05/13 20:36, pdv a écrit :
  What exactly takes 17.4s?
 
  I suppose that's the time taken by GuiPainter::text(), but I don't know
  enough of the Instruments app and it's modules to give any more details.
 
  I've now monitored both functions with pmprof:
  ( I scroll through a document of mine starting from the top down to the
  same location with the down arrow key (line per line not page per page) )
 
 A related question: will you be somewhat available during the coming 
 week? I'd like at the developers meeting (from Thursday to Sunday) to 
 start from your patch and apply it to master branch. We will probably 
 diverge significantly from what you propose but nevertheless it would be 
 useful to know whether there are times when you are available. The plan 
 is probably to set up a branch on git to work on.
 
 JMarc

Yes, I'm available.
I've posted another version as you might already have noticed.

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1) - LyXscrollpatch20130509.diff (1/1)

[pdv]

In article <517ee12b.4040...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 28/04/2013 13:06, pdv a écrit :
> > OK, here is a new version. Let me know if you experience anymore
> > problems.
> > For the time being I've left the clean-up step of the map as it was,
> > although I realize it's of limited value; when entering the same word
> > multiple times, the partial words get included anyway;
> >
> > The map itself is still defined in the BufferView class, but as a shared
> > static map. The reason for this is that when the user makes changes to
> > the screen fonts, the map becomes useless and I think the best option is
> > to clear it at that point.
> > I've added the case LFUN_SCREEN_FONT_UPDATE: to BufferView::dispatch()
> > and added a corresponding request in GuiApplication::dispatch();
> 
> You should move the code that computes text width to 
> GuiFontMetrics::width(docstring). This is the right place for storing a 
> map, that could be static if you want to keep your current solution or 
> just a member of the GuiFontMetrics object so that you do not have to 
> play tricks with font attributes.
> 
> Moreover, if your mùap is in GuiFontMetrics it will be reset 
> automatically by the code in GuiApplication.cpp.
> 
> This will be much easier in my opinion.
> 
> > I noticed then that the map was cleared and rebuild twice ...
> > ... because in GuiPreferences::dispatchParams() there is first a call
> > dispatch(FuncRequest(LFUN_LYXRC_APPLY, ss.str()))
> > later followed by
> > dispatch(FuncRequest(LFUN_SCREEN_FONT_UPDATE))
> > but the first dispatch runs GuiReset() which also sends a
> > LFUN_SCREEN_FONT_UPDATE.
> > Therefore I've commented out the 2nd explicit LFUN_SCREEN_FONT_UPDATE
> > request.
> 
> Not sure about that, but things should become clearer once code is at 
> the right place.
> 
> JMarc

I've moved the code to GuiFontMetrics which is indeed much better.
Solved also a remaining issue with smallcaps.

begin 644 LyXscrollpatch20130509.diff
M1G)O;2`W9#)C.3(W,S`W,C<W93DX,#(T96,X,C0X83<X8F4U,#,Q,&5F,68V
M($UO;B!397`@,3<@,#`Z,#`Z,#`@,C`P,0I&<F]M.B!0871R:6-K($1E(%9I
M<W-C:&5R92`\<&1V:7-S8VAE<F5`961P;F5T+F)E/@I$871E.B!7960L(#$@
M36%Y(#(P,3,@,C(Z-38Z,3$@*S`R,#`*4W5B:F5C=#H@6U!!5$-(72!-;W9E
M9"!T:&4@=&5X=%=I9'1H*"D@9G)O;2!497AT365T<FEC<R!T;R!'=6E&;VYT
M365T<FEC<RP*(')E;F%M960@:70@86YD(&9I>&5D('-M86QL8V%P<RX*"BTM
M+0H@<W)C+T)U9F9E<E9I97<N8W!P("`@("`@("`@("`@("`@("`@('P@("`T
M("LM"B!S<F,O0G5F9F5R5FEE=RYH("`@("`@("`@("`@("`@("`@("`@?"`@
M(#,@*RT*('-R8R]497AT365T<FEC<RYC<'`@("`@("`@("`@("`@("`@("!\
M(#(Y,R`K*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RTM+0H@<W)C
M+U1E>'1-971R:6-S+F@@("`@("`@("`@("`@("`@("`@('P@(#$X("LK+0H@
M<W)C+V9R;VYT96YD<R]&;VYT365T<FEC<RYH("`@("`@("`@('P@("`R("L*
M('-R8R]F<F]N=&5N9',O<70T+T=U:49O;G1-971R:6-S+F-P<"!\("`T."`K
M*RLK*RL*('-R8R]F<F]N=&5N9',O<70T+T=U:49O;G1-971R:6-S+F@@("!\
M("`@-B`K"B!S<F,O9G)O;G1E;F1S+W%T-"]'=6E086EN=&5R+F-P<"`@("`@
M?"`@(#(@*PH@<W)C+V9R;VYT96YD<R]Q=#0O1W5I4')E9G,N8W!P("`@("`@
M('P@("`S("LM"B!S<F,O<F]W<&%I;G1E<BYC<'`@("`@("`@("`@("`@("`@
M("`@?"`@,S<@*RLK*RL*(#$P(&9I;&5S(&-H86YG960L(#,X-2!I;G-E'1-971R:6-S+F-P<`II
M;F1E>"`T93<P9&,P+BYD-S0Y-V(Y(#$P,#8T-`HM+2T@82]S<F,O5&5X=$UE
M=')I8W,N8W!P"BLK*R!B+W-R8R]497AT365T<FEC<RYC<'`*0$`@+30Y+#$P
M("LT.2PQ-B!`0`H@(VEN8VQU9&4@(F9R;VYT96YD<R]&;VYT365T<FEC'1U=
M<RYH(@HK"BLC:6YC;'5D92`\471'=6DO449O;G1-971R:6-S/@H@"B`C:6YC
M;'5D92`\8W-T9*(`I`0"`M,S8R+#<@*S,V."PV($!`(&)O;VP@5&5X
M=$UE=')I8W,Z.FES4E1,0F]U;F1A<GDH<<&4@<+"!P;W-?='EP
M92!P;W,L"B`)

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article <5186ae01.4080...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 05/05/13 20:36, pdv a écrit :
> >> What exactly takes 17.4s?
> >
> > I suppose that's the time taken by GuiPainter::text(), but I don't know
> > enough of the Instruments app and it's modules to give any more details.
> >
> > I've now monitored both functions with pmprof:
> > ( I scroll through a document of mine starting from the top down to the
> > same location with the down arrow key (line per line not page per page) )
> 
> A related question: will you be somewhat available during the coming 
> week? I'd like at the developers meeting (from Thursday to Sunday) to 
> start from your patch and apply it to master branch. We will probably 
> diverge significantly from what you propose but nevertheless it would be 
> useful to know whether there are times when you are available. The plan 
> is probably to set up a branch on git to work on.
> 
> JMarc

Yes, I'm available.
I've posted another version as you might already have noticed.

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article 518166ab.5070...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 01/05/2013 20:55, pdv a écrit :
  There are 2 occurences of calculate_qt_char_width, in TextMetrics and in
  RowPainter.
 
 Yes, I toggled both.
 
  and there is at least one change which is not enclosed by these
  conditionals: In TextMetrics I changed rowBreakPoint() to return the
  breakpoint as well as the width, so that the subsequent call to
  rowWidth() is not needed anymore.
 
  I'm still many  revisions behind master;
  I'll catch-up and see what I obtain with pmprof.
 
 It would be surprising that playing catch-up is enough.
 
  I've done some timing with Instruments and a testdocument;
  with calculate_qt_char_width=0 GuiPainter::text takes 17.4s
  with calculate_qt_char_width=1 GuiPainter::text takes 4.5s
 
 What exactly takes 17.4s?

I suppose that's the time taken by GuiPainter::text(), but I don't know 
enough of the Instruments app and it's modules to give any more details.

I've now monitored both functions with pmprof:
( I scroll through a document of mine starting from the top down to the 
same location with the down arrow key (line per line not page per page) )


calculate_qt_char_widths = 0
#pmprof# text: 0.04msec, count=1044047, total=45155.01msec

calculate_qt_char_widths = 1
#pmprof# text: 0.05msec, count=427662, total=21348.83msec
#pmprof# textmetrics_textwidth: 0.00msec, count=285813, total=563.34msec

text is from GuiPainter::text()
in both cases I inserted the macro at the start of the function.
Qualitatively this agrees with the Instruments timings, although the 
gain in text() is smaller and the time in TextMetrics::textWidth() is 
larger but still negligible compared to the time in GuiPainter::text().


 
  the time taken by TextMetrics::textMetrics is then 137ms
 
  Was this scrolling problem not an OS X issue?
 
 Yes, but I do not have OS X at hand. It is nevertheless important to 
 test all platforms.
 
 JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article <518166ab.5070...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 01/05/2013 20:55, pdv a écrit :
> > There are 2 occurences of calculate_qt_char_width, in TextMetrics and in
> > RowPainter.
> 
> Yes, I toggled both.
> 
> > and there is at least one change which is not enclosed by these
> > conditionals: In TextMetrics I changed rowBreakPoint() to return the
> > breakpoint as well as the width, so that the subsequent call to
> > rowWidth() is not needed anymore.
> >
> > I'm still many  revisions behind master;
> > I'll catch-up and see what I obtain with pmprof.
> 
> It would be surprising that playing catch-up is enough.
> 
> > I've done some timing with Instruments and a testdocument;
> > with calculate_qt_char_width=0 GuiPainter::text takes 17.4s
> > with calculate_qt_char_width=1 GuiPainter::text takes 4.5s
> 
> What exactly takes 17.4s?

I suppose that's the time taken by GuiPainter::text(), but I don't know 
enough of the Instruments app and it's modules to give any more details.

I've now monitored both functions with pmprof:
( I scroll through a document of mine starting from the top down to the 
same location with the down arrow key (line per line not page per page) )


calculate_qt_char_widths = 0
#pmprof# text: 0.04msec, count=1044047, total=45155.01msec

calculate_qt_char_widths = 1
#pmprof# text: 0.05msec, count=427662, total=21348.83msec
#pmprof# textmetrics_textwidth: 0.00msec, count=285813, total=563.34msec

"text" is from GuiPainter::text()
in both cases I inserted the macro at the start of the function.
Qualitatively this agrees with the Instruments timings, although the 
gain in text() is smaller and the time in TextMetrics::textWidth() is 
larger but still negligible compared to the time in GuiPainter::text().


> 
> > the time taken by TextMetrics::textMetrics is then 137ms
> >
> > Was this scrolling problem not an "OS X" issue?
> 
> Yes, but I do not have OS X at hand. It is nevertheless important to 
> test all platforms.
> 
> JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article 517fe428.8070...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 28/04/2013 13:06, pdv a écrit :
  OK, here is a new version. Let me know if you experience anymore
  problems.
  For the time being I've left the clean-up step of the map as it was,
  although I realize it's of limited value; when entering the same word
  multiple times, the partial words get included anyway;
 
 For now I only tried performance, and did not notice any problem. With 
 the attached patch I get the following numbers.
 
 The profiler only computes the time needed to recomputes the metrics. I 
 do not know what other parts should be intrumented, probably around 
 rowpainter.
 
 Experiment is to load the user's guide, go to top and press PageDown 40 
 times. The numbers are in milliseconds, 3 runs for each case.
 
 My numbers are quite noisy actually, but it seems that the cost of 
 calculate_qt_char_width is non-negligible. OTOH, I do not understand why 
 calculate_qt_char_widths=0 does not give the same numbers as master? 
 Didn't you say that it should be equivalent?

There are 2 occurences of calculate_qt_char_width, in TextMetrics and in 
RowPainter.
and there is at least one change which is not enclosed by these 
conditionals: In TextMetrics I changed rowBreakPoint() to return the 
breakpoint as well as the width, so that the subsequent call to 
rowWidth() is not needed anymore.

I'm still many  revisions behind master;
I'll catch-up and see what I obtain with pmprof.

I've done some timing with Instruments and a testdocument;
with calculate_qt_char_width=0 GuiPainter::text takes 17.4s
with calculate_qt_char_width=1 GuiPainter::text takes 4.5s
the time taken by TextMetrics::textMetrics is then 137ms

Was this scrolling problem not an OS X issue?

 
 JMarc
 
 
 Your patch with #define calculate_qt_char_widths 1
 
 #pmprof# metrics: 4.43msec, count=49, total=216.90msec
 
 #pmprof# metrics: 4.23msec, count=49, total=207.36msec
 
 #pmprof# metrics: 4.49msec, count=49, total=219.83msec
 
 
 Your patch with #define calculate_qt_char_widths 0
 
 #pmprof# metrics: 3.05msec, count=49, total=149.61msec
 
 #pmprof# metrics: 2.81msec, count=50, total=140.57msec
 
 #pmprof# metrics: 2.74msec, count=50, total=136.93msec
 
 
 Current master:
 
 #pmprof# metrics: 3.18msec, count=50, total=158.78msec
 
 #pmprof# metrics: 3.95msec, count=50, total=197.63msec
 
 #pmprof# metrics: 3.97msec, count=50, total=198.61msec
 
 
 -
 diff --git a/src/BufferView.cpp b/src/BufferView.cpp
 index 10b5263..4af1b14 100644
 --- a/src/BufferView.cpp
 +++ b/src/BufferView.cpp
 @@ -78,6 +78,7 @@
  #include support/lstrings.h
  #include support/Package.h
  #include support/types.h
 +#include support/pmprof.h
  
  #include cerrno
  #include fstream
 @@ -2574,6 +2575,7 @@ bool BufferView::singleParUpdate()
  
  void BufferView::updateMetrics()
  {
 + PROFILE_THIS_BLOCK(metrics);
   if (height_ == 0 || width_ == 0)
   return;

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article <517fe428.8070...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 28/04/2013 13:06, pdv a écrit :
> > OK, here is a new version. Let me know if you experience anymore
> > problems.
> > For the time being I've left the clean-up step of the map as it was,
> > although I realize it's of limited value; when entering the same word
> > multiple times, the partial words get included anyway;
> 
> For now I only tried performance, and did not notice any problem. With 
> the attached patch I get the following numbers.
> 
> The profiler only computes the time needed to recomputes the metrics. I 
> do not know what other parts should be intrumented, probably around 
> rowpainter.
> 
> Experiment is to load the user's guide, go to top and press PageDown 40 
> times. The numbers are in milliseconds, 3 runs for each case.
> 
> My numbers are quite noisy actually, but it seems that the cost of 
> calculate_qt_char_width is non-negligible. OTOH, I do not understand why 
> calculate_qt_char_widths=0 does not give the same numbers as master? 
> Didn't you say that it should be equivalent?

There are 2 occurences of calculate_qt_char_width, in TextMetrics and in 
RowPainter.
and there is at least one change which is not enclosed by these 
conditionals: In TextMetrics I changed rowBreakPoint() to return the 
breakpoint as well as the width, so that the subsequent call to 
rowWidth() is not needed anymore.

I'm still many  revisions behind master;
I'll catch-up and see what I obtain with pmprof.

I've done some timing with Instruments and a testdocument;
with calculate_qt_char_width=0 GuiPainter::text takes 17.4s
with calculate_qt_char_width=1 GuiPainter::text takes 4.5s
the time taken by TextMetrics::textMetrics is then 137ms

Was this scrolling problem not an "OS X" issue?

> 
> JMarc
> 
> 
> Your patch with #define calculate_qt_char_widths 1
> 
> #pmprof# metrics: 4.43msec, count=49, total=216.90msec
> 
> #pmprof# metrics: 4.23msec, count=49, total=207.36msec
> 
> #pmprof# metrics: 4.49msec, count=49, total=219.83msec
> 
> 
> Your patch with #define calculate_qt_char_widths 0
> 
> #pmprof# metrics: 3.05msec, count=49, total=149.61msec
> 
> #pmprof# metrics: 2.81msec, count=50, total=140.57msec
> 
> #pmprof# metrics: 2.74msec, count=50, total=136.93msec
> 
> 
> Current master:
> 
> #pmprof# metrics: 3.18msec, count=50, total=158.78msec
> 
> #pmprof# metrics: 3.95msec, count=50, total=197.63msec
> 
> #pmprof# metrics: 3.97msec, count=50, total=198.61msec
> 
> 
> -
> diff --git a/src/BufferView.cpp b/src/BufferView.cpp
> index 10b5263..4af1b14 100644
> --- a/src/BufferView.cpp
> +++ b/src/BufferView.cpp
> @@ -78,6 +78,7 @@
>  #include "support/lstrings.h"
>  #include "support/Package.h"
>  #include "support/types.h"
> +#include "support/pmprof.h"
>  
>  #include 
>  #include 
> @@ -2574,6 +2575,7 @@ bool BufferView::singleParUpdate()
>  
>  void BufferView::updateMetrics()
>  {
> + PROFILE_THIS_BLOCK(metrics);
>   if (height_ == 0 || width_ == 0)
>   return;
>

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article 5178e9fc.6040...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 24/04/2013 21:41, pdv:
  Why do you add 0x61 to the values?
 
  That's just for easy reading when looking at what exactly gets written
  to the map; In this way the codes are a, b, c ...
 
 That makes sense.
 
  I do not think there is a need to have a map per document. A shared map
  stored in TextLetrics should be OK (like singleWidth currently).
 
  I was worried that the map might grow out of proportion, e.g. when
  leaving the application open for a long time and since there are more
  words than characters this will be worse than for singleWidth.
 
 I would start with the simple solution and then worry about a more 
 complicated one. A shared map will take less total memory. If acces time 
 is bad, then it may be worth implementing qHash(docstring) (by aping the 
 QString version) and use a QHashdoctring, int.
 
  When typing it's unavoidable to generate all partials of a word; these
  are removed again from the map so that only the final word remains;
  However nothing is done to remedy the reverse: when deleting a word
  character by character all partials will end-up in the map;
 
  Did you do some measurement to ensure that there is a gain of doing that?
 
  I don't think it makes so much difference in time. It was merely to
  avoid filling the map with useless entries, especially if a single map
  is used.
 
 My policy in these kind of situation is to implement the simple solution 
 and do optimization only when some measurement (profiling) proved that 
 there is a problem to solve. Remember Knuth quote: Premature 
 optimization is the root of all evil (or at least most of it) in 
 programming.
 
 Do not hesitate to post patches as often as needed. While I do not have 
 time to look at the hard parts of the patch right now, I think we move 
 in the right direction.
 
 JMarc

OK, here is a new version. Let me know if you experience anymore 
problems.
For the time being I've left the clean-up step of the map as it was, 
although I realize it's of limited value; when entering the same word 
multiple times, the partial words get included anyway;

The map itself is still defined in the BufferView class, but as a shared 
static map. The reason for this is that when the user makes changes to 
the screen fonts, the map becomes useless and I think the best option is 
to clear it at that point.
I've added the case LFUN_SCREEN_FONT_UPDATE: to BufferView::dispatch() 
and added a corresponding request in GuiApplication::dispatch();

I noticed then that the map was cleared and rebuild twice ...
... because in GuiPreferences::dispatchParams() there is first a call
dispatch(FuncRequest(LFUN_LYXRC_APPLY, ss.str()))
later followed by 
dispatch(FuncRequest(LFUN_SCREEN_FONT_UPDATE))
but the first dispatch runs GuiReset() which also sends a 
LFUN_SCREEN_FONT_UPDATE.
Therefore I've commented out the 2nd explicit LFUN_SCREEN_FONT_UPDATE 
request.

Regards,

P. De Visschere

begin 644 LyXscrollpatch20130427.diff
M9EF9B`M+6=I=!A+W-R8R]=69F97)6:65W+F-P!B+W-R8R]=69F97)6
M:65W+F-P`II;F1E`S86$R,#%B+BYD8S,W.6(P(#$P,#8T-`HM+2T@82]S
MF,O0G5F9F5R5FEE=RYC'`**RLK((OW)C+T)U9F9EE9I97N8W!PD!`
M(TY-C4L-R`K.38U+#$X($!`('9O:60@0G5F9F5R5FEE=SHZ=7!D871E1]C
M=6UE;G1#;%SRA$;V-U;65N=$-L87-S0V]NW10='(@;VQD9,IB`*(`EB
M=69F97)?+F5RF]RR@B0VQAW,@4W=I=-H(BD[B!]BT**PD**R\J*B!N
M;W)M86QL2!D969I;F5D(EN;EN90HK(H)=AIR!O;F4@:7,@9F]R(1E
M8G5G9VEN9PHK(HOBL)BMS=0Z.FUA#QD;V-S=')I;FL(EN=#X@0G5F
M9F5R5FEE=SHZ=5X=%]W:61T:%\[BL)BMV;VED($)U9F9EE9I97Z.G-E
M=%1E'17:61T:AD;V-S=')I;F@8V]NW0@)B!K97DL(EN=!W*2![BL)
M=5X=%]W:61T:%];:V5Y72`]('[BL)+R]L7AEG(@/#P@(FUA'-IF4@
M/2`B(#P\('1E'1?=VED=A?+G-IF4H*2`\/`B+!K97D@/2`B(#P\(ME
M2`\/!E;F1L.PHK?0HK(\OB`*(\J*B!2971UFX@=AE(-H86YG92!S
M=%T=7,@870@8W5RV]R('!OVET:6]N+!T86MI;F@:6X@86-C;W5N=!T
M:4*(`J('-T871UR!A=!E86-H(QE=F5L(]F('1H92!D;V-U;65N=!I
M=5R871OB`H82!T86)L92!I;B!A(1E;5T960*0$`@+3$V,38L-B`K,38R
M-RPQ,!`0!V;VED($)U9F9EE9I97Z.F1IW!A=-H*$9U;F-297%U97-T
M(-O;G-T(8@8VUD+!$:7-P871C:%)EW5L=`F(1R*0H@6-AV4@3$95
M3E]30U)%14Y?4D5#14Y415(ZB`)7)E8V5N=5R*D[B`)6)R96%K.PHK
M0D)BL)8V%S92!,1E5.7U-#4D5%3E]3TY47U501$%413H**PD)=5X=%]W
M:61T:%\N8VQE87(H*3L**PD)8G)E86L[B`*(`EC87-E($Q54Y?0DE5$58
M7T1!5$%05-%7T%$1#H@PH@0E#=7)S;W(@=UP8W5R(#t...@8w5r.pid:69F
M(TM9VET($OW)C+T)U9F9EE9I97N:!B+W-R8R]=69F97)6:65W+F@*
M:6YD97@@834X9#(U,2XN-CAD93DQ82`Q,#`V-#0*+2TM($OW)C+T)U9F9E
ME9I97N:`HK*RL@8B]SF,O0G5F9F5R5FEE=RYHD!`(TQ.PQ,`K,3@L
M,3(@0$`*(-I;F-L=61E()$;V-U;65N=$-L87-S4'1R+F@BB`C:6YC;'5D
M92`B=7!D871E7V9L86=S+F@BB`**R-I;F-L=61E()S=7!P;W)T+V1O8W-T
MFEN9RYH(@H@(VEN8VQU94@(G-U'!OG0OVAAF5D7W!TBYH(@HM(VEN
M8VQU94@(G-U'!OG0OW1R9G=D+F@BB`C:6YC;'5D92`BW5P]R=]T
M7!ERYH(@H@BLC:6YC;'5D92`\;6%P/@HKB!N86UEW!A8V4@;'EX('L*
M(`H@;F%M97-P86-E('-U'!OG0@R!C;%SR!:6QE3F%M93L@?0I`0`M
M,S(P+#8@*S,R,BPQ,B!`0!P=6)L:6,ZB`)8F]O;!C;EC:V%B;5);G-E
M=@I(-O;G-T.PH@2\O+PH@79O:60@;6%K941O8W5M96YT0VQAW,H*3L*
M*PD**PDO+R\@9G5N8W1I;VYS('5S960@8GD@55X=$UE=')I8W,Z.G1E'17
M:61T:@IBL)+R\O(9OB!A8V-EW-I;F

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1) - LyXscrollpatch20130427.diff (1/1)

[pdv]

In article <5178e9fc.6040...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 24/04/2013 21:41, pdv:
> >> Why do you add 0x61 to the values?
> >
> > That's just for easy reading when looking at what exactly gets written
> > to the map; In this way the codes are a, b, c ...
> 
> That makes sense.
> 
> >> I do not think there is a need to have a map per document. A shared map
> >> stored in TextLetrics should be OK (like singleWidth currently).
> >
> > I was worried that the map might grow out of proportion, e.g. when
> > leaving the application open for a long time and since there are more
> > words than characters this will be worse than for singleWidth.
> 
> I would start with the simple solution and then worry about a more 
> complicated one. A shared map will take less total memory. If acces time 
> is bad, then it may be worth implementing qHash(docstring) (by aping the 
> QString version) and use a QHash<doctring, int>.
> 
> >>> When typing it's unavoidable to generate all partials of a word; these
> >>> are removed again from the map so that only the final word remains;
> >>> However nothing is done to remedy the reverse: when deleting a word
> >>> character by character all partials will end-up in the map;
> >>
> >> Did you do some measurement to ensure that there is a gain of doing that?
> >
> > I don't think it makes so much difference in time. It was merely to
> > avoid filling the map with useless entries, especially if a single map
> > is used.
> 
> My policy in these kind of situation is to implement the simple solution 
> and do optimization only when some measurement (profiling) proved that 
> there is a problem to solve. Remember Knuth quote: "Premature 
> optimization is the root of all evil (or at least most of it) in 
> programming."
> 
> Do not hesitate to post patches as often as needed. While I do not have 
> time to look at the hard parts of the patch right now, I think we move 
> in the right direction.
> 
> JMarc

OK, here is a new version. Let me know if you experience anymore 
problems.
For the time being I've left the clean-up step of the map as it was, 
although I realize it's of limited value; when entering the same word 
multiple times, the partial words get included anyway;

The map itself is still defined in the BufferView class, but as a shared 
static map. The reason for this is that when the user makes changes to 
the screen fonts, the map becomes useless and I think the best option is 
to clear it at that point.
I've added the case LFUN_SCREEN_FONT_UPDATE: to BufferView::dispatch() 
and added a corresponding request in GuiApplication::dispatch();

I noticed then that the map was cleared and rebuild twice ...
... because in GuiPreferences::dispatchParams() there is first a call
dispatch(FuncRequest(LFUN_LYXRC_APPLY, ss.str()))
later followed by 
dispatch(FuncRequest(LFUN_SCREEN_FONT_UPDATE))
but the first dispatch runs GuiReset() which also sends a 
LFUN_SCREEN_FONT_UPDATE.
Therefore I've commented out the 2nd explicit LFUN_SCREEN_FONT_UPDATE 
request.

Regards,

P. De Visschere

begin 644 LyXscrollpatch20130427.diff
M9`M+6=I="!A+W-R8R]"=69F97)6:65W+F-P<"!B+W-R8R]"=69F97)6
M:65W+F-P<`II;F1E>"`S86$R,#%B+BYD8S,W.6(P(#$P,#8T-`HM+2T@82]S
M<F,O0G5F9F5R5FEE=RYC<'`**RLK(&(O<W)C+T)U9F9E<E9I97<N8W!P"D!`
M("TY-C4L-R`K.38U+#$X($!`('9O:60@0G5F9F5R5FEE=SHZ=7!D871E1&]C
M=6UE;G1#;&%S<RA$;V-U;65N=$-L87-S0V]N

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article 5176c559.3030...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 21/04/2013 21:24, pdv a écrit :
  Of course, but I wanted a fully functional patch before posting.
  As far as I have tested the functionality should be largely OK now (at
  least the User's Guide and some of my documents are displayed and
  handled correctly).
  There might still be problems with the coding style ...
 
 I have compilation problems with your patch, that are solved by 
 including support/doctring.H instead of strfwd.h in BufferView.h.
 Also, one should use char_type instead of wchar_t in the code.
 
 When running the code with stdlib-debug enables, I get the assertion 
 below on user guide. There is a i + 1  end test missing around line 
 1020 of TextMetrics.cpp.

Sorry, the problem is obvious.
I'm using cmake and although --enable-stdlib-debug is mentioned in the 
install notes, I can't set that option.
Once (more or less) ready I build manually with the 
LyX-Mac-binary-release.sh script, which by default disables this option.
When I enable it, lyx crashes right away when starting. Don't know yet 
whether this signals other problems or if there is a problem with this 
option.


 
 JMarc
 
 
 /usr/include/c++/4.7/bits/basic_string.h:845: std::basic_stringChar, 
 Traits, Alloc::reference std::basic_stringChar, Traits, 
 Alloc::operator[](std::basic_stringChar, Traits, Alloc::size_type) 
 [with _CharT = wchar_t; _Traits = std::char_traitswchar_t; _Alloc = 
 std::allocatorwchar_t; std::basic_stringChar, Traits, 
 Alloc::reference = wchar_t; std::basic_stringChar, Traits, 
 Alloc::size_type = unsigned int]: Assertion '__pos  size()' failed.
 
 Program received signal SIGABRT, Aborted.
 0xb7fdd424 in __kernel_vsyscall ()
 (gdb) bt
 #0  0xb7fdd424 in __kernel_vsyscall ()
 #1  0xb6f1e1df in __GI_raise (sig=6)
  at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
 #2  0xb6f21825 in __GI_abort () at abort.c:91
 #3  0x08081d1a in std::__replacement_assert (
  __file=0x88a3f34 /usr/include/c++/4.7/bits/basic_string.h, 
 __line=845,
  __function=0x88a4aa0 std::basic_stringwchar_t, 
 std::char_traitswchar_t, std::allocatorwchar_t 
  ::operator[](unsigned int)::__PRETTY_FUNCTION__ 
 std::basic_stringChar, Traits, Alloc::reference 
 std::basic_stringChar, Traits, 
 Alloc::operator[](std::basic_stringChar, Traits, Alloc::size_type) 
 [with _CharT = wchar_t; _Traits = std::char_trai...,
  __condition=0x88a3f5d __pos  size())
  at /usr/include/c++/4.7/i686-linux-gnu/bits/c++config.h:361
 #4  0x080841a2 in std::basic_stringwchar_t, std::char_traitswchar_t, 
 std::allocatorwchar_t ::operator[] (this=0x973861c, __pos=20)
  at /usr/include/c++/4.7/bits/basic_string.h:845
 #5  0x0828d7af in lyx::Paragraph::isLineSeparator (this=0x9756658, pos=20)
  at ../../master/src/Paragraph.cpp:2994
 #6  0x082fc113 in lyx::TextMetrics::rowBreakPoint (this=0xa16b114, 
 width=628,
  pit=0, pos=0) at ../../master/src/TextMetrics.cpp:1020

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article 5176ae47.9050...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 Le 21/04/2013 21:24, pdv a écrit :
  Hereafter I've listed some comments which might be helpful or answer
  suggestions you've made earlier. (btw I couldn't find support/pmprof.h)
  If you have comments, questions ... I'm looking forward to hearing from
  you.
 
 I need some time to really understand the code. I will probably do that 
 during LDM in Milano at the beginning of May. In  the meantime, here are 
 some remarks.
 
 Some general comments:
 
 - please drop the //pdv comments, since they will eventually not be 
 necessary anymore.

I agree; this was just temporary to easily find what I did modify.

 - please add the #include directives at the right place (separate Qt 
 headers from support and frontend ones).
 
  - there are 4 functions where the textwidth must be calculated: in
  GuiPainter::text() and in 3 functions in the TextMetrics class, in order
  of complexity:
  (1) cursorX(): find the position in pixels, given the cursor position in
  characters,
  (2) rowBreakPoint(): find the next breakpoint of a row, this will always
  break between words,
  (3) getColumnNearX(): actually the reverse operation of (1); more
  complex than (2) since the position can also be located within a word.
 
  For the time being these 3 functions are still independent, although
  they are somewhat similar and maybe some more streamlining is possible
  here. I'm also aware that the code for getColumnNearX() is rather
  complex.
 
 I would think that all computation could be done in rowBreakPoint and 
 that information could be kept in some data structure, so that the other 
 methods can reuse them.
 
  The widths calculated are cached in a std::mapdocstring, int. I've
  also tried QHash but since docstring has no qhash function all strings
  must then be converted to QStrings and there is no speed gain.
 
 OK.
 
  I use only one map, the fonts are coded as a string of 4 characters
  (family, series, shape, size) which is then used as a prefix for the
  key. I have not tried alternatives like using a map for each used font.
 
 Why do you add 0x61 to the values?

That's just for easy reading when looking at what exactly gets written 
to the map; In this way the codes are a, b, c ...

 
  The map itself is stored in the BufferView class; In this way there is
  one map for each document; when storing the map in the TextMetrics
  class, multiple maps are generated. I have only tested this with simple
  documents (no child documents S).
 
 I do not think there is a need to have a map per document. A shared map 
 stored in TextLetrics should be OK (like singleWidth currently).

I was worried that the map might grow out of proportion, e.g. when 
leaving the application open for a long time and since there are more 
words than characters this will be worse than for singleWidth.


 
  When typing it's unavoidable to generate all partials of a word; these
  are removed again from the map so that only the final word remains;
  However nothing is done to remedy the reverse: when deleting a word
  character by character all partials will end-up in the map;
 
 Did you do some measurement to ensure that there is a gain of doing that?

I don't think it makes so much difference in time. It was merely to 
avoid filling the map with useless entries, especially if a single map 
is used.

Thanks for the feedback.

 
  The old code is still in place and the old painting character by
  character can be restored by changing 2 appropriate macro definitions.
 
 Thanks,
 JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article <5176c559.3030...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 21/04/2013 21:24, pdv a écrit :
> > Of course, but I wanted a fully functional patch before posting.
> > As far as I have tested the functionality should be largely OK now (at
> > least the User's Guide and some of my documents are displayed and
> > handled correctly).
> > There might still be problems with the coding style ...
> 
> I have compilation problems with your patch, that are solved by 
> including  instead of strfwd.h in BufferView.h.
> Also, one should use char_type instead of wchar_t in the code.
> 
> When running the code with stdlib-debug enables, I get the assertion 
> below on user guide. There is a "i + 1 < end" test missing around line 
> 1020 of TextMetrics.cpp.

Sorry, the problem is obvious.
I'm using cmake and although --enable-stdlib-debug is mentioned in the 
install notes, I can't set that option.
Once (more or less) ready I build manually with the 
LyX-Mac-binary-release.sh script, which by default disables this option.
When I enable it, lyx crashes right away when starting. Don't know yet 
whether this signals other problems or if there is a problem with this 
option.


> 
> JMarc
> 
> 
> /usr/include/c++/4.7/bits/basic_string.h:845: std::basic_string<Char, 
> Traits, Alloc>::reference std::basic_string<Char, Traits, 
> Alloc>::operator[](std::basic_string<Char, Traits, Alloc>::size_type) 
> [with _CharT = wchar_t; _Traits = std::char_traits; _Alloc = 
> std::allocator; std::basic_string<Char, Traits, 
> Alloc>::reference = wchar_t&; std::basic_string<Char, Traits, 
> Alloc>::size_type = unsigned int]: Assertion '__pos < size()' failed.
> 
> Program received signal SIGABRT, Aborted.
> 0xb7fdd424 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7fdd424 in __kernel_vsyscall ()
> #1  0xb6f1e1df in __GI_raise (sig=6)
>  at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2  0xb6f21825 in __GI_abort () at abort.c:91
> #3  0x08081d1a in std::__replacement_assert (
>  __file=0x88a3f34 "/usr/include/c++/4.7/bits/basic_string.h", 
> __line=845,
>  __function=0x88a4aa0 <std::basic_string<wchar_t, 
> std::char_traits, std::allocator 
>  >::operator[](unsigned int)::__PRETTY_FUNCTION__> 
> "std::basic_string<Char, Traits, Alloc>::reference 
> std::basic_string<Char, Traits, 
> Alloc>::operator[](std::basic_string<Char, Traits, Alloc>::size_type) 
> [with _CharT = wchar_t; _Traits = std::char_trai"...,
>  __condition=0x88a3f5d "__pos < size()")
>  at /usr/include/c++/4.7/i686-linux-gnu/bits/c++config.h:361
> #4  0x080841a2 in std::basic_string<wchar_t, std::char_traits, 
> std::allocator >::operator[] (this=0x973861c, __pos=20)
>  at /usr/include/c++/4.7/bits/basic_string.h:845
> #5  0x0828d7af in lyx::Paragraph::isLineSeparator (this=0x9756658, pos=20)
>  at ../../master/src/Paragraph.cpp:2994
> #6  0x082fc113 in lyx::TextMetrics::rowBreakPoint (this=0xa16b114, 
> width=628,
>  pit=0, pos=0) at ../../master/src/TextMetrics.cpp:1020

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article <5176ae47.9050...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> Le 21/04/2013 21:24, pdv a écrit :
> > Hereafter I've listed some comments which might be helpful or answer
> > suggestions you've made earlier. (btw I couldn't find support/pmprof.h)
> > If you have comments, questions ... I'm looking forward to hearing from
> > you.
> 
> I need some time to really understand the code. I will probably do that 
> during LDM in Milano at the beginning of May. In  the meantime, here are 
> some remarks.
> 
> Some general comments:
> 
> - please drop the //pdv comments, since they will eventually not be 
> necessary anymore.

I agree; this was just temporary to easily find what I did modify.

> - please add the #include directives at the right place (separate Qt 
> headers from support and frontend ones).
> 
> > - there are 4 functions where the textwidth must be calculated: in
> > GuiPainter::text() and in 3 functions in the TextMetrics class, in order
> > of complexity:
> > (1) cursorX(): find the position in pixels, given the cursor position in
> > characters,
> > (2) rowBreakPoint(): find the next breakpoint of a row, this will always
> > break between words,
> > (3) getColumnNearX(): actually the reverse operation of (1); more
> > complex than (2) since the position can also be located within a word.
> >
> > For the time being these 3 functions are still independent, although
> > they are somewhat similar and maybe some more streamlining is possible
> > here. I'm also aware that the code for getColumnNearX() is rather
> > complex.
> 
> I would think that all computation could be done in rowBreakPoint and 
> that information could be kept in some data structure, so that the other 
> methods can reuse them.
> 
> > The widths calculated are cached in a std::map<docstring, int>. I've
> > also tried QHash but since docstring has no qhash function all strings
> > must then be converted to QStrings and there is no speed gain.
> 
> OK.
> 
> > I use only one map, the fonts are coded as a string of 4 characters
> > (family, series, shape, size) which is then used as a prefix for the
> > key. I have not tried alternatives like using a map for each used font.
> 
> Why do you add 0x61 to the values?

That's just for easy reading when looking at what exactly gets written 
to the map; In this way the codes are a, b, c ...

> 
> > The map itself is stored in the BufferView class; In this way there is
> > one map for each document; when storing the map in the TextMetrics
> > class, multiple maps are generated. I have only tested this with simple
> > documents (no child documents S).
> 
> I do not think there is a need to have a map per document. A shared map 
> stored in TextLetrics should be OK (like singleWidth currently).

I was worried that the map might grow out of proportion, e.g. when 
leaving the application open for a long time and since there are more 
words than characters this will be worse than for singleWidth.


> 
> > When typing it's unavoidable to generate all partials of a word; these
> > are removed again from the map so that only the final word remains;
> > However nothing is done to remedy the reverse: when deleting a word
> > character by character all partials will end-up in the map;
> 
> Did you do some measurement to ensure that there is a gain of doing that?

I don't think it makes so much difference in time. It was merely to 
avoid filling the map with useless entries, especially if a single map 
is used.

Thanks for the feedback.

> 
> > The old code is still in place and the old painting character by
> > character can be restored by changing 2 appropriate macro definitions.
> 
> Thanks,
> JMarc

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article 516eabdf.5090...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 17/04/2013 00:05, pdv:
  I do now all the width-calculations in one function.
  In that function the widths are cached in a mapdocstring,int.
  I then obtain again a substantial speed increase.
  For testing I defined a static map, but I assume that eventually the map
  should be stored in a suitable object so that the map doesn't grow out
  of proportion.
 
 You need to keep one map for each FontInfo instance (like what is done 
 for singleWidth). I agree that may use a lot of memory. This is 
 something that can be measured using the massif tool of valgrind.
 
  So far I can handle all basic content properly. I haven't paid much
  attention to inlinecompletion (at one point it posed no problem, but I
  have to check that again), but I just discovered an issue with the
  Labeling style ...
 
 Great. If you want to do basic timing before/after, have a look at 
 support/pmprof.h.
 
 Can we see the patch?
 
 JMarc

Of course, but I wanted a fully functional patch before posting.
As far as I have tested the functionality should be largely OK now (at 
least the User's Guide and some of my documents are displayed and 
handled correctly).
There might still be problems with the coding style ...

Hereafter I've listed some comments which might be helpful or answer 
suggestions you've made earlier. (btw I couldn't find support/pmprof.h)
If you have comments, questions ... I'm looking forward to hearing from 
you.

Regards,

P. De Visschere

- there are 4 functions where the textwidth must be calculated: in 
GuiPainter::text() and in 3 functions in the TextMetrics class, in order 
of complexity:
(1) cursorX(): find the position in pixels, given the cursor position in 
characters,
(2) rowBreakPoint(): find the next breakpoint of a row, this will always 
break between words,
(3) getColumnNearX(): actually the reverse operation of (1); more 
complex than (2) since the position can also be located within a word.

For the time being these 3 functions are still independent, although 
they are somewhat similar and maybe some more streamlining is possible 
here. I'm also aware that the code for getColumnNearX() is rather 
complex.

The widths are calculated in a single TextMetrics::textWidth() function 
which accepts a parameter to cache the result or not (e.g. widths of 
partial words needed when positioning the cursor within a word are not 
cached).

The widths calculated are cached in a std::mapdocstring, int. I've 
also tried QHash but since docstring has no qhash function all strings 
must then be converted to QStrings and there is no speed gain.

I use only one map, the fonts are coded as a string of 4 characters 
(family, series, shape, size) which is then used as a prefix for the 
key. I have not tried alternatives like using a map for each used font.

The map itself is stored in the BufferView class; In this way there is 
one map for each document; when storing the map in the TextMetrics 
class, multiple maps are generated. I have only tested this with simple 
documents (no child documents Š).

When typing it's unavoidable to generate all partials of a word; these 
are removed again from the map so that only the final word remains; 
However nothing is done to remedy the reverse: when deleting a word 
character by character all partials will end-up in the map;

The old code is still in place and the old painting character by 
character can be restored by changing 2 appropriate macro definitions.

begin 644 LyXscrollpatch20130421.diff
M9EF9B`M+6=I=!A+W-R8R]=69F97)6:65W+F-P!B+W-R8R]=69F97)6
M:65W+F-P`II;F1E`S86$R,#%B+BYF,S0X,F%D(#$P,#8T-`HM+2T@82]S
MF,O0G5F9F5R5FEE=RYC'`**RLK((OW)C+T)U9F9EE9I97N8W!PD!`
M(TY-C4L-R`K.38U+#$U($!`('9O:60@0G5F9F5R5FEE=SHZ=7!D871E1]C
M=6UE;G1#;%SRA$;V-U;65N=$-L87-S0V]NW10='(@;VQD9,IB`*(`EB
M=69F97)?+F5RF]RR@B0VQAW,@4W=I=-H(BD[B!]BT**PD**R\J*B!N
M;W)M86QL2!D969I;F5D(EN;EN90HK(H)=AIR!O;F4@:7,@9F]R(1E
M8G5G9VEN9PHK(HOBMV;VED($)U9F9EE9I97Z.G-E=%1E'17:61T:AD
M;V-S=')I;F@8V]NW0@)B!K97DL(EN=!W*2![BL)=5X=%]W:61T:%];
M:V5Y72`]('[BL)+R]L7AEG(@/#P@(FUA'-IF4@/2`B(#P\('1E'1?
M=VED=A?+G-IF4H*2`\/`B+!K97D@/2`B(#P\(ME2`\/!E;F1L.PHK
M?0HK(\OB`*(\J*B!2971UFX@=AE(-H86YG92!S=%T=7,@870@8W5R
MV]R('!OVET:6]N+!T86MI;F@:6X@86-C;W5N=!T:4*(`J('-T871U
MR!A=!E86-H(QE=F5L(]F('1H92!D;V-U;65N=!I=5R871OB`H82!T
M86)L92!I;B!A(1E;5T960*9EF9B`M+6=I=!A+W-R8R]=69F97)6:65W
M+F@@8B]SF,O0G5F9F5R5FEE=RYHFEN95X($U.0R-3$N+C(Y,3(T864@
M,3`P-C0TBTM+2!A+W-R8R]=69F97)6:65W+F@**RLK((OW)C+T)U9F9E
ME9I97N:`I`0`M,C$L-B`K,C$L-R!`0`H@(VEN8VQU94@(G-U'!OG0O
MVAAF5D7W!TBYH(@H@(VEN8VQU94@(G-U'!OG0OW1R9G=D+F@BB`C
M:6YC;'5D92`BW5P]R=]T7!ERYH(@HK(VEN8VQU94@/UA#X@+R\@
M1VB`*(YA;65S%C92!L7@@PH@D!`(TS,C`L-B`K,S(Q+#$R($!`
M('!U8FQI8SH*(`EB;V]L(-L:6-K86)L94ENV5T*D@8V]NW0[B`)+R\O
MB`)=F]I9!M86ME1]C=6UE;G1#;%Sr...@i.phk0HK2\O+R!F=6YC=EO
M;G,@=7-E9!B2!497AT365TFECSHZ=5X=%=I9'1H*D**PDO+R\@9F]R
M(%C8V5SVEN9R!T:4@;6%P('=I=@@=V]R9'=I9'1HPHK6EN=!G9714
M97AT5VED=@H9]CW1R:6YG(-O

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1) - LyXscrollpatch20130421.diff (1/1)

[pdv]

In article <516eabdf.5090...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 17/04/2013 00:05, pdv:
> > I do now all the width-calculations in one function.
> > In that function the widths are cached in a map<docstring,int>.
> > I then obtain again a substantial speed increase.
> > For testing I defined a static map, but I assume that eventually the map
> > should be stored in a suitable object so that the map doesn't grow out
> > of proportion.
> 
> You need to keep one map for each FontInfo instance (like what is done 
> for singleWidth). I agree that may use a lot of memory. This is 
> something that can be measured using the massif tool of valgrind.
> 
> > So far I can handle all basic content properly. I haven't paid much
> > attention to inlinecompletion (at one point it posed no problem, but I
> > have to check that again), but I just discovered an issue with the
> > Labeling style ...
> 
> Great. If you want to do basic timing before/after, have a look at 
> support/pmprof.h.
> 
> Can we see the patch?
> 
> JMarc

Of course, but I wanted a fully functional patch before posting.
As far as I have tested the functionality should be largely OK now (at 
least the User's Guide and some of my documents are displayed and 
handled correctly).
There might still be problems with the coding style ...

Hereafter I've listed some comments which might be helpful or answer 
suggestions you've made earlier. (btw I couldn't find support/pmprof.h)
If you have comments, questions ... I'm looking forward to hearing from 
you.

Regards,

P. De Visschere

- there are 4 functions where the textwidth must be calculated: in 
GuiPainter::text() and in 3 functions in the TextMetrics class, in order 
of complexity:
(1) cursorX(): find the position in pixels, given the cursor position in 
characters,
(2) rowBreakPoint(): find the next breakpoint of a row, this will always 
break between words,
(3) getColumnNearX(): actually the reverse operation of (1); more 
complex than (2) since the position can also be located within a word.

For the time being these 3 functions are still independent, although 
they are somewhat similar and maybe some more streamlining is possible 
here. I'm also aware that the code for getColumnNearX() is rather 
complex.

The widths are calculated in a single TextMetrics::textWidth() function 
which accepts a parameter to cache the result or not (e.g. widths of 
partial words needed when positioning the cursor within a word are not 
cached).

The widths calculated are cached in a std::map<docstring, int>. I've 
also tried QHash but since docstring has no qhash function all strings 
must then be converted to QStrings and there is no speed gain.

I use only one map, the fonts are coded as a string of 4 characters 
(family, series, shape, size) which is then used as a prefix for the 
key. I have not tried alternatives like using a map for each used font.

The map itself is stored in the BufferView class; In this way there is 
one map for each document; when storing the map in the TextMetrics 
class, multiple maps are generated. I have only tested this with simple 
documents (no child documents Š).

When typing it's unavoidable to generate all partials of a word; these 
are removed again from the map so that only the final word remains; 
However nothing is done to remedy the reverse: when deleting a word 
character by character all partials will end-up in the map;

The old code is still in place and the old painting character by 
character can be restored by changing 2 appropriate macro definitions.

begin 644 LyXscrollpatch20130421.diff
M9`M+6=I="!A+W-R8R]"=69F97)6:65W+F-P<"!B+W-R8R]"=69F97)6
M:65W+F-P<`II;F1E>"`S86$R,#%B+BYF,S0X,F%D(#$P,#8T-`HM+2T@82]S
M<F,O0G5F9F5R5FEE=RYC<'`**RLK(&(O<W)C+T)U9F9E<E9I97<N8W!P"D!`
M("TY-C4L-R`K.38U+#$U($!`('9O:60@0G5F9F5R5FEE=SHZ=7!D871E1&]C
M=6UE;G1#;&%S<RA$;V-U;65N=$-L87-S0V]N

Re: Word wrapping problem

[pdv]

In article 5163d9fd.9090...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 09/04/2013 09:25, Lin Wei:
  It seems the following function decides where to break within a paragraph:
  TextMetrics.cpp:  pos_type TextMetrics::rowBreakPoint(int width,
  pit_type const pit,pos_type pos) const
 
 Yes.
 
  But still, I didn't really figure out how it works...What I'm puzzled
  about the codes is how it knows the exact breaking point as it iterates
  to then end of a row width but is still in the middle of a word. Say a
  word itshardtowrapaword is at the end of a line and the position
  iterator now pointing to 'p'. Then we find we are now at the end of the
  line, which means the whole words needs to be wrapped. How did the codes
  achieve that?
 
 As far as I understand, there is a variable named point that keeps 
 track of the last possible break point. This is what get used when the 
 algorithm realizes that one given word is too long.
 
  Becides, I think the problem of Lyx with Chinese is that it view all
  Chinese characters as just one word so long as no space/newline appears.
  A main feature of Chinese and Japanese is that they generally don't use
  any space within words or sentences. So a sentence like ***(Bob
  2010)*** would be treated as two words, **(Bob and
  2010)***, thus incorrectly wrapped if the second so-called
  word is too long.
 
 I agree with the analysis, but I do not know what the correct algorithm 
 is. There is a Qt tool for that
http://doc.qt.digia.com/4.6/qtextboundaryfinder.html
 but I am not sure that we can use it directly. It may be possible to use 
 it on strings between insets and handle insets by ourselves.
 
  BtwSorry that I don't know the convention in developing free
  software, but should I reply only to the mailing list or cc to everyone
  replied me as well?
 
 You can just answer to the list.
 
 Regards,
 JMarc

Hi Jin,

Jean-Marc drew my attention to this thread.
I'm working on another problem (the slow scrolling problem) and this 
involves also the TextMetrics::rowBreakPoint() function.

As Jean-Marc explained the function keeps track of the last breakpoint 
and then tries to add as much of the next word as possible; if there is 
still enough space the breakpoint is moved otherwise the function 
returns the last breakpoint. However if a very long word is inserted the 
function will break within that word. That's probably what happens if 
you insert chinese (without any spaces).

If there are no spaces between words, I suppose one must understand 
the meaning of the words to know where to break? Or is there another way 
to find the possible breakpoints?

Regards,

P. De Visschere

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1)

[pdv]

In article 516519f8.2070...@lyx.org,
 Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 09/04/2013 23:12, pdv:
  I've adapted rowBreakPoint() and also removed the following call to
  rowWidth(), where the same calculations are done again.
  The on screen layout is now OK, except for a small remaining issue with
  RTL-languages.
 
 Yes, we should not have several pieces of code that do the same 
 calculations. What is the data structure that you use to remember the 
 row characteristics?

I do now all the width-calculations in one function.
In that function the widths are cached in a mapdocstring,int.
I then obtain again a substantial speed increase.
For testing I defined a static map, but I assume that eventually the map 
should be stored in a suitable object so that the map doesn't grow out 
of proportion.


 
 I also notice that the inlineCompletion code is polluting the 
 TextMetrics code, I wonder why the completion string is not just 
 inserted in the paragraph and removed by the DEPM mechanism. I suspect 
 this would be cleaner.

So far I can handle all basic content properly. I haven't paid much 
attention to inlinecompletion (at one point it posed no problem, but I 
have to check that again), but I just discovered an issue with the 
Labeling style ...


 
  Unfortunately the extra time taken to calculate the correct widths in
  rowBreakPoint() eats too much of the time gained gained by avoiding
  single_character_painting and although still somewhat faster than before
  I find the scrolling speed again no longer acceptable.
 
  It looks indeed that this can only be solved by caching the widths.
 
 Yes, probably. Remember also that a bit of profiling can help. Just 
 reconfigure with --enable-build-type=prof and use Shark.app on LyX.
 
 Finally, there is probably some parallel effort from Lin Wei (look for 
 the Word wrapping problem thread) for breaking rows properly in 
 chinese/english documents. I suspect that this work will become easier 
 to get right after you have put all the word breaking code in one place.

I've posted a reply to that thread.

 
 JMarc

Re: Word wrapping problem

[pdv]

In article <5163d9fd.9090...@lyx.org>,
 Jean-Marc Lasgouttes  wrote:

> 09/04/2013 09:25, Lin Wei:
> > It seems the following function decides where to break within a paragraph:
> > TextMetrics.cpp:  pos_type TextMetrics::rowBreakPoint(int width,
> > pit_type const pit,pos_type pos) const
> 
> Yes.
> 
> > But still, I didn't really figure out how it works...What I'm puzzled
> > about the codes is how it knows the exact breaking point as it iterates
> > to then end of a row width but is still in the middle of a word. Say a
> > word "itshardtowrapaword" is at the end of a line and the position
> > iterator now pointing to 'p'. Then we find we are now at the end of the
> > line, which means the whole words needs to be wrapped. How did the codes
> > achieve that?
> 
> As far as I understand, there is a variable named "point" that keeps 
> track of the last possible break point. This is what get used when the 
> algorithm realizes that one given word is too long.
> 
> > Becides, I think the problem of Lyx with Chinese is that it view all
> > Chinese characters as just one word so long as no space/newline appears.
> > A main feature of Chinese and Japanese is that they generally don't use
> > any space within words or sentences. So a sentence like "***(Bob
> > 2010)***" would be treated as two words, "**(Bob" and
> > "2010)***", thus incorrectly wrapped if the second so-called
> > word is too long.
> 
> I agree with the analysis, but I do not know what the correct algorithm 
> is. There is a Qt tool for that
>http://doc.qt.digia.com/4.6/qtextboundaryfinder.html
> but I am not sure that we can use it directly. It may be possible to use 
> it on strings between insets and handle insets by ourselves.
> 
> > BtwSorry that I don't know the convention in developing free
> > software, but should I reply only to the mailing list or cc to everyone
> > replied me as well?
> 
> You can just answer to the list.
> 
> Regards,
> JMarc

Hi Jin,

Jean-Marc drew my attention to this thread.
I'm working on another problem (the slow scrolling problem) and this 
involves also the TextMetrics::rowBreakPoint() function.

As Jean-Marc explained the function keeps track of the last breakpoint 
and then tries to add as much of the next word as possible; if there is 
still enough space the breakpoint is moved otherwise the function 
returns the last breakpoint. However if a very long word is inserted the 
function will break within that word. That's probably what happens if 
you insert chinese (without any spaces).

If there are no spaces between words, I suppose "one" must understand 
the meaning of the words to know where to break? Or is there another way 
to find the possible breakpoints?

Regards,

P. De Visschere

Re: patch for scrolling issue - LyXscrollpatch20130302.diff (1/1)

[pdv]

In article <516519f8.2070...@lyx.org>,
 Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote:

> 09/04/2013 23:12, pdv:
> > I've adapted rowBreakPoint() and also removed the following call to
> > rowWidth(), where the same calculations are done again.
> > The on screen layout is now OK, except for a small remaining issue with
> > RTL-languages.
> 
> Yes, we should not have several pieces of code that do the same 
> calculations. What is the data structure that you use to remember the 
> row characteristics?

I do now all the width-calculations in one function.
In that function the widths are cached in a map<docstring,int>.
I then obtain again a substantial speed increase.
For testing I defined a static map, but I assume that eventually the map 
should be stored in a suitable object so that the map doesn't grow out 
of proportion.


> 
> I also notice that the inlineCompletion code is polluting the 
> TextMetrics code, I wonder why the completion string is not just 
> inserted in the paragraph and removed by the DEPM mechanism. I suspect 
> this would be cleaner.

So far I can handle all basic content properly. I haven't paid much 
attention to inlinecompletion (at one point it posed no problem, but I 
have to check that again), but I just discovered an issue with the 
Labeling style ...


> 
> > Unfortunately the extra time taken to calculate the correct widths in
> > rowBreakPoint() eats too much of the time gained gained by avoiding
> > single_character_painting and although still somewhat faster than before
> > I find the scrolling speed again no longer acceptable.
> >
> > It looks indeed that this can only be solved by caching the widths.
> 
> Yes, probably. Remember also that a bit of profiling can help. Just 
> reconfigure with --enable-build-type=prof and use Shark.app on LyX.
> 
> Finally, there is probably some parallel effort from Lin Wei (look for 
> the "Word wrapping problem" thread) for breaking rows properly in 
> chinese/english documents. I suspect that this work will become easier 
> to get right after you have put all the word breaking code in one place.

I've posted a reply to that thread.

> 
> JMarc