Re: Undefined references to Attica
On 20/02/14 06:56, Adrián Chaves Fernández wrote: I was trying to build frameworks 4.96.0, and I run into trouble compiling the tests for KXmlGui, due to undefined references to Attica. I did this to solve it: https://git.reviewboard.kde.org/r/115907/diff/ Now, on the next package, KBookmarks, I again get undefined references to Attica (from the KXmlGui shared library) when building the tests. Am I missing something here? I'm starting to think the issue is with my personal configuration and not with the packages themselves. Odd; that shouldn't be happening. What system are you building on? Also, `make VERBOSE=1` can be a helpful debugging tool; I could imagine maybe getting errors like this if you are doing static builds. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Sprint from 24th of April until 28th
On Wednesday 19 February 2014 18:20:21 you wrote: We finally have a date for the sprint, next step is to know how many people need sponsoring, so please register yourself here: https://sprints.kde.org/sprint/224 I want to send the budget somewhere next week so please, hurry! Thanks ! Remember that you have to put as well your travel expenses (flight, train, bus...) so we can request the budget to the KDE e.V Thanks ! signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
On Feb. 19, 2014, 3:21 p.m., Alex Merry wrote:
CMakeLists.txt, lines 23-32
https://git.reviewboard.kde.org/r/115863/diff/1/?file=244733#file244733line23
KCompletion, KConfig[Widgets] and KCoreAddons are used, but never
linked against. So there's not much point searching for them: we're
already depending on them being bought in by other libraries.
Michael Palimaka wrote:
The listed frameworks are directly used. I don't see how linking or not
makes a difference - khtml will fail to build without them. If we trust that
one dependency will always bring in some other dependencies that we happen to
also use, I am sure there are others we could remove too.
Alex Merry wrote:
Well, my view is that you can either find them and link against them
(explicit dependencies), or not find or link against them (implicitly trust
that the libraries you *do* link against bring them in). Finding them and
not linking against them just seems a bit pointless.
A dependency can still be explicit even though a binary link isn't required,
for example:
src/rendering/render_form.cpp:#include kservice.h
src/rendering/render_form.cpp:KService::List providers =
KServiceTypeTrader::self()-query(SearchProvider);
src/rendering/render_form.cpp:foreach (const KService::Ptr
provider, providers) {
If you feel that strongly about it though, I'll drop those changes. They
additions don't affect me at all, I just was aiming for a 'correct' change
since I was touching this framework anyway.
- Michael
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/#review50260
---
On Feb. 18, 2014, 8:01 a.m., Michael Palimaka wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/
---
(Updated Feb. 18, 2014, 8:01 a.m.)
Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.
Repository: khtml
Description
---
- QtTest is only required for autotests
- QtX11Extras is only required for X11 builds, and for tests
- Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are
not used
Diffs
-
CMakeLists.txt 3a3dbab90e6572cf953ba5edc1fcb60a7e30b493
autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da
tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a
Diff: https://git.reviewboard.kde.org/r/115863/diff/
Testing
---
Builds. Tests pass.
Thanks,
Michael Palimaka
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114997: Improve KAuth README.md
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114997/#review50335 --- Ship it! Ship It! - Kevin Ottens On Jan. 28, 2014, 11:48 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114997/ --- (Updated Jan. 28, 2014, 11:48 a.m.) Review request for KDE Frameworks and Dario Freddi. Repository: kauth Description --- Improve KAuth README.md Diffs - README.md a8a011a147d2dcc0fb5db39e263412005a86def4 Diff: https://git.reviewboard.kde.org/r/114997/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114997: Improve KAuth README.md
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114997/ --- (Updated Feb. 20, 2014, 12:07 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Dario Freddi. Repository: kauth Description --- Improve KAuth README.md Diffs - README.md a8a011a147d2dcc0fb5db39e263412005a86def4 Diff: https://git.reviewboard.kde.org/r/114997/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114987: khtml and other components from frameworks should use kde5_install , remove kde4 refs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114987/ --- (Updated Feb. 20, 2014, 12:09 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: khtml Description --- khtml and other components from frameworks should use kde5_install , remove kde4 refs Diffs - tests/pics/CMakeLists.txt 3d2f8d5 Diff: https://git.reviewboard.kde.org/r/114987/diff/ Testing --- None Thanks, Siddharth Sharma ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114989: kapidox and other components from frameworks should use kde5-config instead of kde4-config, remove kde4 references
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114989/ --- (Updated Feb. 20, 2014, 12:10 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kapidox Description --- kapidox and other components from frameworks should use kde5-config instead of kde4-config, remove kde4 references Diffs - src/doxygen-preprocess-kcfg.sh 567a248 Diff: https://git.reviewboard.kde.org/r/114989/diff/ Testing --- Thanks, Siddharth Sharma ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
On Feb. 19, 2014, 3:21 p.m., Alex Merry wrote:
CMakeLists.txt, lines 23-32
https://git.reviewboard.kde.org/r/115863/diff/1/?file=244733#file244733line23
KCompletion, KConfig[Widgets] and KCoreAddons are used, but never
linked against. So there's not much point searching for them: we're
already depending on them being bought in by other libraries.
Michael Palimaka wrote:
The listed frameworks are directly used. I don't see how linking or not
makes a difference - khtml will fail to build without them. If we trust that
one dependency will always bring in some other dependencies that we happen to
also use, I am sure there are others we could remove too.
Alex Merry wrote:
Well, my view is that you can either find them and link against them
(explicit dependencies), or not find or link against them (implicitly trust
that the libraries you *do* link against bring them in). Finding them and
not linking against them just seems a bit pointless.
Michael Palimaka wrote:
A dependency can still be explicit even though a binary link isn't
required, for example:
src/rendering/render_form.cpp:#include kservice.h
src/rendering/render_form.cpp:KService::List providers =
KServiceTypeTrader::self()-query(SearchProvider);
src/rendering/render_form.cpp:foreach (const KService::Ptr
provider, providers) {
If you feel that strongly about it though, I'll drop those changes. They
additions don't affect me at all, I just was aiming for a 'correct' change
since I was touching this framework anyway.
Alex Merry wrote:
Yes, but this code won't work unless you link against KF5::Service,
either explicitly or implicitly. If it's explicit, you should also have
find_package(KF5Service). If it's implicit, you're depending on one of your
explicit dependencies including KF5::Service in its link interface anyway, in
which case that dependency will also pull in the KF5Service package.
I mean, in the end it doesn't matter that much. I'm not going to say
don't ship it unless you do this. But I think that searching for packages
in CMake and then not making any use of those packages in CMake (even if it
doesn't make any difference to whether the package is required) just clutters
things up unnecessarily.
Sorry, I just realised I misunderstood your original comment. The final product
does actually link to KCompletion etc. but indeed they are not explicitly
marked that way. I guess for the case of KCompletion the link is happening
anyway because it is a public dependency of KTextWidgets.
- Michael
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/#review50260
---
On Feb. 18, 2014, 8:01 a.m., Michael Palimaka wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/
---
(Updated Feb. 18, 2014, 8:01 a.m.)
Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.
Repository: khtml
Description
---
- QtTest is only required for autotests
- QtX11Extras is only required for X11 builds, and for tests
- Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are
not used
Diffs
-
CMakeLists.txt 3a3dbab90e6572cf953ba5edc1fcb60a7e30b493
autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da
tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a
Diff: https://git.reviewboard.kde.org/r/115863/diff/
Testing
---
Builds. Tests pass.
Thanks,
Michael Palimaka
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/#review50341 --- autotests/CMakeLists.txt https://git.reviewboard.kde.org/r/115504/#comment35416 Didn't you mean if (BUILD_EPS_PLUGIN) ? This line confuses me. :-) - Kevin Ottens On Feb. 5, 2014, 5:41 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 5, 2014, 5:41 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 2b88843e677163d8229d2a3b9055a540f7fb5961 autotests/CMakeLists.txt 0192636c3617bf37264a3895e61ecd837e228c4a src/imageformats/CMakeLists.txt 242753e0b2c493bbf1da9654967494415e8249d8 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115752: Change DATA_INSTALL_DIR on Mac OS X
On Feb. 15, 2014, 3:51 p.m., Alexander Richardson wrote: Same Problem on Windows: https://git.reviewboard.kde.org/r/115210/ Further discussion needed I guess I'd propose the discussion to be started on list then. Once the discussion is started this patch can be discarded until we reach a consensus and implement it. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115752/#review49837 --- On Feb. 14, 2014, 6:49 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115752/ --- (Updated Feb. 14, 2014, 6:49 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Let it point to ~/Library/Application Support as that is what QStandardPaths expects This is actually a tricky one - I'd rather have $HOMEBREW_PREFIX/share as data path, but Qt only reports ~/Library/Application\ Support So - do we add some magic to Qt to allow user-configurable extra data dirs (juck), implement our own magic (juck), or just change the DATA_INSTALL_DIR to ~/Library/Application\ Support? Diffs - kde-modules/KDEInstallDirs.cmake 9ff23540f00a2794b1ebd842656c3d61b047a500 Diff: https://git.reviewboard.kde.org/r/115752/diff/ Testing --- Tested with homebrew tap at https://github.com/haraldF/homebrew-kf5 Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
On Feb. 19, 2014, 3:21 p.m., Alex Merry wrote:
CMakeLists.txt, lines 23-32
https://git.reviewboard.kde.org/r/115863/diff/1/?file=244733#file244733line23
KCompletion, KConfig[Widgets] and KCoreAddons are used, but never
linked against. So there's not much point searching for them: we're
already depending on them being bought in by other libraries.
Michael Palimaka wrote:
The listed frameworks are directly used. I don't see how linking or not
makes a difference - khtml will fail to build without them. If we trust that
one dependency will always bring in some other dependencies that we happen to
also use, I am sure there are others we could remove too.
Alex Merry wrote:
Well, my view is that you can either find them and link against them
(explicit dependencies), or not find or link against them (implicitly trust
that the libraries you *do* link against bring them in). Finding them and
not linking against them just seems a bit pointless.
Michael Palimaka wrote:
A dependency can still be explicit even though a binary link isn't
required, for example:
src/rendering/render_form.cpp:#include kservice.h
src/rendering/render_form.cpp:KService::List providers =
KServiceTypeTrader::self()-query(SearchProvider);
src/rendering/render_form.cpp:foreach (const KService::Ptr
provider, providers) {
If you feel that strongly about it though, I'll drop those changes. They
additions don't affect me at all, I just was aiming for a 'correct' change
since I was touching this framework anyway.
Alex Merry wrote:
Yes, but this code won't work unless you link against KF5::Service,
either explicitly or implicitly. If it's explicit, you should also have
find_package(KF5Service). If it's implicit, you're depending on one of your
explicit dependencies including KF5::Service in its link interface anyway, in
which case that dependency will also pull in the KF5Service package.
I mean, in the end it doesn't matter that much. I'm not going to say
don't ship it unless you do this. But I think that searching for packages
in CMake and then not making any use of those packages in CMake (even if it
doesn't make any difference to whether the package is required) just clutters
things up unnecessarily.
Michael Palimaka wrote:
Sorry, I just realised I misunderstood your original comment. The final
product does actually link to KCompletion etc. but indeed they are not
explicitly marked that way. I guess for the case of KCompletion the link is
happening anyway because it is a public dependency of KTextWidgets.
Yes, that's exactly it. Sorry for not being clearer.
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/#review50260
---
On Feb. 18, 2014, 8:01 a.m., Michael Palimaka wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/
---
(Updated Feb. 18, 2014, 8:01 a.m.)
Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.
Repository: khtml
Description
---
- QtTest is only required for autotests
- QtX11Extras is only required for X11 builds, and for tests
- Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are
not used
Diffs
-
CMakeLists.txt 3a3dbab90e6572cf953ba5edc1fcb60a7e30b493
autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da
tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a
Diff: https://git.reviewboard.kde.org/r/115863/diff/
Testing
---
Builds. Tests pass.
Thanks,
Michael Palimaka
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115897: Remove FindDocBook*.cmake
On Feb. 19, 2014, 12:52 p.m., Luigi Toscano wrote: Uhm, well, not sure about the non-usage in kde4support: I would like to make sure that the needed files (4.2) are really there, so I would like to call FindDocBookXML4 for that. Alex Merry wrote: Oh, I see, it's going to look for a different version to kdoctools, right? Luigi Toscano wrote: Yes, I was not clear on that: the final plan is to use 4.5 for KDocTools and keep compatibility files and 4.2 in kde4support, to allow for a smooth transition. Luigi Toscano wrote: ... does it mean we are going to keep the modules in ECM? :) Alex Merry wrote: I'd still rather not have such a niche find-module in ECM; I guess it really depends on how much we want to avoid duplicating things in the compatibility module (kde4support). I've added David and Kevin to the RR to see if they have any input. Please note that the common FindDocBookXML is not the current version, but the one in this review request: https://git.reviewboard.kde.org/r/115876/ Also, the version in 115876 will be changed by removing the compatibility variables, which were not used outside kdelibs and need to be fixed only in Frameworks. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/#review50220 --- On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/ --- (Updated Feb. 19, 2014, 11:45 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, David Faure, Kevin Ottens, and Luigi Toscano. Repository: extra-cmake-modules Description --- Remove FindDocBook*.cmake These are only really useful to kdoctools, so they may as well live there. (NB: after looking at how kdoctools uses the information from these files, I suspect they won't even be needed for the compatibility macros that are intended to end up in kde4support). Diffs - find-modules/FindDocBookXML.cmake b6d623e4e5ca40cdda4c895a19a0dc273831703a find-modules/FindDocBookXSL.cmake a7320aed66b72c92f0286658e38b7fc32266790c Diff: https://git.reviewboard.kde.org/r/115897/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review50347 --- Please address David's comments, I think this patch is interesting and shouldn't stay in limbo too long. - Kevin Ottens On Feb. 12, 2014, 11:28 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 12, 2014, 11:28 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
On Feb. 19, 2014, 3:21 p.m., Alex Merry wrote:
CMakeLists.txt, lines 23-32
https://git.reviewboard.kde.org/r/115863/diff/1/?file=244733#file244733line23
KCompletion, KConfig[Widgets] and KCoreAddons are used, but never
linked against. So there's not much point searching for them: we're
already depending on them being bought in by other libraries.
Michael Palimaka wrote:
The listed frameworks are directly used. I don't see how linking or not
makes a difference - khtml will fail to build without them. If we trust that
one dependency will always bring in some other dependencies that we happen to
also use, I am sure there are others we could remove too.
Alex Merry wrote:
Well, my view is that you can either find them and link against them
(explicit dependencies), or not find or link against them (implicitly trust
that the libraries you *do* link against bring them in). Finding them and
not linking against them just seems a bit pointless.
Michael Palimaka wrote:
A dependency can still be explicit even though a binary link isn't
required, for example:
src/rendering/render_form.cpp:#include kservice.h
src/rendering/render_form.cpp:KService::List providers =
KServiceTypeTrader::self()-query(SearchProvider);
src/rendering/render_form.cpp:foreach (const KService::Ptr
provider, providers) {
If you feel that strongly about it though, I'll drop those changes. They
additions don't affect me at all, I just was aiming for a 'correct' change
since I was touching this framework anyway.
Alex Merry wrote:
Yes, but this code won't work unless you link against KF5::Service,
either explicitly or implicitly. If it's explicit, you should also have
find_package(KF5Service). If it's implicit, you're depending on one of your
explicit dependencies including KF5::Service in its link interface anyway, in
which case that dependency will also pull in the KF5Service package.
I mean, in the end it doesn't matter that much. I'm not going to say
don't ship it unless you do this. But I think that searching for packages
in CMake and then not making any use of those packages in CMake (even if it
doesn't make any difference to whether the package is required) just clutters
things up unnecessarily.
Michael Palimaka wrote:
Sorry, I just realised I misunderstood your original comment. The final
product does actually link to KCompletion etc. but indeed they are not
explicitly marked that way. I guess for the case of KCompletion the link is
happening anyway because it is a public dependency of KTextWidgets.
Alex Merry wrote:
Yes, that's exactly it. Sorry for not being clearer.
So, should the explicit link be added, or just forget about it for now? :-)
- Michael
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/#review50260
---
On Feb. 18, 2014, 8:01 a.m., Michael Palimaka wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115863/
---
(Updated Feb. 18, 2014, 8:01 a.m.)
Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.
Repository: khtml
Description
---
- QtTest is only required for autotests
- QtX11Extras is only required for X11 builds, and for tests
- Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are
not used
Diffs
-
CMakeLists.txt 3a3dbab90e6572cf953ba5edc1fcb60a7e30b493
autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da
tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a
Diff: https://git.reviewboard.kde.org/r/115863/diff/
Testing
---
Builds. Tests pass.
Thanks,
Michael Palimaka
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115909: Remove unused dependency from krunner
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115909/ --- Review request for KDE Frameworks. Repository: krunner Description --- There does not appear to be any actual KCompletion usage, so remove it. Diffs - src/runnercontext.cpp 8b7461459ead6ff8c18549531f1b5c9baf1df3fa CMakeLists.txt ebae16d0610c5c53aac34e9134db5d4b0e47903b src/CMakeLists.txt 0f8221fc175f51da32a5abcc96bdeca2c9b0e17b src/abstractrunner.h cee292812075db59c13703de37dc1e983c3d8968 src/runnercontext.h c6441b7a1bb92df5549d26f45183c1ff7ce157e6 Diff: https://git.reviewboard.kde.org/r/115909/diff/ Testing --- Builds. Tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
On Feb. 20, 2014, 12:14 p.m., Kevin Ottens wrote: autotests/CMakeLists.txt, line 82 https://git.reviewboard.kde.org/r/115504/diff/1/?file=242132#file242132line82 Didn't you mean if (BUILD_EPS_PLUGIN) ? This line confuses me. :-) Hmm... it is a little non-obvious, now you mention it. It is disabled for the reason mentioned in the comment above it; perhaps it would be clearer if I just commented out those lines. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/#review50341 --- On Feb. 5, 2014, 5:41 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 5, 2014, 5:41 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 2b88843e677163d8229d2a3b9055a540f7fb5961 autotests/CMakeLists.txt 0192636c3617bf37264a3895e61ecd837e228c4a src/imageformats/CMakeLists.txt 242753e0b2c493bbf1da9654967494415e8249d8 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 20, 2014, 12:38 p.m.) Review request for KDE Frameworks. Changes --- Comment out broken tests, instead of using if(FALSE) Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs (updated) - CMakeLists.txt 8a24fd3600ef18a4e9992660c8637af6ed8f9ddc autotests/CMakeLists.txt bedc3ad451128365699ec8f1392c68993934453b src/imageformats/CMakeLists.txt 7cafd18105a7219a9c761193012f87625f74d995 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/#review50361 --- This review has been submitted with commit 4fbbc75429597dc545ae8af24e870d9bac5f2f2a by Alex Merry to branch master. - Commit Hook On Feb. 16, 2014, 12:14 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- (Updated Feb. 16, 2014, 12:14 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- WebP: use Q_DECL_OVERRIDE In doing so, found a method that should not have been overridden, and so removed it. WebP: remove unused include Make WebP mimetype xml match the one in shared-mime-info-git This includes the detection magic and an alias for image/webp. It should be in shared-mime-info 1.3. Proposed by Jerome Leclanche adys...@gmail.com. Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Autotests are generated using the cwebp and dwebp utilities distributed with the libwebp reference library. Diffs - src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION cmake/FindWebP.cmake PRE-CREATION autotests/read/webp/rgb-cwebp.webp PRE-CREATION autotests/read/webp/rgb-cwebp.png PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.webp PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.png PRE-CREATION autotests/read/webp/bw-cwebp.webp PRE-CREATION autotests/read/webp/bw-cwebp.png PRE-CREATION autotests/read/webp/bw-cwebp-lossless.webp PRE-CREATION autotests/read/webp/bw-cwebp-lossless.png PRE-CREATION autotests/CMakeLists.txt bedc3ad451128365699ec8f1392c68993934453b src/imageformats/webp.h PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.cpp PRE-CREATION src/imageformats/CMakeLists.txt 7cafd18105a7219a9c761193012f87625f74d995 Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; autotests run Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/#review50359 --- This review has been submitted with commit 30cff602964dd47379d8a7161768183fe4a64f19 by Alex Merry to branch master. - Commit Hook On Feb. 16, 2014, 12:14 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- (Updated Feb. 16, 2014, 12:14 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- WebP: use Q_DECL_OVERRIDE In doing so, found a method that should not have been overridden, and so removed it. WebP: remove unused include Make WebP mimetype xml match the one in shared-mime-info-git This includes the detection magic and an alias for image/webp. It should be in shared-mime-info 1.3. Proposed by Jerome Leclanche adys...@gmail.com. Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Autotests are generated using the cwebp and dwebp utilities distributed with the libwebp reference library. Diffs - src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION cmake/FindWebP.cmake PRE-CREATION autotests/read/webp/rgb-cwebp.webp PRE-CREATION autotests/read/webp/rgb-cwebp.png PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.webp PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.png PRE-CREATION autotests/read/webp/bw-cwebp.webp PRE-CREATION autotests/read/webp/bw-cwebp.png PRE-CREATION autotests/read/webp/bw-cwebp-lossless.webp PRE-CREATION autotests/read/webp/bw-cwebp-lossless.png PRE-CREATION autotests/CMakeLists.txt bedc3ad451128365699ec8f1392c68993934453b src/imageformats/webp.h PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.cpp PRE-CREATION src/imageformats/CMakeLists.txt 7cafd18105a7219a9c761193012f87625f74d995 Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; autotests run Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/#review50358 --- This review has been submitted with commit 71772963359553c2da8d0891d6e179e03f0cd4e5 by Alex Merry to branch master. - Commit Hook On Feb. 16, 2014, 12:14 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- (Updated Feb. 16, 2014, 12:14 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- WebP: use Q_DECL_OVERRIDE In doing so, found a method that should not have been overridden, and so removed it. WebP: remove unused include Make WebP mimetype xml match the one in shared-mime-info-git This includes the detection magic and an alias for image/webp. It should be in shared-mime-info 1.3. Proposed by Jerome Leclanche adys...@gmail.com. Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Autotests are generated using the cwebp and dwebp utilities distributed with the libwebp reference library. Diffs - src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION cmake/FindWebP.cmake PRE-CREATION autotests/read/webp/rgb-cwebp.webp PRE-CREATION autotests/read/webp/rgb-cwebp.png PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.webp PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.png PRE-CREATION autotests/read/webp/bw-cwebp.webp PRE-CREATION autotests/read/webp/bw-cwebp.png PRE-CREATION autotests/read/webp/bw-cwebp-lossless.webp PRE-CREATION autotests/read/webp/bw-cwebp-lossless.png PRE-CREATION autotests/CMakeLists.txt bedc3ad451128365699ec8f1392c68993934453b src/imageformats/webp.h PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.cpp PRE-CREATION src/imageformats/CMakeLists.txt 7cafd18105a7219a9c761193012f87625f74d995 Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; autotests run Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/#review50360 --- This review has been submitted with commit 331a813662e5b753bc83834ada4a715c8df95f26 by Alex Merry to branch master. - Commit Hook On Feb. 16, 2014, 12:14 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- (Updated Feb. 16, 2014, 12:14 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- WebP: use Q_DECL_OVERRIDE In doing so, found a method that should not have been overridden, and so removed it. WebP: remove unused include Make WebP mimetype xml match the one in shared-mime-info-git This includes the detection magic and an alias for image/webp. It should be in shared-mime-info 1.3. Proposed by Jerome Leclanche adys...@gmail.com. Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Autotests are generated using the cwebp and dwebp utilities distributed with the libwebp reference library. Diffs - src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION cmake/FindWebP.cmake PRE-CREATION autotests/read/webp/rgb-cwebp.webp PRE-CREATION autotests/read/webp/rgb-cwebp.png PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.webp PRE-CREATION autotests/read/webp/rgb-cwebp-lossless.png PRE-CREATION autotests/read/webp/bw-cwebp.webp PRE-CREATION autotests/read/webp/bw-cwebp.png PRE-CREATION autotests/read/webp/bw-cwebp-lossless.webp PRE-CREATION autotests/read/webp/bw-cwebp-lossless.png PRE-CREATION autotests/CMakeLists.txt bedc3ad451128365699ec8f1392c68993934453b src/imageformats/webp.h PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.cpp PRE-CREATION src/imageformats/CMakeLists.txt 7cafd18105a7219a9c761193012f87625f74d995 Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; autotests run Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kimageformats_master_qt5 #28
See http://build.kde.org/job/kimageformats_master_qt5/28/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115702: Check that kconfig_compiler signals get emitted when using KConfigDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115702/#review50375 --- Ship it! Ship It! - Kevin Ottens On Feb. 16, 2014, 5:03 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115702/ --- (Updated Feb. 16, 2014, 5:03 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Check that kconfig_compiler signals get emitted when using KConfigDialog Diffs - autotests/CMakeLists.txt 2ae17fa8cad51720f26e453a8fb15c0dc7984bb4 autotests/kconfigdialog_unittest.cpp e5322c1782c2a68c15451777066e28a9b7afea23 autotests/signaltest.kcfg PRE-CREATION autotests/signaltest.kcfgc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115702/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115863/ --- (Updated Feb. 20, 2014, 3:01 p.m.) Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Changes --- Don't find dependencies that are used but not explicitly linked against. Adding the remaining dependencies and their explicit links can be for a future review request. Repository: khtml Description --- - QtTest is only required for autotests - QtX11Extras is only required for X11 builds, and for tests - Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are not used Diffs (updated) - CMakeLists.txt 8ced64f9b80123e45c319357d829c45641ed9d4d autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a Diff: https://git.reviewboard.kde.org/r/115863/diff/ Testing --- Builds. Tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115863/#review50377 --- Ship it! Ship It! - Alex Merry On Feb. 20, 2014, 3:01 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115863/ --- (Updated Feb. 20, 2014, 3:01 p.m.) Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Repository: khtml Description --- - QtTest is only required for autotests - QtX11Extras is only required for X11 builds, and for tests - Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are not used Diffs - CMakeLists.txt 8ced64f9b80123e45c319357d829c45641ed9d4d autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a Diff: https://git.reviewboard.kde.org/r/115863/diff/ Testing --- Builds. Tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115863: Improve khtml dependencies
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115863/ --- (Updated Feb. 20, 2014, 3:47 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Repository: khtml Description --- - QtTest is only required for autotests - QtX11Extras is only required for X11 builds, and for tests - Remove KCrash, KDBusAddons, KGuiAddons, KInit, and KItemViews as they are not used Diffs - CMakeLists.txt 8ced64f9b80123e45c319357d829c45641ed9d4d autotests/CMakeLists.txt 33f1ecb7ba65f223baef242eb21cd34457b020da tests/CMakeLists.txt 8fc438fa932ec43492b6c2a8e5bc8f0337550d1a Diff: https://git.reviewboard.kde.org/r/115863/diff/ Testing --- Builds. Tests pass. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KItemModels, Solid KJS licenses
On Thursday 20 of February 2014 11:41:48 Alex Merry wrote: ... KItemModels kcheckableproxymodel.(cpp|h) is Stephen Kelly (and, for safety, David Faure). modeltest.(cpp|h) were taken from Qt Concurrent, and subsequently modified by Stephen Kelly, and touched by David Faure and Aurélien Gâteau (but I don't think the latter two count as copyright holders, judging from the commit messages). David is on record as being happy with relicensing to LGPLv2+ (with or without the e.V. clause) - see relicensecheck.pl in kde:kde-dev-scripts. [1] https://build.opensuse.org/request/show/223093 KItemModels are even more GPL, than LGPLv2+, 'only' main.cpp, lessthanwidget.(cpp|h), mainwindow.(cpp|h), selectionpmwidget.(cpp|h), descendantpmwidget.(cpp|h), recursivefilterpmwidget.(cpp|h), reparentingpmwidget.(cpp|h) and proxymodeltestwidget.(cpp|h) (all from autotests/proxymodeltestapp/) are LGPLv2+, the rest is GPL. Cheers, Hrvoje signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115635: Make kconfig_compiler signals actually useful
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115635/ --- (Updated Feb. 20, 2014, 4:57 p.m.) Review request for KDE Frameworks. Changes --- Fixed the last two issues, will squash this with https://git.reviewboard.kde.org/r/115634/ once it has been approved and then commit. https://git.reviewboard.kde.org/r/115702/ can go in then as well Repository: kconfig Description --- Make kconfig_compiler signals actually useful Previously the classes generated by kconfig_compiler would only emit the defined signals when using the setters provided by that class. However, when using e.g. KConfigDialog which uses KConfigSkeletonItem::setProperty() to change the items no signal was generated. This patch fixes this by using a wrapper KConfigSkeletonItem subclass that calls a private itemChanged() method in the generated class which updates the set of changed properties. As soon as the item is saved (usrWriteConfig() in the generated class is called) the signal will be emitted Diffs (updated) - src/core/kcoreconfigskeleton.h c1a158771a785151902cd0a36aa672623618b99e src/core/kcoreconfigskeleton.cpp d9b95b4b0f236f82b1d4831432d3e7637ef19365 src/kconfig_compiler/kconfig_compiler.cpp 0c4254a296348e02e596e9b10b76ff446f26bb65 autotests/kconfig_compiler/test_signal.h.ref 737718d0244b23914678046bc519cf082e4b1a99 autotests/kconfig_compiler/test_signal.cpp.ref fd2d4bc9941a6ee14f0a221fdd72ef663ee078a4 Diff: https://git.reviewboard.kde.org/r/115635/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115634/ passes Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115874: Fix unit tests on Windows by adding two expected failures
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115874/#review50382 --- This review has been submitted with commit 1f07a6af8a219e2adf9d1c37e774bb42fc3f5612 by Alex Richardson to branch master. - Commit Hook On Feb. 19, 2014, 7:11 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115874/ --- (Updated Feb. 19, 2014, 7:11 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix unit tests on Windows by adding two expected failures KDirWatch with QFSWatch backend fails in two cases, this seems to be a limitation in the QFSWatch code since it works fine with the stat backend. Diffs - autotests/kdirwatch_unittest.cpp ca9cf0361dbe1bee3b0b76942c708110b7445ad5 Diff: https://git.reviewboard.kde.org/r/115874/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115874: Fix unit tests on Windows by adding two expected failures
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115874/ --- (Updated Feb. 20, 2014, 4:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix unit tests on Windows by adding two expected failures KDirWatch with QFSWatch backend fails in two cases, this seems to be a limitation in the QFSWatch code since it works fine with the stat backend. Diffs - autotests/kdirwatch_unittest.cpp ca9cf0361dbe1bee3b0b76942c708110b7445ad5 Diff: https://git.reviewboard.kde.org/r/115874/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115702: Check that kconfig_compiler signals get emitted when using KConfigDialog
On Feb. 20, 2014, 3:32 p.m., Kevin Ottens wrote: Ship It! Waiting for https://git.reviewboard.kde.org/r/115634/, otherwise the unit test will fail. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115702/#review50375 --- On Feb. 16, 2014, 6:03 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115702/ --- (Updated Feb. 16, 2014, 6:03 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Check that kconfig_compiler signals get emitted when using KConfigDialog Diffs - autotests/CMakeLists.txt 2ae17fa8cad51720f26e453a8fb15c0dc7984bb4 autotests/kconfigdialog_unittest.cpp e5322c1782c2a68c15451777066e28a9b7afea23 autotests/signaltest.kcfg PRE-CREATION autotests/signaltest.kcfgc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115702/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115742: KParts: Allow compilation on windows
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115742/ --- (Updated Feb. 20, 2014, 5:27 p.m.) Review request for KDE Frameworks. Changes --- CreateHardLink works exactly the same as link(2) on Linux (just with swapped parameters and return value). Repository: kparts Description --- Allow compilation on windows Diffs (updated) - src/browserextension.h 3ccafcbf0f6628cf7b07ce0436036bb972f95107 src/readwritepart.cpp 693cb76e05d975066ff93e69da27cc25d9dfe35d Diff: https://git.reviewboard.kde.org/r/115742/diff/ Testing --- compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115916: Fix MSVC build of kprintpreview_test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115916/ --- Review request for KDE Frameworks. Repository: kprintutils Description --- Fix MSVC build of kprintpreview_test I am not sure whether this is the best solution, but I don't want to make the Linux code less efficient. However it is a test application so it probably doesn't matter... Diffs - tests/kprintpreview_test.cpp 79cac037ab38bce89b97e4ede58eb58d821b25f3 Diff: https://git.reviewboard.kde.org/r/115916/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115634: Add kconfig_compiler autotest that checks whether signals are emitted
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115634/#review50388 --- Ship it! Ship It! - Aleix Pol Gonzalez On Feb. 20, 2014, 3:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115634/ --- (Updated Feb. 20, 2014, 3:53 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- Add kconfig_compiler autotest that checks whether signals are emitted Currently this works when using the setters, however when using setProperty() on the KCoreConfigSkeleton* (as done by KConfigDialog) no signals are emitted. Diffs - autotests/kconfig_compiler/signals_test_no_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/CMakeLists.txt a2ebb9453bacb2c7507bc9477b6753a34bbcd434 autotests/kconfig_compiler/kconfigcompiler_test_signals.cpp PRE-CREATION autotests/kconfig_compiler/signals_test.kcfg PRE-CREATION autotests/kconfig_compiler/signals_test_no_singleton.kcfgc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115634/diff/ Testing --- Compiles, tests fail until https://git.reviewboard.kde.org/r/115635/ is applied, then they pass. Rather ugly code IMO, open for suggestions to improve it... Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115635: Make kconfig_compiler signals actually useful
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115635/#review50390 --- This review has been submitted with commit 6d3a4405fc2723f5796e845247b6b0eb0448216e by Alex Richardson to branch master. - Commit Hook On Feb. 20, 2014, 3:57 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115635/ --- (Updated Feb. 20, 2014, 3:57 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- Make kconfig_compiler signals actually useful Previously the classes generated by kconfig_compiler would only emit the defined signals when using the setters provided by that class. However, when using e.g. KConfigDialog which uses KConfigSkeletonItem::setProperty() to change the items no signal was generated. This patch fixes this by using a wrapper KConfigSkeletonItem subclass that calls a private itemChanged() method in the generated class which updates the set of changed properties. As soon as the item is saved (usrWriteConfig() in the generated class is called) the signal will be emitted Diffs - src/core/kcoreconfigskeleton.h c1a158771a785151902cd0a36aa672623618b99e src/core/kcoreconfigskeleton.cpp d9b95b4b0f236f82b1d4831432d3e7637ef19365 src/kconfig_compiler/kconfig_compiler.cpp 0c4254a296348e02e596e9b10b76ff446f26bb65 autotests/kconfig_compiler/test_signal.h.ref 737718d0244b23914678046bc519cf082e4b1a99 autotests/kconfig_compiler/test_signal.cpp.ref fd2d4bc9941a6ee14f0a221fdd72ef663ee078a4 Diff: https://git.reviewboard.kde.org/r/115635/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115634/ passes Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115635: Make kconfig_compiler signals actually useful
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115635/ --- (Updated Feb. 20, 2014, 5:15 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kconfig Description --- Make kconfig_compiler signals actually useful Previously the classes generated by kconfig_compiler would only emit the defined signals when using the setters provided by that class. However, when using e.g. KConfigDialog which uses KConfigSkeletonItem::setProperty() to change the items no signal was generated. This patch fixes this by using a wrapper KConfigSkeletonItem subclass that calls a private itemChanged() method in the generated class which updates the set of changed properties. As soon as the item is saved (usrWriteConfig() in the generated class is called) the signal will be emitted Diffs - src/core/kcoreconfigskeleton.h c1a158771a785151902cd0a36aa672623618b99e src/core/kcoreconfigskeleton.cpp d9b95b4b0f236f82b1d4831432d3e7637ef19365 src/kconfig_compiler/kconfig_compiler.cpp 0c4254a296348e02e596e9b10b76ff446f26bb65 autotests/kconfig_compiler/test_signal.h.ref 737718d0244b23914678046bc519cf082e4b1a99 autotests/kconfig_compiler/test_signal.cpp.ref fd2d4bc9941a6ee14f0a221fdd72ef663ee078a4 Diff: https://git.reviewboard.kde.org/r/115635/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115634/ passes Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115634: Add kconfig_compiler autotest that checks whether signals are emitted
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115634/ --- (Updated Feb. 20, 2014, 5:15 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kconfig Description --- Add kconfig_compiler autotest that checks whether signals are emitted Currently this works when using the setters, however when using setProperty() on the KCoreConfigSkeleton* (as done by KConfigDialog) no signals are emitted. Diffs - autotests/kconfig_compiler/signals_test_no_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/CMakeLists.txt a2ebb9453bacb2c7507bc9477b6753a34bbcd434 autotests/kconfig_compiler/kconfigcompiler_test_signals.cpp PRE-CREATION autotests/kconfig_compiler/signals_test.kcfg PRE-CREATION autotests/kconfig_compiler/signals_test_no_singleton.kcfgc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115634/diff/ Testing --- Compiles, tests fail until https://git.reviewboard.kde.org/r/115635/ is applied, then they pass. Rather ugly code IMO, open for suggestions to improve it... Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115634: Add kconfig_compiler autotest that checks whether signals are emitted
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115634/#review50389 --- This review has been submitted with commit 6d3a4405fc2723f5796e845247b6b0eb0448216e by Alex Richardson to branch master. - Commit Hook On Feb. 20, 2014, 3:53 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115634/ --- (Updated Feb. 20, 2014, 3:53 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- Add kconfig_compiler autotest that checks whether signals are emitted Currently this works when using the setters, however when using setProperty() on the KCoreConfigSkeleton* (as done by KConfigDialog) no signals are emitted. Diffs - autotests/kconfig_compiler/signals_test_no_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton.kcfgc PRE-CREATION autotests/kconfig_compiler/signals_test_singleton_dpointer.kcfgc PRE-CREATION autotests/kconfig_compiler/CMakeLists.txt a2ebb9453bacb2c7507bc9477b6753a34bbcd434 autotests/kconfig_compiler/kconfigcompiler_test_signals.cpp PRE-CREATION autotests/kconfig_compiler/signals_test.kcfg PRE-CREATION autotests/kconfig_compiler/signals_test_no_singleton.kcfgc PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115634/diff/ Testing --- Compiles, tests fail until https://git.reviewboard.kde.org/r/115635/ is applied, then they pass. Rather ugly code IMO, open for suggestions to improve it... Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Allocating kde-runtime/platforms/win
Hi! I am going through the list of things where we're moving kde-runtime components to [1] and I see that there's a platform/win directory. Do you agree that having it in a separate repository would be the best? Could anybody with a working KF5 + windows system (if that exists) work on it? Thanks Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115485: Porting KTranscript from KJS to QtScript
On Feb. 20, 2014, 2:36 p.m., Kevin Ottens wrote: Any concerns left on that patch? It'd be nice to have it in alpha 2. I guess the main problem is that due to a weird JavaScriptCore internal thing the unit test crashes on exit. See https://bugreports.qt-project.org/browse/QTBUG-9622 for reference. One idea I had was to compile KTranscript into the unit test directly, using a DEFINE to switch from Q_GLOBAL_STATIC to an explicitly created and destroyed instance. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review50376 --- On Feb. 16, 2014, 6:54 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 16, 2014, 6:54 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - CMakeLists.txt 3e099d5 src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp c922e91 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
using KDBusConnectionPool in libraries
Hi.. I ran into an interesting situation the other day with libkactivities: it uses KDBusConnectionPool to create connections in a thread-safe manner. KDBusConnectionPool creates a connection in whatever thread it happens to be executed from. In libkactivities this creates a problem as a singleton that is internal to the library uses KDBusConnectionPool .. so whatever thread it happens to be called from first: that’s the thread it gets its QDBusConnection object put into. Of course, if that thread has no event loop and/or exits, then things stop working as expected. In the case of libkactivities, things just stop working, period. Either a better solution needs to be found for KDBusConnectionPool or a warning should be placed prominently in the apidox about this “gotcha” and perhaps it should be completely avoided in other frameworks where it is impossible to know the threading model of the application that will be using it. Or, I suppose, we could invent a policy that applications should do all dbus related activities in a specific thread .. though that can be difficult to know as dbus calls are often hidden within libraries. .. or, does anyone have a pointer to what exactly in QDBusConnection is not thread safe? -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : ktexteditor_master_qt5 #217
See http://build.kde.org/job/ktexteditor_master_qt5/217/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Undefined references to Attica
O Xoves, 20 de Febreiro de 2014 10:50:21 Alex Merry escribiu: On 20/02/14 06:56, Adrián Chaves Fernández wrote: I was trying to build frameworks 4.96.0, and I run into trouble compiling the tests for KXmlGui, due to undefined references to Attica. I did this to solve it: https://git.reviewboard.kde.org/r/115907/diff/ Now, on the next package, KBookmarks, I again get undefined references to Attica (from the KXmlGui shared library) when building the tests. Am I missing something here? I'm starting to think the issue is with my personal configuration and not with the packages themselves. Odd; that shouldn't be happening. Does that statement include https://git.reviewboard.kde.org/r/115907/diff/ ? Should I need those changes to build kxmlgui or shouldn’t I? What system are you building on? Also, `make VERBOSE=1` can be a helpful debugging tool; I could imagine maybe getting errors like this if you are doing static builds. I’m building on Chakra, which should be not too different from Arch Linux. I’m using this lines for the actual build of kbookmarks (after building kxmlgui with the linked patch): mkdir -p build cd build cmake ../kbookmarks-4.96.0 \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DCMAKE_INSTALL_PREFIX=/usr/bin \ -DLIB_INSTALL_DIR=lib make With VERBOSE=1 in make, I get this towards the end: Linking CXX executable kbookmarkdialogtest cd /home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kbookmarks/src/build/tests /usr/bin/cmake -E cmake_link_script CMakeFiles/kbookmarkdialogtest.dir/link.txt --verbose=1 /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -g -fvar-tracking-assignments -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 -O2 -g -DNDEBUG -Wl,--enable-new-dtags -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/kbookmarkdialogtest.dir/kbookmarkdialogtest.cpp.o CMakeFiles/kbookmarkdialogtest.dir/kbookmarkdialogtest_automoc.cpp.o -o kbookmarkdialogtest -rdynamic ../src/libKF5Bookmarks.so.4.96.0 /usr/lib/libQt5Xml.so.5.2.1 /usr/lib/libQt5Widgets.so.5.2.1 /usr/lib/libQt5Gui.so.5.2.1 /usr/lib/libQt5Core.so.5.2.1 -Wl,-rpath,/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kbookmarks/src/build/src /usr/bin/ld: warning: libKF5Attica.so.4, needed by /usr/lib/libKF5XmlGui.so.4, not found (try using -rpath or -rpath-link) /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::~Person()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::~Provider()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::city() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::extendedAttribute(QString const) const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ItemJobAttica::Person::result() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Metadata::~Metadata()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::country() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ProviderManager::ProviderManager(QFlagsAttica::ProviderManager::ProviderFlag const)' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ProviderManager::providers() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::name() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::Provider()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::avatarUrl() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ProviderManager::loadDefaultProviders()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Metadata::error() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ProviderManager::~ProviderManager()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::BaseJob::staticMetaObject' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::BaseJob::start()' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::ProviderManager::providerByUrl(QUrl const) const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::isValid() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::requestPerson(QString const)' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Person::homepage() const' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::Provider::operator=(Attica::Provider const)' /usr/lib/libKF5XmlGui.so.4: undefined reference to `Attica::BaseJob::metadata() const' collect2: error: ld returned 1 exit status make[2]: *** [tests/kbookmarkdialogtest] Error 1 make[2]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kbookmarks/src/build' make[1]: ***
Re: Review Request 115907: Link tests with extra libraries as well
On Feb. 20, 2014, 10:46 a.m., Alex Merry wrote: Can you describe the problem this fixes? Are the tests directly using these libraries somehow? If I build with these steps: mkdir -p build cd build cmake ../kxmlgui-4.96.0 \ -DCMAKE_INSTALL_PREFIX=/usr/bin \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DLIB_INSTALL_DIR=lib \ -DSYSCONF_INSTALL_DIR=/etc make In Chakra, I cannot get it to build. Without these changes, I get something like this when building the tests: Linking CXX executable kbugreporttest cd /home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/tests /usr/bin/cmake -E cmake_link_script CMakeFiles/kbugreporttest.dir/link.txt --verbose=1 /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -g -fvar-tracking-assignments -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 -O2 -g -DNDEBUG -Wl,--enable-new-dtags -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/kbugreporttest.dir/kbugreporttest.cpp.o CMakeFiles/kbugreporttest.dir/kbugreporttest_automoc.cpp.o -o kbugreporttest -rdynamic /usr/lib/libQt5Test.so.5.2.1 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 ../src/libKF5XmlGui.so.4.96.0 /usr/lib/libKF5ConfigWidgets.so.4.96.0 /usr/lib/libKF5Codecs.so.4.96.0 /usr/lib/libKF5Auth.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 /usr/lib/libKF5CoreAddons.so.4.96.0 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5ConfigGui.so.4.96.0 /usr/lib/libQt5Xml.so.5.2.1 /usr/lib/libKF5ConfigC ore.so.4.96.0 /usr/lib/libQt5Widgets.so.5.2.1 /usr/lib/libQt5Gui.so.5.2.1 /usr/lib/libQt5DBus.so.5.2.1 /usr/lib/libQt5Core.so.5.2.1 -Wl,-rpath,/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/src /usr/bin/ld: warning: libKF5Attica.so.4, needed by ../src/libKF5XmlGui.so.4.96.0, not found (try using -rpath or -rpath-link) ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::~Person()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::~Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::city() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::extendedAttribute(QString const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ItemJobAttica::Person::result() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::~Metadata()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::country() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::ProviderManager(QFlagsAttica::ProviderManager::ProviderFlag const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providers() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::name() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::avatarUrl() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::loadDefaultProviders()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::error() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::~ProviderManager()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::staticMetaObject' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::start()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providerByUrl(QUrl const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::isValid() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::requestPerson(QString const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::homepage() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::operator=(Attica::Provider const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::metadata() const' collect2: error: ld returned 1 exit status make[2]: *** [tests/kbugreporttest] Error 1 make[2]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make[1]: *** [tests/CMakeFiles/kbugreporttest.dir/all] Error 2 make[1]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make: *** [all] Error 2 - Adrián --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115907/#review50328 --- On Feb. 20, 2014, 5:53 a.m., Adrián Chaves Fernández wrote:
Re: Review Request 115744: Fix projects using KDocTools on windows.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115744/#review50410
---
Ship it!
Ok, even without the opinion from kde-windows, the change looks fine and it's
windows only. There is enough time to fix it before the final release.
- Luigi Toscano
On Feb. 19, 2014, 7:45 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115744/
---
(Updated Feb. 19, 2014, 7:45 p.m.)
Review request for Documentation, KDE Frameworks and Luigi Toscano.
Repository: kdoctools
Description
---
Fix projects using KDocTools on windows.
If ${CMAKE_INSTALL_PREFIX}/${DATA_INSTALL_DIR} contained /../ elements
file(RELATIVE_PATH) would interpret these as valid directory names and
therefore return a relative path which has too many /../
REVIEW: 115744
Diffs
-
src/CMakeLists.txt 241d56ffdb9f5cf4859eaf06aad491b9e1ca94fa
Diff: https://git.reviewboard.kde.org/r/115744/diff/
Testing
---
kservice didn't compile before this change, now it does (win32), doesn't
affect other platforms
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115907: Link tests with extra libraries as well
On Feb. 20, 2014, 10:46 a.m., Alex Merry wrote: Can you describe the problem this fixes? Are the tests directly using these libraries somehow? Adrián Chaves Fernández wrote: If I build with these steps: mkdir -p build cd build cmake ../kxmlgui-4.96.0 \ -DCMAKE_INSTALL_PREFIX=/usr/bin \ -DCMAKE_BUILD_TYPE=RelWithDebInfo \ -DLIB_INSTALL_DIR=lib \ -DSYSCONF_INSTALL_DIR=/etc make In Chakra, I cannot get it to build. Without these changes, I get something like this when building the tests: Linking CXX executable kbugreporttest cd /home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/tests /usr/bin/cmake -E cmake_link_script CMakeFiles/kbugreporttest.dir/link.txt --verbose=1 /usr/bin/c++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -g -fvar-tracking-assignments -g -fvar-tracking-assignments -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 -O2 -g -DNDEBUG -Wl,--enable-new-dtags -Wl,-O1,--sort-common,--as-needed,-z,relro CMakeFiles/kbugreporttest.dir/kbugreporttest.cpp.o CMakeFiles/kbugreporttest.dir/kbugreporttest_automoc.cpp.o -o kbugreporttest -rdynamic /usr/lib/libQt5Test.so.5.2.1 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 ../src/libKF5XmlGui.so.4.96.0 /usr/lib/libKF5ConfigWidgets.so.4.96.0 /usr/lib/libKF5Codecs.so.4.96.0 /usr/lib/libKF5Auth.so.4.96.0 /usr/lib/libKF5I18n.so.4.96.0 /usr/lib/libKF5CoreAddons.so.4.96.0 /usr/lib/libKF5WidgetsAddons.so.4.96.0 /usr/lib/libKF5ConfigGui.so.4.96.0 /usr/lib/libQt5Xml.so.5.2.1 /usr/lib/libKF5C onfigCore.so.4.96.0 /usr/lib/libQt5Widgets.so.5.2.1 /usr/lib/libQt5Gui.so.5.2.1 /usr/lib/libQt5DBus.so.5.2.1 /usr/lib/libQt5Core.so.5.2.1 -Wl,-rpath,/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build/src /usr/bin/ld: warning: libKF5Attica.so.4, needed by ../src/libKF5XmlGui.so.4.96.0, not found (try using -rpath or -rpath-link) ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::~Person()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::~Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::city() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::extendedAttribute(QString const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ItemJobAttica::Person::result() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::~Metadata()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::country() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::ProviderManager(QFlagsAttica::ProviderManager::ProviderFlag const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providers() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::name() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::Provider()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::avatarUrl() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::loadDefaultProviders()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Metadata::error() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::~ProviderManager()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::staticMetaObject' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::start()' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::ProviderManager::providerByUrl(QUrl const) const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::isValid() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::requestPerson(QString const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Person::homepage() const' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::Provider::operator=(Attica::Provider const)' ../src/libKF5XmlGui.so.4.96.0: undefined reference to `Attica::BaseJob::metadata() const' collect2: error: ld returned 1 exit status make[2]: *** [tests/kbugreporttest] Error 1 make[2]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make[1]: *** [tests/CMakeFiles/kbugreporttest.dir/all] Error 2 make[1]: Leaving directory `/home/gallaecio/proxectos/empaquetamento/repositorios/desktop/kxmlgui/src/build' make: *** [all] Error 2 Hmm…
Re: using KDBusConnectionPool in libraries
On Thu, February 20, 2014 20:03:20 Aaron J. Seigo wrote: Either a better solution needs to be found for KDBusConnectionPool or a warning should be placed prominently in the apidox about this “gotcha” and perhaps it should be completely avoided in other frameworks where it is impossible to know the threading model of the application that will be using it. Or, I suppose, we could invent a policy that applications should do all dbus related activities in a specific thread .. though that can be difficult to know as dbus calls are often hidden within libraries. An apidox warning at the very least sounds appropriate. On a less related note, all this talk about threading models is starting to remind me of a bunch of Microsoft COM programmers talking about apartment models and such from 10 years ago. I'm also starting to think that all of our DBus interfaces intended for general programmatic consumption need to be async; I've been able to encounter the most amazing deadlocks sometimes. Of course this is both hard to do and hard to train/teach others to know how to do. :-/ Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115485: Porting KTranscript from KJS to QtScript
On Feb. 20, 2014, 2:36 p.m., Kevin Ottens wrote: Any concerns left on that patch? It'd be nice to have it in alpha 2. Kevin Krammer wrote: I guess the main problem is that due to a weird JavaScriptCore internal thing the unit test crashes on exit. See https://bugreports.qt-project.org/browse/QTBUG-9622 for reference. One idea I had was to compile KTranscript into the unit test directly, using a DEFINE to switch from Q_GLOBAL_STATIC to an explicitly created and destroyed instance. Sounds like an adequate workaround, would be awesome if you could try it. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review50376 --- On Feb. 16, 2014, 6:54 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 16, 2014, 6:54 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - CMakeLists.txt 3e099d5 src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp c922e91 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115775: Defer to CMake's find_dependency macro if it exists
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115775/#review50432 --- Ship it! Ship It! - Kevin Ottens On Feb. 18, 2014, 3:49 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115775/ --- (Updated Feb. 18, 2014, 3:49 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Defer to CMake's find_dependency macro if it exists This will be available in CMake 3.0.0. This way, we automatically pick up any new features from it. Diffs - modules/ECMPackageConfigHelpers.cmake 78017393afa6e35dd90df0bd15e08ceed9dff841 Diff: https://git.reviewboard.kde.org/r/115775/diff/ Testing --- Built some frameworks with CMake 2.8.12 (still works) and CMake git (properly defers to CMake's version, as shown by the fact that packages only searched for with find_dependency() are not shown in the feature summary). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115602: Rename kactivitymanagerd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/#review50434 --- I understand Ivan point of view. Now I'm wondering about something: Are we sure the situation will be the same in the future for a 5 to 6 transition? I don't think we can be 100% sure and so we might want to start versioning to be ready for that and be consistent with other similar services. I wouldn't have a huge problem either way, just want to make sure we thought that through. - Kevin Ottens On Feb. 18, 2014, 9:50 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/ --- (Updated Feb. 18, 2014, 9:50 p.m.) Review request for KDE Frameworks and Ivan Čukić. Repository: kactivities Description --- ...so it can co-exists with kactivities4 in the same prefix Diffs - autotests/Process.cpp a7a0507 src/lib/core/manager_p.cpp 57f60be src/service/CMakeLists.txt 141e9b7 src/service/files/kactivitymanagerd.desktop ce68a49 Diff: https://git.reviewboard.kde.org/r/115602/diff/ Testing --- Both Plasma1 and Next ran fine with this patch and withouth kactivitymanagerd(4) installed. Haven't tested the case when they are both installed. Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115875: kconfigtest: write everything into a subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/#review50435 --- autotests/kconfigtest.cpp https://git.reviewboard.kde.org/r/115875/#comment35495 Hm we're loosing the test mode for QStandardPaths, I don't think that's desirable. - Kevin Ottens On Feb. 18, 2014, 9:52 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/ --- (Updated Feb. 18, 2014, 9:52 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- kconfigtest: write everything into a subdirectory This test keeps deleting the whole ~/.qttest directory. By moving all data into a subdirectory it is now possible to run multiple tests that use kconfig in parallel. Diffs - autotests/kconfigtest.cpp 1c0dc1cf63539e29236ab57e1e848930b468053a Diff: https://git.reviewboard.kde.org/r/115875/diff/ Testing --- Test still passes. No files (except kdeglobals) are created in ~/.qttest Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115879: DocBookXML has been renamed, use the new exported variables
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115879/#review50436 --- Ship it! Ship It! - Kevin Ottens On Feb. 18, 2014, 10:54 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115879/ --- (Updated Feb. 18, 2014, 10:54 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- Follow up of https://git.reviewboard.kde.org/r/115876/: - use the new name (FindDocBookXML2.cmake); - use the new variables instead of the legacy one - define here the DocBookXML4 requested version number (currently 4.2). Diffs - CMakeLists.txt a400186 config-kdoctools.h.cmake f2fe22c src/CMakeLists.txt 241d56f src/customization/dtd/kdex.dtd.cmake c643d9b Diff: https://git.reviewboard.kde.org/r/115879/diff/ Testing --- Compiles, the relevant files (like customization/dtd/kdex.dtd) are generated Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115876: More generic DocBookXML - DocBookXML4
On Feb. 18, 2014, 11:13 p.m., Alex Merry wrote: Does this have any other users than kdoctools? If not, it should probably just move to that module. Even if kde4support ends up using it, I don't view that as a reason to put it in ECM. Luigi Toscano wrote: There are no other use apart from kdoctools and (soon) kde4support. The module (and the companion FindDocBookXSLT) is now more generic (the legacy part will be removed once it lands into kde4support), so maybe could go upstream, but regarding ECM I'm not aware of other applications/libraries using it. I agree with Alex there, if there's no indication of users so far, let's maybe move that to kdoctools even if that means putting a copy in kde4support. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115876/#review50181 --- On Feb. 18, 2014, 10:52 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115876/ --- (Updated Feb. 18, 2014, 10:52 p.m.) Review request for Build System, Documentation and KDE Frameworks. Repository: extra-cmake-modules Description --- FindDocBookXML.cmake was originally part of kdelibs/kdoctools, but not installed. The version currently in ECM is, as the old one, is quite tight to the old behavior, it hardcodes the DocBookXML version currently used. - the rename reflect the fact that it's used for DocBookXML4; a future DocBookXML5 could be added if needed; - the structure allows a generic usage (find DocBookXML version 4.x), not tied to the usage in KDocTools. KDocTools will be changed to call it with the correct version (the version number is a property of KDocTools, not used outside it, but hidden inside meinproc5 and libKF5XsltKde.a). Next changes: - use DocBookXML4 (so DocBookXML4_* instead of DOCBOOKXML_* legacy variables) in frameworks - move the definition of legacy DOCBOOKXML_* in kde4support Diffs - find-modules/FindDocBookXML.cmake b6d623e find-modules/FindDocBookXML4.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115876/diff/ Testing --- Compiles (some changes are needed in KDocTools, I will add them to another review). Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115816: Remove strigi libs from kf5-frameworks-build-include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115816/#review50438 --- Ship it! Ship It! - Kevin Ottens On Feb. 19, 2014, 11:54 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115816/ --- (Updated Feb. 19, 2014, 11:54 a.m.) Review request for Build System, KDE Frameworks, David Faure, and Kevin Ottens. Repository: kdesrc-build Description --- Remove strigi libs from kf5-frameworks-build-include Nothing in frameworks actually uses anything strigi-related. Diffs - kf5-frameworks-build-include 937d182ad96eb3780756876087cb44233cc8f21e Diff: https://git.reviewboard.kde.org/r/115816/diff/ Testing --- kdesrc-build has got to KIO so far with no problems (clean build and install dirs, although I do actually have strigi 0.7.8 installed in /usr). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115840: Rename Platform to Frameworks in both about dialogs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115840/#review50440 --- Ship it! Ship It! - Kevin Ottens On Feb. 17, 2014, 7:04 p.m., Sebastian Kügler wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115840/ --- (Updated Feb. 17, 2014, 7:04 p.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- Rename Platform to Frameworks in both about dialogs Diffs - src/kaboutapplicationdialog.cpp e7bd2fe4c50a4e13321e501608409a2f339636c2 src/kaboutkdedialog_p.cpp b97ad1071f107bde2e829c9de7b343a17fd4cfe9 Diff: https://git.reviewboard.kde.org/r/115840/diff/ Testing --- Started kwrite, new names appear correctly. File Attachments After and before https://git.reviewboard.kde.org/media/uploaded/files/2014/02/17/6ace6797-b82a-4c61-9bae-004ea7bdb654__aboutdialog.png Thanks, Sebastian Kügler ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115896: Import FindDocBook*.cmake from extra-cmake-modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/#review50441 --- Ship it! Ship It! - Kevin Ottens On Feb. 19, 2014, 12:47 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115896/ --- (Updated Feb. 19, 2014, 12:47 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- Commits imported with `git format-patch` (edited), followed by `git am`. Add the local cmake directory to the CMake module path Use the newer syntax in FindDocBook* It approprietly sets the _FOUND variables, we were defining the all uppercase instead. Sorry for the mess! Originally commit 190c79bb4e6bc8b8757bd890485a9bafb4a65219 of the extra-cmake-modules repository Move FindDocBook* to find-modules Originally commit d42d5889d25ac4c900a294f283dd802eccf96010 of the extra-cmake-modules repository Diffs - CMakeLists.txt d135e0caa55d126ba3c335b9f05f8125453c1e53 cmake/FindDocBookXML.cmake PRE-CREATION cmake/FindDocBookXSL.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115896/diff/ Testing --- Removed FindDocBook*.cmake from $PREFIX/share/ECM/find-modules, and a clean configure, build, install still works. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115316: Add demo for KRecentFileList
On Jan. 27, 2014, 2:23 a.m., Aleix Pol Gonzalez wrote: It's a test, not a demo. If you want, it's for demonstrating the developer that he did it right, but I wouldn't see it as documentation. I would rename it to KRecentFilesActionTest Kevin Ottens wrote: Yes, definitely a manual test (otherwise wouldn't be allowed in tests/ but in examples/ instead). Gregor Mi wrote: Ok, I will rename it. In the test/ folder there is also kcolorutilsdemo.cpp and kcolorschemedemo.cpp, so I was not sure which is correct. Alex Merry wrote: Any progress on this? Please update this review ASAP. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115316/#review48327 --- On Jan. 25, 2014, 10:56 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115316/ --- (Updated Jan. 25, 2014, 10:56 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- This is a demo test for KRecentFileList (in combination with KSharedConfig). The patch also contains a documentation update for krecentfilesaction.h/loadEntries() saying that Local file entries that do not exist anymore are not restored.. As a side note: Does it makes sense to optionally disable the automated removal of non-existing recent files? Or have the possibility to return the files that were automatically removed? Diffs - src/krecentfilesaction.h 38d1b5e3455d081304b064d13bccfc2164d12a14 tests/CMakeLists.txt 617a55944b2c91c9b09125ad92d070d3cd9a6551 tests/krecentfilesactiondemo.h PRE-CREATION tests/krecentfilesactiondemo.cpp PRE-CREATION tests/krecentfilesactiondemo.ui PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115316/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
On Jan. 27, 2014, 7:45 a.m., Kevin Ottens wrote: src/lib/kaboutdata.cpp, line 941 https://git.reviewboard.kde.org/r/115207/diff/1/?file=235099#file235099line941 Not really my type of thing. It's acting on an object behind our back without knowing... what happens to code where setApplication* was called before? Information would be lost and it's not obvious to the user. Looks dangerous to me. If we want to factorize the qApp call, and I see the need for that indeed, then that block should be provided by a separate method (setupApplication(QCoreApplication *)?). Aleix Pol Gonzalez wrote: I agree, I only did it this way to avoid the required set up. An alternative would be to make KAboutData to pass the information to Q*Application when it's initialized (and if it's an application KAboutData...). Alex Merry wrote: Any progress on this? In that case, wouldn't putting that in setApplicationData better? I see it already attaches properties to the application pointer. Or is that unrelated to what you had in mind? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review48347 --- On Jan. 21, 2014, 11:36 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Jan. 21, 2014, 11:36 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp f24006b Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115395: Also pass -fno-exceptions when building with clang
On Feb. 3, 2014, 6:07 p.m., Raphael Kubo da Costa wrote:
Please see the big comment below the elseif line, the link to the
kde-core-devel and
http://lists.kde.org/?l=kde-core-develm=138244424421211w=2: the issue
here is that if you pass -fno-exceptions to clang you need to guarantee it
is not going to include any headers that throw exceptions either, even if
it is in some template code that never gets instantiated.
For example, this does not build with clang++ -fno-exceptions, but does
with GCC 4.8:
#include exception
template typename T
struct S { void f() { throw std::exception(); } };
This was a problem for kdelibs including OpenEXR headers, or kdepim
including pimlibs headers that all fell into this case.
Alex Merry wrote:
Arguably, the solution here is to always enable exceptions for code that
encounters this (as we do for the OpenEXR QImage format plugin, for example).
Alexander Richardson wrote:
It works with all the STL headers, the question is should we have
everything built with clang be 7% bigger, or just enable exceptions in those
cases where it breaks compilation? I don't really mind either way, I just
realized that all of frameworks builds fine even with -fno-exceptions.
Raphael Kubo da Costa wrote:
The situation might be easier with frameworks and we can choose to
selectively enable exceptions where necessary; I only worry about ending up
having to play catch up with libraries that suddenly end up including headers
that throw exceptions via a dependency of a dependency, or issues going
undetected due to everyone using GCC.
Alex Merry wrote:
The choice, I guess, is between making life easy for Clang users by
avoiding errors that don't crop up with GCC, and making use of Clang's better
diagnostics to catch these sorts of problems. I'm not sure which we should
be going for.
I'd lean toward making use of clang's better diagnostics to be honest. Means we
need a clang build of frameworks too on the CI though.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115395/#review48846
---
On Jan. 29, 2014, 11:18 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115395/
---
(Updated Jan. 29, 2014, 11:18 p.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
Also pass -fno-exceptions when building with clang
All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
The only problem related to clang and -fno-exceptions I could find was
http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
clang version 3.0 which was released in December 2011
Diffs
-
kde-modules/KDECompilerSettings.cmake
335e1270d19f8342e41b22e7081dea3f7ac0fbfc
Diff: https://git.reviewboard.kde.org/r/115395/diff/
Testing
---
compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3
Would be good if someone with an older clang version could test it and see
whether it works.
May also be related to the libstdc++ headers (4.8 installed here).
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115717: Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set
On Feb. 19, 2014, 2:07 p.m., Alex Merry wrote: I don't think papering over the X11-ness of kdesu like this is the right approach. Of course, what this framework really needs is a test app; maybe a simple port of the kdesu app from kde-runtime? This kind of papering over can only be temporary indeed. Just wondering if Martin has the possibility to clean that up better at that stage? As for the test app: hell yes, definitely needed. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/#review50240 --- On Feb. 13, 2014, 9:41 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/ --- (Updated Feb. 13, 2014, 9:41 a.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set If kdesu is compiled with X11 it required the DISPLAY variable to be set. This is no longer correct as it might have been compiled with X11 but is run on Wayland. Thus the code checks now also for WAYLAND_DISPLAY in the HAVE_X11 ifdef blocks. The Wayland support should become more complete, I do not know how it behaves if we compile without X11 support. Unfortunately there are no autotests and no test applications which one could use. Diffs - src/client.cpp 91bfd78fbca6e5d8d365d924c0260087e3937948 src/kcookie.cpp 59448351696c503b34b7507e9c3fa8efc53139f9 Diff: https://git.reviewboard.kde.org/r/115717/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115827: Add KMainWindow::initialGeometrySet to increase SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/#review50446 --- src/kmainwindow.h https://git.reviewboard.kde.org/r/115827/#comment35497 Should definitely be inlined, but then can go in after that. - Kevin Ottens On Feb. 17, 2014, 10:49 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/ --- (Updated Feb. 17, 2014, 10:49 a.m.) Review request for KDE Frameworks. Repository: kxmlgui Description --- Add KMainWindow::initialGeometrySet to increase SC Deprecated and just returns false. Diffs - src/kmainwindow.h 7072b51fa5e9bf44703636481ea26c0e47769b52 src/kmainwindow.cpp f8d1e6dda2be6b8fe343e6b37a2682da061f2273 Diff: https://git.reviewboard.kde.org/r/115827/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115695: Rework KNotification to work without KNotify daemon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115695/#review50447 --- Way to big to properly review to be honest. That said, I agree with Aleix I'd like it to be closer to the target with less regressions before letting it in. You still have a few days. ;-) Also don't forget to update the yaml and the list of frameworks in the wiki, it's moving in tier 3 territory AFAICT. - Kevin Ottens On Feb. 13, 2014, 10:14 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115695/ --- (Updated Feb. 13, 2014, 10:14 a.m.) Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela. Repository: knotifications Description --- This patch merges KNotify daemon into KNotificationManager to have less daemons running and less dbus traffic. The patch is not yet finished (and for now it's full of QDebugs, that will all be removed and FIXMEs to indicate what needs doing), but as the Alpha2 is quite soon, I'd like to start the general review asap so some more changes can be done if needed. Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them the notification directly. KNotifyConfig was repurposed a bit, now it serves mostly just as the .notifyrc wrapper, all the rest is reused from the KNotification object. There are some changes in the KNotification API - id() and appName() are now exposed to public and slotReceivedId(int) is now also public so that KNotificationManager can directly give it an id. I'd like to rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, that is handled in NotifyByPopup which is responsible for communicating with the galago server (all the methods there were renamed to actually have *galago* in the name so it's clear), therefore the mapping of DBus/Galago Server ids is managed only there as it is actually only needed here. KNotitification::id() is assigned by the KNotificationManager and it's a simple increasing counter. The UI/Plasmoid changes will come next - basically the plan is to put only the Persistent notifications in the notifications history. Diffs - src/knotifyconfig.h PRE-CREATION src/knotifyconfig.cpp PRE-CREATION src/knotifyplugin.h PRE-CREATION src/knotifyplugin.cpp PRE-CREATION src/notifybypopup.h PRE-CREATION src/notifybypopup.cpp PRE-CREATION src/notifybypopupgrowl.h PRE-CREATION src/notifybypopupgrowl.cpp PRE-CREATION CMakeLists.txt 63ebf71 src/CMakeLists.txt a81b913 src/knotification.h 00554ba src/knotification.cpp 5d7405b src/knotificationmanager.cpp a4d0dfa src/knotificationmanager_p.h 81d962d Diff: https://git.reviewboard.kde.org/r/115695/diff/ Testing --- Works perfectly with both plasma notifications and kpassivepopup. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115901: Hide private methods and private slots behind the d-pointer in KLineEdit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115901/#review50448 --- Ship it! Ship It! - Kevin Ottens On Feb. 19, 2014, 10:57 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115901/ --- (Updated Feb. 19, 2014, 10:57 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and private slots behind the d-pointer in KLineEdit Diffs - src/klineedit.h b9457c1 src/klineedit.cpp 24b3bf0 src/klineedit_p.h 778e43a Diff: https://git.reviewboard.kde.org/r/115901/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115908: Remove Ki18n from KCompletion dependencies in cmake.in
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115908/#review50449 --- Ship it! Ship It! - Kevin Ottens On Feb. 20, 2014, 11:51 a.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115908/ --- (Updated Feb. 20, 2014, 11:51 a.m.) Review request for KDE Frameworks and David Gil Oliva. Repository: kcompletion Description --- KI18n is unused in KCompletion code, so we shouldn't search for it as a dep... Diffs - KF5CompletionConfig.cmake.in 54403d9 Diff: https://git.reviewboard.kde.org/r/115908/diff/ Testing --- Builds ;-) Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115717: Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set
On Feb. 19, 2014, 3:07 p.m., Alex Merry wrote: I don't think papering over the X11-ness of kdesu like this is the right approach. Of course, what this framework really needs is a test app; maybe a simple port of the kdesu app from kde-runtime? Kevin Ottens wrote: This kind of papering over can only be temporary indeed. Just wondering if Martin has the possibility to clean that up better at that stage? As for the test app: hell yes, definitely needed. well yes if there's a testapp and that works I can implement it properly. But IIRC kdesu never worked on my setup (not having a password for root). - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/#review50240 --- On Feb. 13, 2014, 10:41 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/ --- (Updated Feb. 13, 2014, 10:41 a.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set If kdesu is compiled with X11 it required the DISPLAY variable to be set. This is no longer correct as it might have been compiled with X11 but is run on Wayland. Thus the code checks now also for WAYLAND_DISPLAY in the HAVE_X11 ifdef blocks. The Wayland support should become more complete, I do not know how it behaves if we compile without X11 support. Unfortunately there are no autotests and no test applications which one could use. Diffs - src/client.cpp 91bfd78fbca6e5d8d365d924c0260087e3937948 src/kcookie.cpp 59448351696c503b34b7507e9c3fa8efc53139f9 Diff: https://git.reviewboard.kde.org/r/115717/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: using KDBusConnectionPool in libraries
Hello, On Thursday 20 February 2014 20:03:20 Aaron J. Seigo wrote: I ran into an interesting situation the other day with libkactivities: it uses KDBusConnectionPool to create connections in a thread-safe manner. KDBusConnectionPool creates a connection in whatever thread it happens to be executed from. In libkactivities this creates a problem as a singleton that is internal to the library uses KDBusConnectionPool .. so whatever thread it happens to be called from first: that’s the thread it gets its QDBusConnection object put into. Well, isn't the problem that this singleton should be thread-safe or thread- local in the first place? Of course, if that thread has no event loop and/or exits, then things stop working as expected. In the case of libkactivities, things just stop working, period. Either a better solution needs to be found for KDBusConnectionPool or a warning should be placed prominently in the apidox about this “gotcha” and perhaps it should be completely avoided in other frameworks where it is impossible to know the threading model of the application that will be using it. Yes, adding a big fat warning sounds fair to me. Or, I suppose, we could invent a policy that applications should do all dbus related activities in a specific thread .. though that can be difficult to know as dbus calls are often hidden within libraries. .. or, does anyone have a pointer to what exactly in QDBusConnection is not thread safe? It wasn't (Qt4 times)... I have no idea if that's still the case today. It could be that this class isn't needed anymore. As for what exactly is not thread safe in QDBusConnection I don't remember. Since it was highlighted by Nepomuk at the time and forced upon us by its API (almost behind us too) Vishesh or Sebastian should know more (adding them in CC). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115827: Add KMainWindow::initialGeometrySet to increase SC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115827/ --- (Updated Feb. 21, 2014, 8:35 a.m.) Review request for KDE Frameworks. Changes --- inlined as suggested Repository: kxmlgui Description --- Add KMainWindow::initialGeometrySet to increase SC Deprecated and just returns false. Diffs (updated) - src/kmainwindow.h 7072b51fa5e9bf44703636481ea26c0e47769b52 Diff: https://git.reviewboard.kde.org/r/115827/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
