Re: Review Request 123735: version of QmlObject with a static engine
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/#review80755 --- Ship it! ...in 10 days Great work on all this. - David Edmundson On May 21, 2015, 4:02 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123735/ --- (Updated May 21, 2015, 4:02 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- to make easier doing applications like plasma that use a lot of qml to have a single engine make a subclass of QmlObject called QmlObjectSharedEngine that has a single, static QQmlEngine Adds a class called QuickViewSharedEngine that has the same behavior as QmlObjectSharedEngine(using it): static QQmlEngine, separed rootContexts() for each instance. This is used by desktopviews and panelviews to share their engine. Unfortunately it may not be possible to get the applet configuration dialogs to use this, since they still need a separed engine in order to have a different controls style (qstyle based) than the stuff in the desktop/panel Diffs - autotests/CMakeLists.txt adc1102 autotests/quickviewsharedengine.cpp PRE-CREATION autotests/util.h PRE-CREATION autotests/util.cpp PRE-CREATION src/kdeclarative/CMakeLists.txt d73bff0 src/kdeclarative/kdeclarative.cpp b3906e2 src/kdeclarative/qmlobject.h f26b67d src/kdeclarative/qmlobject.cpp c483665 src/kdeclarative/qmlobjectsharedengine.h PRE-CREATION src/kdeclarative/qmlobjectsharedengine.cpp PRE-CREATION src/quickaddons/CMakeLists.txt 777d07c src/quickaddons/quickviewsharedengine.h PRE-CREATION src/quickaddons/quickviewsharedengine.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/123735/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: ktexteditor master kf5-qt5 » OSX,clang - Build # 5 - Still Failing!
Check console output at https://build.kde.org/job/ktexteditor%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/5/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins-kde-ci: ktexteditor master kf5-qt5 » OSX,clang - Build # 4 - Failure!
Check console output at https://build.kde.org/job/ktexteditor%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/4/ to view the results. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org wrote:
Sorry for the extensive cross-posting in advance, please when replying, do a
reply-all.
Just so everyone is on the same page: Vc is a template library that makes it
easy to build vectorized code using a single source file. Krita uses Vc to
optimize blending colors, creating masks and much more. Krita uses the most
recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc handle
include directories is a big roadblock for us:
https://git.reviewboard.kde.org/r/123179/ .
In a nutshell: Vc builds many different object files from single cpp file.
It does this by creating a custom command for each target vectorization
extension. To do that, it needs to access the contents of
INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7)
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
In the end the command is generated like this:
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
-DVC_IMPL=${_impl}
${_outfile_flag}${_out}
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
IMPLICIT_DEPENDS CXX
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
COMMENT Building CXX object ${_out}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
VERBATIM
)
KF5 uses cmake generator expressions to derive the include directories from
the target_link_libraries lines. This means that when we try to build our
per-extensions object files we get this:
[ 0%] Building CXX object
KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment /usr/bin/c++ -std=c++0x
-fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor
-Woverloaded-virtual -Werror=return-type -D__GNUC_UBUNTU_VERSION__=0xf040a
-Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/koplugin
-I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/pigment
-I/home/boud/kde/src/calligra/libs/pigment/compositeops
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
-I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX -c
-oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
fatal error: QString: No such file or directory
#include QString
^
compilation terminated.
libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for target
'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to be
found.
If we manually set include directories like this:
if (HAVE_VC)
message(. ${KDE4_INCLUDES})
include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
${Boost_INCLUDE_DIR})
endif()
We end up with the entire include line for the contents of KDE4_INCLUDES
($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
expanded to a string with quotes around it:
[ 0%] Building CXX object KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment /usr/bin/c++ -std=c++0x
-fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor
-Woverloaded-virtual -Werror=return-type -D__GNUC_UBUNTU_VERSION__=0xf040a
-Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
Re: Review Request 123341: Optimize reading Sonnet settings by minimizing the cals to save()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123341/ --- (Updated May 23, 2015, 3:20 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Laurent Montel and Martin Tobias Holmedahl Sandsmark. Changes --- Submitted with commit 28f74f1d4c6c0331df957463381d2f2b8936a801 by Kåre Särs to branch master. Repository: sonnet Description --- The curent implementation can causes ~25 cals to Settings::save() for every created Speller instance. The Settings::restore() function ends with setQuietIgnoreList(...) which would call save() for evey ignore-word. This patch removes the save() cals in the setFoo() functions of Settings and replace it by a boolean that indicates if the settign is changed or not. Then in the Speller class save() is called when needed. The reason for this patch is that it took Kate ~2 minutes to open a kate session with ~340 files. The implementation in Kate called reload() for every file. There is a RR for Kate to remove that unneeded reload. This patch also prepares Sonnet::Settings for being used in the public API to set aplication specific Sonnet settings without saving them in the global settings. The Settings class is exported but the header is private. This change is BIC, but since the class is private, my interpretation is that it should not mater. If accepted I will also add a Review Request to make the Settings class public to enable application specific settings. Diffs - autotests/CMakeLists.txt 8ade413 autotests/test_settings.h PRE-CREATION autotests/test_settings.cpp PRE-CREATION src/core/settings.cpp b5c4198 src/core/settings_p.h 0d48889 src/core/speller.cpp 3903b42 src/ui/configwidget.cpp 02f2a26 Diff: https://git.reviewboard.kde.org/r/123341/diff/ Testing --- Tested with Kate and with the patch the startup time was back to normal. Two unit tests added. Thanks, Kåre Särs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem using Vc with CMake 3.0 and kf5
I'm not sure if I understood the issue. If we need to pass the -I
parameters to vc_compile_for_all_implementations, then something like
https://git.reviewboard.kde.org/r/115110/diff/1/ might work.
Em 23/05/2015 09:07, Aleix Pol aleix...@kde.org escreveu:
On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org
wrote:
Sorry for the extensive cross-posting in advance, please when replying,
do a
reply-all.
Just so everyone is on the same page: Vc is a template library that
makes it
easy to build vectorized code using a single source file. Krita uses Vc
to
optimize blending colors, creating masks and much more. Krita uses the
most
recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc
handle
include directories is a big roadblock for us:
https://git.reviewboard.kde.org/r/123179/ .
In a nutshell: Vc builds many different object files from single cpp
file.
It does this by creating a custom command for each target vectorization
extension. To do that, it needs to access the contents of
INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7
)
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
In the end the command is generated like this:
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
-DVC_IMPL=${_impl}
${_outfile_flag}${_out}
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
MAIN_DEPENDENCY
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
IMPLICIT_DEPENDS CXX
${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
COMMENT Building CXX object ${_out}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
VERBATIM
)
KF5 uses cmake generator expressions to derive the include directories
from
the target_link_libraries lines. This means that when we try to build our
per-extensions object files we get this:
[ 0%] Building CXX object
KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment /usr/bin/c++
-std=c++0x
-fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wnon-virtual-dtor
-Woverloaded-virtual -Werror=return-type
-D__GNUC_UBUNTU_VERSION__=0xf040a
-Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/koplugin
-I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/pigment
-I/home/boud/kde/src/calligra/libs/pigment/compositeops
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
-I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
-c
-oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
fatal error: QString: No such file or directory
#include QString
^
compilation terminated.
libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
target
'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to
be
found.
If we manually set include directories like this:
if (HAVE_VC)
message(. ${KDE4_INCLUDES})
include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
${Boost_INCLUDE_DIR})
endif()
We end up with the entire include line for the contents of KDE4_INCLUDES
($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
expanded to a string with quotes around it:
[ 0%] Building CXX object
KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
cd /home/boud/kde/build/calligra/libs/pigment /usr/bin/c++
-std=c++0x
-fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wnon-virtual-dtor
-Woverloaded-virtual -Werror=return-type
-D__GNUC_UBUNTU_VERSION__=0xf040a
-Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
Review Request 123890: Don't show KDE Frameworks version in the About KDE dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123890/ --- Review request for KDE Frameworks. Repository: kxmlgui Description --- Doesn't make sense, if you want to know which frameworks version you're using you can use the application dialog version, this is about kde, and as such it's about the community, the frameworks version there matters nothing Diffs - src/kaboutkdedialog_p.cpp 1c3539b Diff: https://git.reviewboard.kde.org/r/123890/diff/ Testing --- Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KEncodingProber vs unexisting codecs
One of the codecs that KEncodingProber can return is x-euc-tw But neither the Qt4 nor the Qt5 installed in my distribution understand that codec, so doing the suggested QTextCodec::codecForName(prober.encoding())-toUnicode(data); Will crash. Not good. Two ways to fix this that i can think of: * Go through all the probers and remove the ones that don't exist in Qt * On runtime when creating the prober check if Qt understands it before testing if the data matches it The first is defenitely faster on execution time but is also less versatile and i don't know enough about QTextCoded internals to be sure all the codecs that are available in my ditro are available on distro X and viceversa, so maybe option 2 is better. Opinions and comments before i start implementing? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123852: Optimize: Do not wipe dict cache when copying speller objects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123852/#review80761 --- Ship it! Seems good for me. Ship it - Laurent Montel On mai 19, 2015, 9:49 matin, Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123852/ --- (Updated mai 19, 2015, 9:49 matin) Review request for KDE Frameworks, Laurent Montel, Martin Tobias Holmedahl Sandsmark, and Kåre Särs. Repository: sonnet Description --- This removes a serious performance penalty from enabling on-the-fly spell checking in KTextEditor. For some reason, the copy assignment of a Speller object invalidated the internal cache which happened very often from the Kate code base. Now, the cache is kept valid and reused, and the performance is good again. I'm not sure whether this has any unintentional side-effects, but the tests work fine and spell checking in KatePart still looks good as well, and is now fast again. E.g. previously I easily ended up with heaptrack reports such as this one: 2284529 calls to allocation functions with 16.23MB peak consumption from HashMgr::add_word(char const*, int, int, unsigned short*, int, char const*, bool) in /usr/lib/libhunspell-1.3.so.0 1978045 calls with 2.30MB peak consumption from: HashMgr::load_tables(char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HashMgr::HashMgr(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 Hunspell::Hunspell(char const*, char const*, char const*) in /usr/lib/libhunspell-1.3.so.0 HunspellDict at .../sonnet/src/plugins/hunspell/hunspelldict.cpp:36 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so HunspellClient::createSpeller(QString const) at .../sonnet/src/plugins/hunspell/hunspellclient.cpp:43 in /home/milian/projects/compiled/kf5/lib64/plugins/kf5/sonnet/hunspell.so Sonnet::Loader::createSpeller(QString const, QString const) const at .../sonnet/src/core/loader.cpp:103 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::updateDict() at .../sonnet/src/core/speller.cpp:64 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::Private::recreateDict() at .../sonnet/src/core/speller.cpp:79 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::Speller::operator=(Sonnet::Speller const) at .../sonnet/src/core/speller.cpp:111 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 Sonnet::BackgroundChecker::setSpeller(Sonnet::Speller const) at .../sonnet/src/core/backgroundchecker.cpp:131 in /home/milian/projects/compiled/kf5/lib64/libKF5SonnetCore.so.5 KateOnTheFlyChecker::performSpellCheck() at .../ktexteditor/src/spellcheck/ontheflycheck.cpp:405 in /home/milian/projects/compiled/kf5/lib64/libKF5TextEditor.so.5 Diffs - src/core/speller.cpp 3903b42ebb4f7cb98a049fcf7a291c74dd9457e0 Diff: https://git.reviewboard.kde.org/r/123852/diff/ Testing --- Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
