Review Request 124696: Fix (worrying) MSVC warning
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124696/ --- Review request for KDE Frameworks and Mirko Boehm. Repository: threadweaver Description --- Warning: Z:\kderoot\download\git\threadweaver\src\iddecorator.cpp(196): warning C4312: 'r einterpret_cast': conversion from 'const int' to 'ThreadWeaver::IdDecorator::Pri vate2 *' of greater size Diffs - src/iddecorator.cpp 5bf6d002eb2671a02f330cd3022e0692a0343fe4 Diff: https://git.reviewboard.kde.org/r/124696/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- (Updated Aug. 10, 2015, 6:13 a.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Changes --- Submitted with commit 38265304276e6305f72a7e1a68aa1b4193657820 by Kevin Funk to branch master. Bugs: 348061 https://bugs.kde.org/show_bug.cgi?id=348061 Repository: kdoctools Description --- BUG: 348061 Diffs - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/#review83574 --- @Luigi: Bump? - Kevin Funk On Aug. 6, 2015, 6:37 a.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- (Updated Aug. 6, 2015, 6:37 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Bugs: 348061 https://bugs.kde.org/show_bug.cgi?id=348061 Repository: kdoctools Description --- BUG: 348061 Diffs - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- (Updated Aug. 6, 2015, 6:37 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Changes --- Made requested changes Bugs: 348061 https://bugs.kde.org/show_bug.cgi?id=348061 Repository: kdoctools Description --- BUG: 348061 Diffs (updated) - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124577: Fix Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124577/ --- Review request for KDE Frameworks and Martin Klapetek. Repository: kwallet Description --- Fix Windows build Diffs - src/runtime/kwalletd/main.cpp 3e98befadb99dc81e65c7d0586f13bd1b375ad42 Diff: https://git.reviewboard.kde.org/r/124577/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124577: Fix Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124577/ --- (Updated Aug. 1, 2015, 9:34 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Klapetek. Changes --- Submitted with commit a0fcb7d7ab14f379fabf440491ce40298ec0b540 by Kevin Funk to branch master. Repository: kwallet Description --- Fix Windows build Diffs - src/runtime/kwalletd/main.cpp 3e98befadb99dc81e65c7d0586f13bd1b375ad42 Diff: https://git.reviewboard.kde.org/r/124577/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
On July 31, 2015, 8:18 a.m., David Faure wrote: src/CMakeLists.txt, line 20 https://git.reviewboard.kde.org/r/124542/diff/1/?file=388805#file388805line20 no-op? Not a no-op, this code is written into cmake_install which is used for the 'install' target. If I don't add this line I get this during 'make install': ``` (...) -- Installing: Z:/kderoot/build/frameworks/kdoctools/image-msvc2015-RelWithDebInfo-master/kderoot/share/man/man7/qt5options.7 -- Found Perl: Z:/kderoot/dev-utils/bin/perl.exe (found version 5.20.2) CMake Error at Z:/kderoot/download/git/kdoctools/cmake/uriencode.cmake:34 (find_package): By not providing FindPerlModules.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by PerlModules, but CMake did not find one. ``` (I can also push this separately) - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/#review83214 --- On July 31, 2015, 7:34 a.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- (Updated July 31, 2015, 7:34 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- BUG: 348061 Diffs - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 src/CMakeLists.txt e3868fc4f22324d25f680c13609bfb92b8b7c41d Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- (Updated July 31, 2015, 5:33 p.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Changes --- Add bug link Bugs: 348061 https://bugs.kde.org/show_bug.cgi?id=348061 Repository: kdoctools Description --- BUG: 348061 Diffs - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 src/CMakeLists.txt e3868fc4f22324d25f680c13609bfb92b8b7c41d Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 124542: CMake fixes for Windows build
On July 31, 2015, 5:19 p.m., David Faure wrote:
src/CMakeLists.txt, line 20
https://git.reviewboard.kde.org/r/124542/diff/1/?file=388805#file388805line20
I can't see how setting a variable to itself can possibly change
anything, or make any sense (other than an extremely weird bug in cmake).
Actually it could be that this interprets the string as a list or vice
versa in which case the problem could be before this, at the time where
this module sets CMAKE_MODULE_PATH (toplevel file?)
Alex Merry wrote:
See my comment above. This change is correct.
Alex Merry wrote:
Ah, and you should note the context the variable substitution takes place
in. It is being substituted in the CMakeLists.txt file, but the `set` call is
being evaluated in the install script.
That being said, there should probably be some quotes in there, like
set(CMAKE_MODULE_PATH \${CMAKE_MODULE_PATH}\)
Can do. I'll push this patch within the next hour if noone objects.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124542/#review83249
---
On July 31, 2015, 7:34 a.m., Kevin Funk wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124542/
---
(Updated July 31, 2015, 7:34 a.m.)
Review request for Documentation, KDE Frameworks and Luigi Toscano.
Repository: kdoctools
Description
---
BUG: 348061
Diffs
-
cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751
src/CMakeLists.txt e3868fc4f22324d25f680c13609bfb92b8b7c41d
Diff: https://git.reviewboard.kde.org/r/124542/diff/
Testing
---
Adding ':' to the list of escaped characters is probably not an ideal
solution, but let me hear your ideas.
Thanks,
Kevin Funk
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 124542: CMake fixes for Windows build
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124542/ --- Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- BUG: 348061 Diffs - cmake/uriencode.cmake e5f3c3acd93d3871e44b6e6fb29ad7113e18d751 src/CMakeLists.txt e3868fc4f22324d25f680c13609bfb92b8b7c41d Diff: https://git.reviewboard.kde.org/r/124542/diff/ Testing --- Adding ':' to the list of escaped characters is probably not an ideal solution, but let me hear your ideas. Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Install location of myframework_version.h headers
On Monday 04 May 2015 14:11:14 Kevin Funk wrote:
On Monday 04 May 2015 13:11:05 David Faure wrote:
On Monday 04 May 2015 12:29:39 David Faure wrote:
On Monday 04 May 2015 12:23:32 Kevin Funk wrote:
The issue could be easily fixed by moving the myframework_version.h
into
$PREFIX/include/KF5/$FRAMEWORK/, no?
Correct, this is what KArchive does.
Ooops, I thought we were talking about the generated export header.
You are right, all the version headers are in include/KF5 directly.
I think this is an oversight. Well, I did see it and didn't think it would
be a problem, but I think the only real reason I didn't move that one when
moving all other headers under $FRAMEWORK is that version headers are
installed by the toplevel CMakeLists.txt while I was working on the
CMakeLists.txt for the libs themselves.
Right, and I just noticed a problem I didn't think of before: There's no
$PREFIX/include/KF5/$myframework/ where I could install
${myframework}_version.h into for some of the frameworks :)
KConfig for instance has two libs, but only installs a single version header.
- $PREFIX/include/KF5/KConfigCore/...
- $PREFIX/include/KF5/KConfigGui/...
- $PREFIX/include/KF5/kconfig_version.h
Now in order to move kconfig_version.h to a proper location, I'd have to
install both a kconfigcore_version.h and kconfiggui_version.h to their resp.
locations:
- $PREFIX/include/KF5/KConfigCore/kconfigcore_version.h
- $PREFIX/include/KF5/KConfigGui/kconfiggui_version.h
This would make the CMake code for installing the version header quite
different for those modules, so I'm wondering how to proceed...
Cheers
I would be OK with *all* framework_version.h headers being installed under
include/KF5/$FRAMEWORK. I.e. change them all, not just one framework.
Sure.
This is SC since apps using the framework do get the include path
automatically. The only exception I can think of would be if some cmake
code was trying to locate (and possibly parse) the version.h header, but
that sounds convoluted given that there are cmake variables with the
version numbers in them already, much much more convenient to use.
In any case, do a full build of everything kf5 based (with a clean kf5
install dir) to make sure nothing breaks :-)
Alright, thanks for the insight!
Will post a review-request as soon as possible.
Thanks
Hm, just gave this a try but then stumbled upon KConfig...
There are two modules
--
Kevin Funk | kf...@kde.org | http://kfunk.org
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 123742: knewstuff: Add verbose ecm message when ECM isn't found.
On May 13, 2015, 6:45 a.m., Kevin Funk wrote: I'd reorder the code: ``` ... include(FeatureSummary) find_package(ECM ...) set_target_properties(ECM ...) feature_summary(...) ... ``` I know that it is a bit harder to script this way , but helps code readability :D Just to say, +1 from me. Better error reporting is always helpful. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80275 --- On May 13, 2015, 12:28 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- (Updated May 13, 2015, 12:28 a.m.) Review request for KDE Frameworks and Jeremy Whiting. Repository: knewstuff Description --- Make ECM missing message explain a) what ECM is, and b) where to find it. Diffs - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123742: knewstuff: Add verbose ecm message when ECM isn't found.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/#review80275 --- I'd reorder the code: ``` ... include(FeatureSummary) find_package(ECM ...) set_target_properties(ECM ...) feature_summary(...) ... ``` I know that it is a bit harder to script this way , but helps code readability :D - Kevin Funk On May 13, 2015, 12:28 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123742/ --- (Updated May 13, 2015, 12:28 a.m.) Review request for KDE Frameworks and Jeremy Whiting. Repository: knewstuff Description --- Make ECM missing message explain a) what ECM is, and b) where to find it. Diffs - CMakeLists.txt cb23ccb8a9b0421a554b41234c3d9ced3965d378 Diff: https://git.reviewboard.kde.org/r/123742/diff/ Testing --- KNewStuff (and any other framework we add these changes to) now reports the ECM url and name when it isn't found at cmake time. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Install location of myframework_version.h headers
Heya, I'm wondering why, for instance, ktexteditor_version.h is installed to $PREFIX/include/KF5 instead of $PREFIX/include/KF5/KTextEditor. This currently leads to confusing behavior when trying to include this header if two versions of KTextEditor are installed in different locations. Suppose the two KTE installs: 1) /usr/include/KF5/ktexteditor_version.h 2) /home/kfunk/devel/install/kf5/include/KF5/ktexteditor_version.h Now when including this header in one of my source files (1) is picked up although CMake found KTextEditor from (2). And this is because the CMake config files always append /usr/include/KF5 in INTERFACE_INCLUDE_DIRECTORIES for all frameworks. The compiler invocation looks like this: /usr/lib/ccache/c++ ... -isystem /usr/include/KF5/ThreadWeaver -isystem /usr/include/KF5 -isystem ... -isystem /home/kfunk/devel/install/kf5/include/KF5/KTextEditor ... -c /home/kfunk/devel/src/kf5/extragear/kdevelop/kdevplatform/language/codegen/applychangeswidget.cpp (The first framework implicitly pulls in /usr/include/KF5) Now you could say this is wrong b/c I'm using both distro packages and self- compiled versions of frameworks. -- Is it? The issue could be easily fixed by moving the myframework_version.h into $PREFIX/include/KF5/$FRAMEWORK/, no? Greets -- Kevin Funk | kf...@kde.org | http://kfunk.org 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: Install location of myframework_version.h headers
On Monday, May 04, 2015 12:23:32 Kevin Funk wrote: Heya, I'm wondering why, for instance, ktexteditor_version.h is installed to $PREFIX/include/KF5 instead of $PREFIX/include/KF5/KTextEditor. This currently leads to confusing behavior when trying to include this header if two versions of KTextEditor are installed in different locations. Suppose the two KTE installs: 1) /usr/include/KF5/ktexteditor_version.h 2) /home/kfunk/devel/install/kf5/include/KF5/ktexteditor_version.h Now when including this header in one of my source files (1) is picked up although CMake found KTextEditor from (2). And this is because the CMake config files always append /usr/include/KF5 in INTERFACE_INCLUDE_DIRECTORIES for all frameworks. More specific: Frameworks which have been installed into /usr pull in /usr/include/KF5, of course. The compiler invocation looks like this: /usr/lib/ccache/c++ ... -isystem /usr/include/KF5/ThreadWeaver -isystem /usr/include/KF5 -isystem ... -isystem /home/kfunk/devel/install/kf5/include/KF5/KTextEditor ... -c /home/kfunk/devel/src/kf5/extragear/kdevelop/kdevplatform/language/codegen/a pplychangeswidget.cpp (The first framework implicitly pulls in /usr/include/KF5) Now you could say this is wrong b/c I'm using both distro packages and self- compiled versions of frameworks. -- Is it? The issue could be easily fixed by moving the myframework_version.h into $PREFIX/include/KF5/$FRAMEWORK/, no? Greets -- Kevin Funk | kf...@kde.org | http://kfunk.org 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: Install location of myframework_version.h headers
On Monday 04 May 2015 13:11:05 David Faure wrote: On Monday 04 May 2015 12:29:39 David Faure wrote: On Monday 04 May 2015 12:23:32 Kevin Funk wrote: The issue could be easily fixed by moving the myframework_version.h into $PREFIX/include/KF5/$FRAMEWORK/, no? Correct, this is what KArchive does. Ooops, I thought we were talking about the generated export header. You are right, all the version headers are in include/KF5 directly. I think this is an oversight. Well, I did see it and didn't think it would be a problem, but I think the only real reason I didn't move that one when moving all other headers under $FRAMEWORK is that version headers are installed by the toplevel CMakeLists.txt while I was working on the CMakeLists.txt for the libs themselves. I would be OK with *all* framework_version.h headers being installed under include/KF5/$FRAMEWORK. I.e. change them all, not just one framework. Sure. This is SC since apps using the framework do get the include path automatically. The only exception I can think of would be if some cmake code was trying to locate (and possibly parse) the version.h header, but that sounds convoluted given that there are cmake variables with the version numbers in them already, much much more convenient to use. In any case, do a full build of everything kf5 based (with a clean kf5 install dir) to make sure nothing breaks :-) Alright, thanks for the insight! Will post a review-request as soon as possible. Thanks -- Kevin Funk | kf...@kde.org | http://kfunk.org 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: Versioning of Frameworks
On Wednesday, April 29, 2015 21:43:20 David Faure wrote: On Wednesday 29 April 2015 11:24:48 Kevin Funk wrote: Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) If this contributor was trying to fix a bug in a Qt module, he would experience the exact same thing. QtAnything 5.5 cannot be compiled with QtBase 5.2. I'm fairly sure you can; let's say build QtWebChannel 5.6 (dev) against QtBase 5.4.1. In fact, I just tried again and it worked just fine. QMake did not complain. Sometimes it's interesting to keep the version of the dependencies and just play around with the version of the module you're interested into, in order to evaluate changes in behavior of your module. By that, you can rule out modifications in your *dependencies* did cause these changes in behavior in your module. I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... So do you also think that Qt failed with the module split ? I disagree. The point (both for Qt and for Frameworks) is that any app can decide to use only what they need. Having to use up-to-date enough versions of the dependent modules does not defeat that purpose. I can clearly see that lifting the restriction of having up-to-date versions of your dependencies creates a version zoo as you say. It's untestable b/c of the potential combinations and clearly doesn't make the maintainer's job easier. However, I think it could be helpful to be able to build master branch of $MODULE against a stable version of its dependencies for *development purposes*, which currently isn't possible. That doesn't mean we should encourage distros to ship a mix of KF5 package versions, obviously. They should continue to ship KF5 with identical versions for each of the frameworks. @David: Didn't stress that enough, but huge thanks for taking care of the KF5 releases! Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org 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: Versioning of Frameworks
On Tuesday, April 28, 2015 12:17:00 Christian Mollekopf wrote: Hey, For the Kolab Groupware Server we use some KDE libraries on the server. Servers being what they are, the libraries we require are often not available by default because the systems are too old, and we end-up backporting what we need. To make this feasible in pre-framework times I had to create a copy-paste monster that contained all the libraries we required, and stripped everything we didn't, to keep the dependency tree at a manageable level (so we don't end up updating some 100+ packages). Now with frameworks, we are finally in the position to get rid of this, but as far as I understand, at least some frameworks are in version-lock with each other, which seems to defeat at least parts of the benefits. Our dependency tree is now indeed reduced, but if we want to update a single library, we are forced to update all libraries, due to the version-lock caused by periodic bumping of dependencies. This comes at significant cost if we have to backport all packages. Ideally framework-libraries should IMO be versioned as any other library that I know of, which is bumping numbers as changes happen. Similarly, requirements are bumped as the requirements increase, making it entirely possible that some low-level libraries can remain the same while others are updated. My favorite versioning scheme is the one explained here [0] (major.minor.teeny with minor for features, and teeny for bugfixes), which is almost what we do, since we already use the major version-number to indicate API incompatibilities. But currently the versions are just used to time-stamp the releases. I think our requirements can be split into two parts: * No automatic version-bumping of dependencies: This harms us the most because it forces us to update everything when updating something. It's not a problem in Tier1 frameworks, but I've seen some doing it (khtml), so I hope it's not a policy and we can do it differently in PIM. Just to give my +1 I also think this is a big issue. Use-case: Potential contributor working on KDevelop: - Has KF5 installed from distro packages - KDevelop/KDevPlatform compiled from Git - There's a bug in ktexteditor (tier 3) - Likes to checkout just ktexteditor, fix the issue, compile, install and use it Well, this doesn't work b/c ktexteditor master usually depends on a too recent version of its dependencies. So there are two options to still compile ktexteditor: a) Compile the complete KF5 set, master branch (exhausting) b) Hack CMakeLists.txt and change KF5_DEP_VERSION (quick dirty way) I also think this somehow defeats the purpose of the splitting we've done when you still have to make sure versions of the individual frameworks have to be identical... Greets * A version number that follows changes and not time: As I understand version numbers are currently bumped periodically because we anyways lack the manpower for release-management, and since changes usually happen, the version is just periodically bumped before each release. This seems to prevent release-management to happen though, where the version number is a vital tool for planning what ends up in what version. So my question would be whether we could move certain frameworks from that time-boxing model to a feature-boxing model, allowing the releases to be somewhat planned. I assume the current versioning is happening so noone has to maintain the individual version-numbers, so the question becomes whether it would break anything moving partially away from that. Initially I'd like to stop the automatic dependency bumping, the rest can IMO wait some more, that's something that can be solved on the PIM side, but I need to know if there are policies regarding that, or if some frameworks just choose to do that out of laziness (aka lack of manpower). The release-management I'd try first on kimap, which is not yet a framework, and where I'm maintainer, so my question would be whether you somehow rely on all frameworks have the same version, and how we could fix that. If it goes well with kimap, I'd then just approach the individual maintainers. It's of course quite possible that I don't understand the requirements of others, so I'm interested to hear about that as well =) Cheers, Christian [0] http://semver.org/ Our dependency tree is roughly (it's currently larger, but we should be able to get it down to that): * PIM (not yet part of frameworks) ** KCalendarCore ** KCalendarUtils ** KMIME ** KIMAP ** KContacts * Current Frameworks ** ECM ** KCoreAddons ** KConfig ** KI18n ** KDELibs4Support ** KCodecs ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part
Re: Review Request 123491: Add a test that checks the modules we're depending on exist
On April 24, 2015, 3:49 p.m., Kevin Funk wrote:
modules/ECMGeneratePriFile.cmake, line 180
https://git.reviewboard.kde.org/r/123491/diff/2/?file=362992#file362992line180
Just tested the patch myself on sonnet.
The test indeed breaks if sonnet is not installed beforehand. But I
agree, that's probably not a big issue since we usually have to install
before running `make test`.
Not having the right `QMAKEPATH` set during the test run imposes
another burden on the user, however.
What about adding:
```
set_tests_properties(... PROPERTIES
ENVIRONMENT
QMAKEPATH=${qt_host_data_dir}
```
Kevin Funk wrote:
Err, wrong. I meant `QMAKEPATH=${CMAKE_INSTALL_PREFIX}`. This is the case
where it breaks, of course.
Albert Astals Cid wrote:
don't think we should workaround the user having the wrong environment,
we're getting the qmake path from another ecm module, so either fix that one
or accept your env is broken :D
Who says it's broken or even wrong? If `QMAKEPATH` is unset, then the user just
doesn't care about the extra Qt modules installed into the install prefix. And
he/she shouldn't need to worry about it as long as qmake isn't the build system
of choice.
Reducing the set of env vars needed to work on KDE is a good thing, too :)
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79460
---
On April 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---
(Updated April 24, 2015, 3:26 p.m.)
Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
Repository: extra-cmake-modules
Description
---
Do some sanity checking on the dependencies we're declaring
Diffs
-
modules/ECMGeneratePriFile.cmake af4b877
Diff: https://git.reviewboard.kde.org/r/123491/diff/
Testing
---
Ran make test in ktextwidgets without
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
and it correctly failed.
Thanks,
Albert Astals Cid
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123452: Expose KJob::capabilities property
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123452/#review79421 --- Ship it! Ship It! - Kevin Funk On April 21, 2015, 4:24 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123452/ --- (Updated April 21, 2015, 4:24 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Makes it possible to figure out from QML if a KJob is Killable. Diffs - src/lib/jobs/kjob.h c95970c Diff: https://git.reviewboard.kde.org/r/123452/diff/ Testing --- Tested it over in Kamoso. 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 123491: Add a test that checks the modules we're depending on exist
On April 24, 2015, 3:49 p.m., Kevin Funk wrote:
modules/ECMGeneratePriFile.cmake, line 180
https://git.reviewboard.kde.org/r/123491/diff/2/?file=362992#file362992line180
Just tested the patch myself on sonnet.
The test indeed breaks if sonnet is not installed beforehand. But I
agree, that's probably not a big issue since we usually have to install
before running `make test`.
Not having the right `QMAKEPATH` set during the test run imposes
another burden on the user, however.
What about adding:
```
set_tests_properties(... PROPERTIES
ENVIRONMENT
QMAKEPATH=${qt_host_data_dir}
```
Err, wrong. I meant `QMAKEPATH=${CMAKE_INSTALL_PREFIX}`. This is the case where
it breaks, of course.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79460
---
On April 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---
(Updated April 24, 2015, 3:26 p.m.)
Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
Repository: extra-cmake-modules
Description
---
Do some sanity checking on the dependencies we're declaring
Diffs
-
modules/ECMGeneratePriFile.cmake af4b877
Diff: https://git.reviewboard.kde.org/r/123491/diff/
Testing
---
Ran make test in ktextwidgets without
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
and it correctly failed.
Thanks,
Albert Astals Cid
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123491: Add a test that checks the modules we're depending on exist
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79460
---
modules/ECMGeneratePriFile.cmake (line 179)
https://git.reviewboard.kde.org/r/123491/#comment54303
Just tested the patch myself on sonnet.
The test indeed breaks if sonnet is not installed beforehand. But I agree,
that's probably not a big issue since we usually have to install before running
`make test`.
Not having the right `QMAKEPATH` set during the test run imposes another
burden on the user, however.
What about adding:
```
set_tests_properties(... PROPERTIES
ENVIRONMENT
QMAKEPATH=${qt_host_data_dir}
```
- Kevin Funk
On April 24, 2015, 3:26 p.m., Albert Astals Cid wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---
(Updated April 24, 2015, 3:26 p.m.)
Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
Repository: extra-cmake-modules
Description
---
Do some sanity checking on the dependencies we're declaring
Diffs
-
modules/ECMGeneratePriFile.cmake af4b877
Diff: https://git.reviewboard.kde.org/r/123491/diff/
Testing
---
Ran make test in ktextwidgets without
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
and it correctly failed.
Thanks,
Albert Astals Cid
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123491: Add a test that checks the modules we're depending on exist
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/#review79452
---
Ship it!
modules/ECMGeneratePriFile.cmake (line 174)
https://git.reviewboard.kde.org/r/123491/#comment54298
Rather: `${PRI_TARGET_BASENAME}_test.pro`?
(Uses the correct suffix)
- Kevin Funk
On April 24, 2015, 2:53 p.m., Albert Astals Cid wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123491/
---
(Updated April 24, 2015, 2:53 p.m.)
Review request for Extra Cmake Modules, KDE Frameworks and Kevin Funk.
Repository: extra-cmake-modules
Description
---
Do some sanity checking on the dependencies we're declaring
Diffs
-
modules/ECMGeneratePriFile.cmake af4b877
Diff: https://git.reviewboard.kde.org/r/123491/diff/
Testing
---
Ran make test in ktextwidgets without
http://quickgit.kde.org/?p=ktextwidgets.gita=commitdiffh=b83617d59b14941b1e26d295e9ea300301365321
and it correctly failed.
Thanks,
Albert Astals Cid
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123229: Ensure we don't crash when using KIO from non-QApplication process
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123229/#review78665 --- src/widgets/jobuidelegate.cpp (line 391) https://git.reviewboard.kde.org/r/123229/#comment53832 You could use http://doc.qt.io/qt-5/qcoreapplication.html#Q_COREAPP_STARTUP_FUNCTION + a queued method invocation to make sure `QApplication` was fully constructed. - Kevin Funk On April 7, 2015, 1:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123229/ --- (Updated April 7, 2015, 1:46 p.m.) Review request for KDE Frameworks. Repository: kio Description --- Prevents the UiDelegate and UiTracker to get initialized, because they'll try to create windows and dialogs when some things happen and these will immediately end in a crash. Diffs - src/widgets/jobuidelegate.cpp 7df289f src/widgets/kdynamicjobtracker.cpp 9bc4a4e Diff: https://git.reviewboard.kde.org/r/123229/diff/ Testing --- Ran the tests, my unit test doesn't crash anymore. 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 122910: Introduce KMoreTools
On March 15, 2015, 10:31 a.m., Dominik Haumann wrote: src/kmoretools/kmoretools.h, line 412 https://git.reviewboard.kde.org/r/122910/diff/1/?file=354447#file354447line412 Qt API never returns a this pointer when settings some properties. While not explicitely stated here, these links may be useful: - http://qt-project.org/wiki/API-Design-Principles - http://kate-editor.org/2011/08/28/coding-style-and-api-design/ For me, this function should be: void setInitialItemText(const QString itemText); Gregor Mi wrote: First of all thanks for the detailled review. About not returning 'this': I was thinking about the Fluent Interface API design principle (https://en.wikipedia.org/wiki/Fluent_interface). But I agree with you: I also did not see it in other code I read so far and I understand the arguments. Can I conclude that there is no QT equivalent and the better practice here is to write a new line for each setter statement? Yes, don't return `this`. One notable exception in Qt is QString::arg, which can be chained. However, in general it's not used in Qt, because of increased complexity when debugging such code (just see section Problems in the wiki article you've just mentioned). - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122910/#review77502 --- On March 11, 2015, 11:06 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122910/ --- (Updated March 11, 2015, 11:06 p.m.) Review request for KDE Frameworks, Emmanuel Pescosta and Jeremy Whiting. Repository: knewstuff Description --- Moved from kservice (https://git.reviewboard.kde.org/r/122576/) to here (knewstuff). Example usages: - dolphin's SpaceInfoToolsMenu: https://git.reviewboard.kde.org/r/122911/ - kate's project addin: https://git.reviewboard.kde.org/r/122374/ Diffs - src/CMakeLists.txt 3b9a403eb473e0c3760506b2757c71d603b99775 src/kmoretools/kmoretools.h PRE-CREATION src/kmoretools/kmoretools.cpp PRE-CREATION src/kmoretools/kmoretools_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.h PRE-CREATION src/kmoretools/kmoretoolsconfigdialog_p.cpp PRE-CREATION src/kmoretools/ui/kmoretoolsconfigwidget.ui PRE-CREATION tests/CMakeLists.txt 103c5fc98deaf83288b843cc66a87f2d95ad9dfb tests/kmoretools/1/a.desktop PRE-CREATION tests/kmoretools/1/b.desktop PRE-CREATION tests/kmoretools/1/c.desktop PRE-CREATION tests/kmoretools/2/kate.desktop PRE-CREATION tests/kmoretools/2/kate.png PRE-CREATION tests/kmoretools/2/mynotinstalledapp.desktop PRE-CREATION tests/kmoretools/2/mynotinstalledapp.png PRE-CREATION tests/kmoretools/kmoretoolstest.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122910/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 122613: Do not add an extra slash if item does not have a host (KUrlComboBoxPrivate::textForItem)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/#review76245 --- autotests/kurlcomboboxtest.cpp https://git.reviewboard.kde.org/r/122613/#comment52571 Name? :) autotests/kurlcomboboxtest.cpp https://git.reviewboard.kde.org/r/122613/#comment52569 Never used autotests/kurlcomboboxtest.cpp https://git.reviewboard.kde.org/r/122613/#comment52570 Never used autotests/kurlcomboboxtest.cpp https://git.reviewboard.kde.org/r/122613/#comment52572 Just create on the stack? - Kevin Funk On Feb. 17, 2015, 10:29 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122613/ --- (Updated Feb. 17, 2015, 10:29 p.m.) Review request for KDE Frameworks. Repository: kio Description --- The rest of kio internally is doing this correctly apparently it was only a problem in the GUI part of it. Diffs - autotests/CMakeLists.txt f613c1a autotests/kurlcomboboxtest.h PRE-CREATION autotests/kurlcomboboxtest.cpp PRE-CREATION src/widgets/kurlcombobox.cpp ed5b8a2 Diff: https://git.reviewboard.kde.org/r/122613/diff/ Testing --- Besides the added unit tests, I have used this patch while running a few ups, everything seems to work great. Thanks, Àlex Fiestas ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kde-baseapps fails to build for branch-group stable-kf5-qt5
On Friday 13 February 2015 21:56:42 Ben Cooksley wrote:
On Fri, Feb 13, 2015 at 9:52 PM, Kevin Funk kf...@kde.org wrote:
On Friday 13 February 2015 08:49:10 Marko Käning wrote:
Hi Albert,
I just realised that kde-baseapps fails on OSX/CI when being build for
branch group stable-kf5-qt5:
--
Group: stable-kf5-qt5
Project : kde/applications/kde-baseapps
Branch : Applications/14.12
Linux-CI : UNSTABLE
OSX/CI : FAILURE
Prep...
Build... : BUILD FAILED
==
This I find in the build log:
---
-- The C compiler identification is AppleClang 6.0.0.656
-- The CXX compiler identification is AppleClang 6.0.0.656
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at
/opt/kde/install/darwin/mavericks/clang/shared/general/cmake/share/cmake-
3.
1/Modules/FindKDE4.cmake:71 (message): ERROR: Could not find KDE4
kde4-config
Call Stack (most recent call first):
CMakeLists.txt:10 (find_package)
You're quite obviously on the wrong branch in kde-baseapps.git.
You're probably on master (KDE4-based), while you should be on frameworks
(KF5-based).
This means the build metadata for kde-baseapps is incorrect.
It is the responsibility of developers to maintain this metadata, as
those who maintain kdesrc-build, the CI system and make releases
cannot be expected to do so with the number of repositories and
projects we have.
Sorry, I've been a bit scarce about information here.
Indeed, the kde/* rule in 'logical-module-structure' is wrong already:
kde/* : {
stable-qt4: Applications/14.12,
latest-qt4: master,
kf5-qt5: frameworks,
stable-kf5-qt5: Applications/14.12
},
Both stable-qt4 and stable-kf5-qt5 point Applications/14.12 -- which is not
what we want. Can someone fix? (short in time atm)
Regards
CMake Warning (dev) in CMakeLists.txt:
No cmake_minimum_required command is present. A line of code such as
cmake_minimum_required(VERSION 3.1)
should be added at the top of the file. The version specified may be
lower if you wish to support older CMake versions for this project. For
more information run cmake --help-policy CMP.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring incomplete, errors occurred!
See also
/Users/marko/WC/KDECI-builds/stable-kf5-qt5/kde-baseapps/build/CMakeFile
s/
CMakeOutput.log.
KDE Continuous Integration Build
== Building Project: kde-baseapps - Branch Applications/14.12
---
Any idea what goes wrong?
Regards,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Regards,
Ben
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
Kevin Funk | kf...@kde.org | http://kfunk.org
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 122542: All frameworks: Add Q_DECL_OVERRIDE where needed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/ --- (Updated Feb. 13, 2015, 12:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Description --- This is a huge patch (almost 30 000 lines) covering all frameworks. This was done using clang-modernize and a few wrapper scripts. If you'll give me the okay, I'll push this to the individual frameworks. Diffs - Diff: https://git.reviewboard.kde.org/r/122542/diff/ Testing --- Compiles fine on my machine. File Attachments frameworks-add-override.patch https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/97a4c658-1517-4ab8-88ee-f76c09146393__frameworks-add-override.patch Without 'virtual' https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/8c42d21f-6a7b-496f-addf-757cb45dbc77__frameworks-add-override.patch Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122551: New feature: Open all recent files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122551/#review75958 --- You're aware that Kate (and any other decent editor) has session management which probably solves your issue? It saves the session when you close it, and re-opens all the files that had been opened. - Kevin Funk On Feb. 12, 2015, 11:56 p.m., Thomas Murach wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122551/ --- (Updated Feb. 12, 2015, 11:56 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- I've always been looking for a feature (mostly in Kate et al.) to open all recently opened files at once. Every once in a while I think I'm done with some source code editing, realise that I'm not, and then have to click through all files one by one. With this patch opening all files at once gets possible. So much for the background. Still there are some open questions: 1) Is such a feature wanted at all? 2) Is the code quality/style ok? 3) Last but not least: This patch will work nicely with kate, presumably also with okular and some others, but I guess it will not work as expected with Kaffeine, for example, as new files which are to be opened will not get appended to a playlist but instead each file will get opened for an instance and then be replaced by the next opened file. Possible solutions: In principle it would be possible to add another signal passing a list of URLs to applications, which then have to define a suitable slot. Alternatively this patch could just not be applied and the feature I'm trying to introduce could be added to kate only... (I don't prefer that option ;) ) So, what are your opinions, comments, ideas? Thanks in advance! PS I hope the reviewer group kdeframeworks is the right one... Diffs - src/krecentfilesaction.h 06965d4 src/krecentfilesaction.cpp 40fdf93 src/krecentfilesaction_p.h 2c690a7 Diff: https://git.reviewboard.kde.org/r/122551/diff/ Testing --- I don't run KF5 on a daily basis, but in a Docker session the patch works nicely with Kate. Thanks, Thomas Murach ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122542: All frameworks: Add Q_DECL_OVERRIDE where needed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/ --- Review request for KDE Frameworks. Description --- This is a huge patch (almost 30 000 lines) covering all frameworks. This was done using clang-modernize and a few wrapper scripts. If you'll give me the okay, I'll push this to the individual frameworks. Diffs - Diff: https://git.reviewboard.kde.org/r/122542/diff/ Testing --- Compiles fine on my machine. File Attachments frameworks-add-override.patch https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/97a4c658-1517-4ab8-88ee-f76c09146393__frameworks-add-override.patch Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122539: Use Q_DECL_OVERRIDE where possible
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122539/ --- (Updated Feb. 12, 2015, 12:54 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- With -Winconsistent-missing-override (Clang), headers from KConfig are throwing a lot of warnings. Diffs - src/core/kconfig.h 0fb15756ec9d089b956ebc9eb3eeade0a76cf7c1 src/core/kconfiggroup.h abb246e37619bcead938a0496eac51f6afff5ec4 src/core/kconfigini_p.h 29f61090df99bf66fdccdb0a1801dbeaec1c6c0f src/core/kcoreconfigskeleton.h bb3d0f61adbfe95077fce759bb437ae7a13856be src/core/ksharedconfig.h b2317afd6d5189e6364acc989bc9ca7a5694248d src/gui/kconfigloader.h aadb19a5b266f4c1ccd07d4b05af0dcbd2686bd9 src/gui/kconfigloaderhandler_p.h 1c7c5a1d3c79a7e98a53245d1037be0b253dc135 src/gui/kconfigskeleton.h 4cd8d140535bb550af8b934a746e2a8ffc0ec008 Diff: https://git.reviewboard.kde.org/r/122539/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122542: All frameworks: Add Q_DECL_OVERRIDE where needed
On Feb. 12, 2015, 2:53 p.m., Albert Astals Cid wrote: Is your script smart enough to convert virtual QByteArray data() const; into QByteArray data() const Q_DECL_OVERRIDE; instead of virtual QByteArray data() const Q_DECL_OVERRIDE; Nope. It only deals with 'override'. But in this case I could easily do sth along s/virtual// in the *diff*. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/#review75924 --- On Feb. 12, 2015, 2:43 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/ --- (Updated Feb. 12, 2015, 2:43 p.m.) Review request for KDE Frameworks. Description --- This is a huge patch (almost 30 000 lines) covering all frameworks. This was done using clang-modernize and a few wrapper scripts. If you'll give me the okay, I'll push this to the individual frameworks. Diffs - Diff: https://git.reviewboard.kde.org/r/122542/diff/ Testing --- Compiles fine on my machine. File Attachments frameworks-add-override.patch https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/97a4c658-1517-4ab8-88ee-f76c09146393__frameworks-add-override.patch Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122542: All frameworks: Add Q_DECL_OVERRIDE where needed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/ --- (Updated Feb. 12, 2015, 3:47 p.m.) Review request for KDE Frameworks. Changes --- New patch, removing 'virtual' from decls Description --- This is a huge patch (almost 30 000 lines) covering all frameworks. This was done using clang-modernize and a few wrapper scripts. If you'll give me the okay, I'll push this to the individual frameworks. Diffs - Diff: https://git.reviewboard.kde.org/r/122542/diff/ Testing --- Compiles fine on my machine. File Attachments (updated) frameworks-add-override.patch https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/97a4c658-1517-4ab8-88ee-f76c09146393__frameworks-add-override.patch Without 'virtual' https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/8c42d21f-6a7b-496f-addf-757cb45dbc77__frameworks-add-override.patch Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122542: All frameworks: Add Q_DECL_OVERRIDE where needed
On Feb. 12, 2015, 4:43 p.m., Albert Astals Cid wrote: It also adds a Q_DECL_OVERRIDE to a Q_DECL_FINAL which is not needed since final will already complain if trying to finalize something that is not overriding a virtual of the parent, no? Nitpicker! :D Fixed that one occurence, but won't upload the patch again. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/#review75928 --- On Feb. 12, 2015, 3:47 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122542/ --- (Updated Feb. 12, 2015, 3:47 p.m.) Review request for KDE Frameworks. Description --- This is a huge patch (almost 30 000 lines) covering all frameworks. This was done using clang-modernize and a few wrapper scripts. If you'll give me the okay, I'll push this to the individual frameworks. Diffs - Diff: https://git.reviewboard.kde.org/r/122542/diff/ Testing --- Compiles fine on my machine. File Attachments frameworks-add-override.patch https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/97a4c658-1517-4ab8-88ee-f76c09146393__frameworks-add-override.patch Without 'virtual' https://git.reviewboard.kde.org/media/uploaded/files/2015/02/12/8c42d21f-6a7b-496f-addf-757cb45dbc77__frameworks-add-override.patch Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122514: Make it possible to interpret properties from plugins that expose properties correctly in the json
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/#review75879 --- Ship it! LGTM. - Kevin Funk On Feb. 11, 2015, 5:45 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/ --- (Updated Feb. 11, 2015, 5:45 p.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kservice Description --- Currently it checks whether it's a stringlist value according to the servicetype (good) and splits the ','. What this patch does is to allow plugins to use json lists to specify string list properties. For example: X-KDevelop-Interfaces: [ IBuildSystemManager, IProjectFileManager] Otherwise I was getting invalid values and nothing worked. Diffs - autotests/kplugininfotest.cpp d99b92a src/services/kplugininfo.cpp 572f14b Diff: https://git.reviewboard.kde.org/r/122514/diff/ Testing --- Builds, tests still pass. Now KDevelop boots correctly, I tried to add a test, but I don't know where's the service type file for KService/NSA. 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 122514: Make it possible to interpret properties from plugins that expose properties correctly in the json
On Feb. 11, 2015, 3:35 p.m., Kevin Funk wrote: src/services/kplugininfo.cpp, line 574 https://git.reviewboard.kde.org/r/122514/diff/1/?file=348194#file348194line574 Style: Space after keyword, more below. Wrong line, sorry. But you know what I mean :) - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/#review75866 --- On Feb. 10, 2015, 5:18 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/ --- (Updated Feb. 10, 2015, 5:18 p.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kservice Description --- Currently it checks whether it's a stringlist value according to the servicetype (good) and splits the ','. What this patch does is to allow plugins to use json lists to specify string list properties. For example: X-KDevelop-Interfaces: [ IBuildSystemManager, IProjectFileManager] Otherwise I was getting invalid values and nothing worked. Diffs - src/services/kplugininfo.cpp 572f14b Diff: https://git.reviewboard.kde.org/r/122514/diff/ Testing --- Builds, tests still pass. Now KDevelop boots correctly, I tried to add a test, but I don't know where's the service type file for KService/NSA. 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 122514: Make it possible to interpret properties from plugins that expose properties correctly in the json
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/#review75866 --- Ship it! Code looks good to me. Unit test would be *very* good, though. src/services/kplugininfo.cpp https://git.reviewboard.kde.org/r/122514/#comment52373 Style: Space after keyword, more below. - Kevin Funk On Feb. 10, 2015, 5:18 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122514/ --- (Updated Feb. 10, 2015, 5:18 p.m.) Review request for KDE Frameworks, Alex Richardson and David Faure. Repository: kservice Description --- Currently it checks whether it's a stringlist value according to the servicetype (good) and splits the ','. What this patch does is to allow plugins to use json lists to specify string list properties. For example: X-KDevelop-Interfaces: [ IBuildSystemManager, IProjectFileManager] Otherwise I was getting invalid values and nothing worked. Diffs - src/services/kplugininfo.cpp 572f14b Diff: https://git.reviewboard.kde.org/r/122514/diff/ Testing --- Builds, tests still pass. Now KDevelop boots correctly, I tried to add a test, but I don't know where's the service type file for KService/NSA. 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 122539: Use Q_DECL_OVERRIDE where possible
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122539/#review75893 --- Note: I can easily script this to run on all frameworks. Please tell me if it's desired and I'll go ahead. - Kevin Funk On Feb. 11, 2015, 11:19 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122539/ --- (Updated Feb. 11, 2015, 11:19 p.m.) Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- With -Winconsistent-missing-override (Clang), headers from KConfig are throwing a lot of warnings. Diffs - src/core/kconfig.h 0fb15756ec9d089b956ebc9eb3eeade0a76cf7c1 src/core/kconfiggroup.h abb246e37619bcead938a0496eac51f6afff5ec4 src/core/kconfigini_p.h 29f61090df99bf66fdccdb0a1801dbeaec1c6c0f src/core/kcoreconfigskeleton.h bb3d0f61adbfe95077fce759bb437ae7a13856be src/core/ksharedconfig.h b2317afd6d5189e6364acc989bc9ca7a5694248d src/gui/kconfigloader.h aadb19a5b266f4c1ccd07d4b05af0dcbd2686bd9 src/gui/kconfigloaderhandler_p.h 1c7c5a1d3c79a7e98a53245d1037be0b253dc135 src/gui/kconfigskeleton.h 4cd8d140535bb550af8b934a746e2a8ffc0ec008 Diff: https://git.reviewboard.kde.org/r/122539/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122539: Use Q_DECL_OVERRIDE where possible
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122539/ --- Review request for KDE Frameworks and Matthew Dawson. Repository: kconfig Description --- With -Winconsistent-missing-override (Clang), headers from KConfig are throwing a lot of warnings. Diffs - src/core/kconfig.h 0fb15756ec9d089b956ebc9eb3eeade0a76cf7c1 src/core/kconfiggroup.h abb246e37619bcead938a0496eac51f6afff5ec4 src/core/kconfigini_p.h 29f61090df99bf66fdccdb0a1801dbeaec1c6c0f src/core/kcoreconfigskeleton.h bb3d0f61adbfe95077fce759bb437ae7a13856be src/core/ksharedconfig.h b2317afd6d5189e6364acc989bc9ca7a5694248d src/gui/kconfigloader.h aadb19a5b266f4c1ccd07d4b05af0dcbd2686bd9 src/gui/kconfigloaderhandler_p.h 1c7c5a1d3c79a7e98a53245d1037be0b253dc135 src/gui/kconfigskeleton.h 4cd8d140535bb550af8b934a746e2a8ffc0ec008 Diff: https://git.reviewboard.kde.org/r/122539/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
On Feb. 9, 2015, 12:59 a.m., Mark Gaiser wrote: -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 Ivan Čukić wrote: I'm torn on this one. This is a minor edit (mainly thinking about the potential qRound version) that would fix the current master to work with an old platform. Without having any downsides (apart from possible future depreciacion of qRound). But, on the other hand, something else will probably be brought in soon that will require some more essential c++11 things, and break on osx 10.7. So, one wonders whether a patch that just prolongs the inevitable has a purpose. :) Not sure if it's worth discussion this issue a lot... `qRound` isn't deprecated yet, used a lot throughout frameworks, and it doesn't look like it will be deprecated (I've yet to see a discussion on the Qt ML about this). Yet `qRound` is way more pleasant to read than `static_castint(...)`. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75645 --- Why not port to `http://doc.qt.io/qt-5/qprocessenvironment.html#systemEnvironment` instead? Looks like you could get rid off the string conversion/parsing here. - Kevin Funk On Feb. 8, 2015, 10:06 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 10:06 p.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75646 --- `qRound`? - Kevin Funk On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122359: Create an uninstall target by default in KDE projects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122359/#review75342 --- Ship it! Looks good to me, but I'll wait for some others giving their +1, too modules/ecm_uninstall.cmake.in https://git.reviewboard.kde.org/r/122359/#comment52112 I'd remove the text inside the condition of `elseif`, `endif` and `endforeach` (I know it is copied code, but still ...) - Kevin Funk On Feb. 3, 2015, 8:19 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122359/ --- (Updated Feb. 3, 2015, 8:19 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Add a module to provide an uninstall target. This is basically just the code available on the CMake FAQ item about `make uninstall`, but packaged up in a convenient module. Create an uninstall target by default in KDE projects. Diffs - docs/module/ECMUninstallTarget.rst PRE-CREATION kde-modules/KDECMakeSettings.cmake 4ccbf82eaf54d6777a8c2296aea4b77e0d1292cb modules/ECMUninstallTarget.cmake PRE-CREATION modules/ecm_uninstall.cmake.in PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122359/diff/ Testing --- Checked with KCoreAddons. 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 122204: Mark results as required.
On Jan. 22, 2015, 11:11 p.m., Aleix Pol Gonzalez wrote: +1 This change is not source-compatible though... 8-) or is it? Milian Wolff wrote: It's _meant_ to be source-incompatible. All places where it doesn't compile are doing it wrong™. If you mean abi-incompatible, then no - I don't think this changes the mangled name and thus anything while linking. I might be wrong though. Aleix Pol Gonzalez wrote: I know it's meant to do that, but we're still supposed to be source compatible. I don't think it would be very nice that there's some (broken) software that uses KF5 that can't be compiled anymore. I'm not against introducing this, BTW, I think it's a nice help, just wanted to highlight it because I think it's important to know what people would think about this. This will just warn by default, though -- at least true for GCC. IMO, it's still worth it, given that using the i18n API can easily lead to no-ops in code (I've been there myself). This doesn't affect the mangling either = ABI compatible - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122204/#review74568 --- On Jan. 22, 2015, 6:34 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122204/ --- (Updated Jan. 22, 2015, 6:34 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- This prevents API misuage, similar to how QString::arg is doing it. See also: http://quickgit.kde.org/?p=kdevplatform.gita=commith=078f1cd584e2de75ad19c46282b47dd1e0feff8f Diffs - src/klocalizedstring.h 8e8e84926b444150e00c80b3b77766ba16e03e25 Diff: https://git.reviewboard.kde.org/r/122204/diff/ Testing --- Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122105: Fix KgDifficulty saving on app close
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122105/#review74330 --- Can't you `Q_ASSERT(qApp)` in `KSharedConfig::openConfig()` in order to make sure people don't do that? - Kevin Funk On Jan. 17, 2015, 9:48 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122105/ --- (Updated Jan. 17, 2015, 9:48 p.m.) Review request for KDE Frameworks and KDE Games. Repository: libkdegames Description --- Since you can't use KSharedConfig::openConfig from a static destructor anymore (the QCoreApplication is gone and thus can't find the name of the thing) use a post routine to save the level before the QCoreApplication is gone. KF5 people: Is this something worth mentioning on the porting notes or using KSharedConfig::openConfig from a static destructor is a bit of a corner case anyway? Diffs - kgdifficulty.cpp 94489c7 Diff: https://git.reviewboard.kde.org/r/122105/diff/ Testing --- Thanks, Albert Astals Cid ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121991: New porting helper: convert-to-cmake-automoc.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121991/ --- Review request for KDE Frameworks. Repository: kde-dev-scripts Description --- New porting helper: convert-to-cmake-automoc.pl As the name suggests, this helper tries to port cpp files to CMake's automoc. It attempts to remove files such as '#include basename.moc' from cpp files where it can, and includes '#include moc_basename.cpp' as fallback. More information inside the documentation of the script Diffs - kf5/convert-to-cmake-automoc.pl PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121991/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121991: New porting helper: convert-to-cmake-automoc.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121991/ --- (Updated Jan. 11, 2015, 7:26 p.m.) Review request for KDE Frameworks. Changes --- K_PLUGIN_FACTORY requires #include foo.moc inside the source as well. Repository: kde-dev-scripts Description (updated) --- New porting helper: convert-to-cmake-automoc.pl As the name suggests, this helper tries to port cpp files to CMake's automoc. It attempts to remove files such as '#include basename.moc' from cpp files where it can, and includes '#include moc_basename.cpp' as fallback. More information inside the documentation of the script Diffs (updated) - kf5/convert-to-cmake-automoc.pl PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121991/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121991: New porting helper: convert-to-cmake-automoc.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121991/ --- (Updated Jan. 11, 2015, 7:29 p.m.) Review request for KDE Frameworks and Laurent Montel. Repository: kde-dev-scripts Description --- New porting helper: convert-to-cmake-automoc.pl As the name suggests, this helper tries to port cpp files to CMake's automoc. It attempts to remove files such as '#include basename.moc' from cpp files where it can, and includes '#include moc_basename.cpp' as fallback. More information inside the documentation of the script Diffs - kf5/convert-to-cmake-automoc.pl PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121991/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121991: New porting helper: convert-to-cmake-automoc.pl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121991/ --- (Updated Jan. 11, 2015, 10:39 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Laurent Montel. Repository: kde-dev-scripts Description --- New porting helper: convert-to-cmake-automoc.pl As the name suggests, this helper tries to port cpp files to CMake's automoc. It attempts to remove files such as '#include basename.moc' from cpp files where it can, and includes '#include moc_basename.cpp' as fallback. More information inside the documentation of the script Diffs - kf5/convert-to-cmake-automoc.pl PRE-CREATION Diff: https://git.reviewboard.kde.org/r/121991/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121931: Unbreak KRecursiveFilterProxyModel for Qt 5.5.0+.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121931/#review73523 --- Ship it! Ship It! - Kevin Funk On Jan. 8, 2015, 6:10 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121931/ --- (Updated Jan. 8, 2015, 6:10 p.m.) Review request for KDE Frameworks and Stephen Kelly. Repository: kitemmodels Description --- The upstream commit f96baeb75fc36a41d2b08f880536cee5a8041e79 with the title: QSortFilterProxyModel: honor the roles parameter of dataChanged changes the signature of the private _q_sourceDataChanged slot of QSortFilterProxyModel. I talked to Peppe and he told me to just use the new signature from Qt 5.5 and onwards. Note that the vector of roles was present in the dataChanged signal from 5.0 onwards already. It was simply ignored by QSFPM so far. Indeed, this patch fixes the following crash on Kate startup for me: QMetaObject::invokeMethod: QMetaObject::invokeMethod: No such method KRecursiveFilterProxyModel::_q_sourceDataChanged(QModelIndex,QModelIndex) Candidates are: _q_sourceDataChanged(QModelIndex,QModelIndex,QVectorint) ASSERT: success in file kf5/src/frameworks/kitemmodels/src/krecursivefilterproxymodel.cpp, line 55 Diffs - src/krecursivefilterproxymodel.h cf14c12d064c864e5fb03ccb1e741b57c615b127 src/krecursivefilterproxymodel.cpp b0753caea8693089873f161c123487a1893d5e01 Diff: https://git.reviewboard.kde.org/r/121931/diff/ Testing --- sadly, there are no unit tests for this. but I can use Kate again without crashes and there are no warnings on startup either. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Some more projects in need of respecting KF5_INSTALL_TARGETS_DEFAULT_ARGS
On Tuesday 06 January 2015 23:55:48 Marko Käning wrote: Hi Christoph, I’ve found that these projects do not make use of KF5_INSTALL_TARGETS_DEFAULT_ARGS at the moment: - systemsettings - muon - rocs - libkdegames - kiten - cantor - kolourpaint - libkmahjongg See for details below in order of appearance. I figure this is only the beginning of it and more projects might turn up in the future. Is KF5_INSTALL_TARGETS_DEFAULT_ARGS even correct for non-frameworks projects? KF5_INSTALL_TARGETS_DEFAULT_ARGS's INCLUDES location points to $SOMETHING/KF5. KDEInstallDirs.cmake also has a KDE_INSTALL_TARGETS_DEFAULT_ARGS, which seems more appropriate. @Alex, please elaborate. Thanks for taking care of these. Regards, Marko P.S.: I’ve tested locally to prepend KF5_” to INSTALL_TARGETS_DEFAULT_ARGS for project systemsettings only, which worked fine and made the project install successfully again here on my OSX/CI system. P.P.S.: I realised by now that there are no changes on the production branch, which probably means that there was some change in ECM or wherever provoking these issues... --- systemsettings: CMake Error at core/CMakeLists.txt:37 (install): install TARGETS given no LIBRARY DESTINATION for shared library target systemsettingsview”. --- muon: CMake Error at libmuon/notifiers/CMakeLists.txt:7 (install): install TARGETS given no LIBRARY DESTINATION for shared library target MuonNotifiers. CMake Error at libmuon/CMakeLists.txt:63 (install): install TARGETS given no LIBRARY DESTINATION for shared library target muonprivate”. --- rocs: CMake Error at libgraphtheory/CMakeLists.txt:106 (install): install TARGETS given no LIBRARY DESTINATION for shared library target rocsgraphtheory”. --- libkdegames: CMake Error at CMakeLists.txt:163 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KDEGames. CMake Error at CMakeLists.txt:222 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KDEGamesPrivate”. --- kiten: CMake Error at lib/CMakeLists.txt:37 (install): install TARGETS given no LIBRARY DESTINATION for shared library target kiten. --- cantor: CMake Error at src/lib/CMakeLists.txt:75 (install): install TARGETS given no LIBRARY DESTINATION for shared library target cantorlibs”. CMake Error at src/CMakeLists.txt:25 (install): install TARGETS given no LIBRARY DESTINATION for shared library target cantor_config. --- kolourpaint: CMake Error at CMakeLists.txt:579 (install): install TARGETS given no LIBRARY DESTINATION for shared library target kolourpaint_lgpl. --- libkmahjongg: CMake Error at CMakeLists.txt:64 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KMahjongglib. CMake Error at CMakeLists.txt:67 (install): install TARGETS given no LIBRARY DESTINATION for shared library target KF5KMahjongglib. --- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kde-baseapps fails to build on branch frameworks
On Thursday 18 December 2014 22:20:54 Marko Käning wrote: /Users/marko/WC/KDECI-builds/kde-baseapps/dolphin/src/tests/kfileitemlistvie wtest.cpp:91:16: error: no matching constructor for initialization of 'QSignalSpy' QSignalSpy itemsRemovedSpy(m_model, KFileItemModel::itemsRemoved); ^ ~~ Note: That needs Qt 5.4 -- QSignalSpy can take a PMF only since that. /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsi gnalspy.h:61:14: note: candidate constructor not viable: no known conversion from 'void (KItemModelBase::*)(const KItemRangeList )' to 'const char *' for 2nd argument explicit QSignalSpy(const QObject *obj, const char *aSignal) ^ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/include/QtTest/qsig nalspy.h:58:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided class QSignalSpy: public QObject, public QListQListQVariant ^ Building CXX object dolphin/src/CMakeFiles/kcm_dolphinviewmodes.dir/settings/viewmodes/viewsett ingstab.cpp.o 2 errors generated. [ 50%] make[2]: *** [dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/kfileitemlistviewte st.cpp.o] Error 1 make[1]: *** [dolphin/src/tests/CMakeFiles/kfileitemlistviewtest.dir/all] Error 2 -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where are my systray icons cont'd
On Thursday 27 November 2014 21:10:10 Kevin Funk wrote: Heya, I'm still missing my beloved systray icons for a few applications in Plasma 5 on Ubuntu 14.10 (using distro provided packages). I have every package installed according to [1] (sni-qt, libindicator*), but still, systray icons for Pidgin or Skype won't show up. Also see [2]. What am I doing wrong? :) PS: I really don't have a clue about implementation details here, so any hints are more than welcome. PPS: Doesn't seem distro-related, Helio has the same issues on Fedora, self- compiled Plasma 5 [1] http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ [2] https://developer.pidgin.im/ticket/16456 Alright. I fixed my issue with Pidgin by installing another plugin: Installed the 'pidgin-indicator' plugin [1], which provides an AppIndicator. PS: IOW that means, Xembed-based icons still don't seem to work for me. Is this an Ubuntu-only problem or am I missing something? (I have a Qt5-based app, using QSystemTrayIcon, whose systray icon doesn't show up) [1] http://www.webupd8.org/2014/01/pidgin-indicator-ubuntu-appindicator.html -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121276: KPluginInfo::category() instead of property(X-KDE-PluginInfo-Category)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121276/#review71029 --- Ship it! Ship It! - Kevin Funk On Nov. 27, 2014, 6:07 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121276/ --- (Updated Nov. 27, 2014, 6:07 p.m.) Review request for KDE Frameworks. Repository: kcmutils Description --- KPluginInfo::category() instead of property(X-KDE-PluginInfo-Category) Diffs - src/kpluginselector.cpp a0d4568c9004b97a3130e699f10847540065a82a Diff: https://git.reviewboard.kde.org/r/121276/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Where are my systray icons cont'd
Heya, I'm still missing my beloved systray icons for a few applications in Plasma 5 on Ubuntu 14.10 (using distro provided packages). I have every package installed according to [1] (sni-qt, libindicator*), but still, systray icons for Pidgin or Skype won't show up. Also see [2]. What am I doing wrong? :) PS: I really don't have a clue about implementation details here, so any hints are more than welcome. PPS: Doesn't seem distro-related, Helio has the same issues on Fedora, self- compiled Plasma 5 [1] http://blog.martin-graesslin.com/blog/2014/06/where-are-my-systray-icons/ [2] https://developer.pidgin.im/ticket/16456 -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121172: Move libgit2-related macro defs into config.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121172/ --- (Updated Nov. 24, 2014, 2:31 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Only recompile dependent files in case of dep changes Diffs - CMakeLists.txt 5a597818e8b5a16899c10fd4a460e09bb233 config.h.cmake e1c9f34cf24eb516c540db3288c93ad5bd093df3 src/document/katedocument.cpp aac17c719cbabf78c2135062fe566671713cea02 src/utils/kateglobal.cpp 473240514eaeb7f108a5bc0a06e182d4aacc7a80 Diff: https://git.reviewboard.kde.org/r/121172/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121173: Use correct version in kbuildsycoca5 executable
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121173/ --- (Updated Nov. 19, 2014, 8:21 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kservice Description --- Use correct version in kbuildsycoca5 executable Diffs - src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 Diff: https://git.reviewboard.kde.org/r/121173/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121172: Move libgit2-related macro defs into config.h
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121172/ --- Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Only recompile dependent files in case of dep changes Diffs - CMakeLists.txt 5a597818e8b5a16899c10fd4a460e09bb233 config.h.cmake e1c9f34cf24eb516c540db3288c93ad5bd093df3 src/document/katedocument.cpp aac17c719cbabf78c2135062fe566671713cea02 src/utils/kateglobal.cpp 473240514eaeb7f108a5bc0a06e182d4aacc7a80 Diff: https://git.reviewboard.kde.org/r/121172/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121173: Use correct version in kbuildsycoca5 executable
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121173/ --- Review request for KDE Frameworks. Repository: kservice Description --- Use correct version in kbuildsycoca5 executable Diffs - src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 Diff: https://git.reviewboard.kde.org/r/121173/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121160: Add libgit2 compile-time check for threads support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121160/ --- Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add libgit2 compile-time check for threads support Diffs - CMakeLists.txt 5cace5fead7c80ede9fa82643426ab5a5e5a4035 src/test_libgit2_threads.c PRE-CREATION src/utils/kateglobal.cpp 6e3362802c213c914430a4775ab15e3515729474 Diff: https://git.reviewboard.kde.org/r/121160/diff/ Testing --- Should fix the CI failure. Compiles fine for me (with threads support) Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121160: Add libgit2 compile-time check for threads support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121160/ --- (Updated Nov. 17, 2014, 10:45 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- Add libgit2 compile-time check for threads support Diffs - CMakeLists.txt 5cace5fead7c80ede9fa82643426ab5a5e5a4035 src/test_libgit2_threads.c PRE-CREATION src/utils/kateglobal.cpp 6e3362802c213c914430a4775ab15e3515729474 Diff: https://git.reviewboard.kde.org/r/121160/diff/ Testing --- Should fix the CI failure. Compiles fine for me (with threads support) Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121082: Add TODO for private signals in KJob
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121082/ --- (Updated Nov. 11, 2014, 8:48 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Can't change that now because it would be BIC. Diffs - src/lib/jobs/kjob.h d4b7abd3774626f450aadb4e43185ed5bb654792 Diff: https://git.reviewboard.kde.org/r/121082/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: How to port KTabBar::mouseMiddleClick?
On Monday 10 November 2014 15:19:22 Nicolás Alvarez wrote:
2014-11-09 7:28 GMT-03:00 Frank Reininghaus frank7...@googlemail.com:
Hi,
2014-11-06 2:59 GMT+01:00 Milian Wolff:
Hey all,
what do I do to get middle-click-closes-tab in Qt 5 without KTabBar?
Previously, we used KTabBar and its mouseMiddleClick signal.
AFAIK, currently the only solution is to subclass QTabBar, override
the mousePressEvent method and emit a signal from there. Dolphin uses
this approach. There were many other reasons why Emmanuel created a
custom QTabBar subclass for Dolphin though .
If many apps need the middle click to close bevavior, then
reanimating KTabBar or getting this functionality into QTabBar might
be better than making every app create its own tab bar class.
Or maybe contribute mouseMiddleClick to QTabBar?
(I'm not volunteering :P)
Yep. I'm wondering if an a patch just reacting on middle clicks would be
accepted. It's not like it breaks existing work flows, it's just there for
convenience.
Grepping qtbase showed that QMdiArea has a similar feature:
widgets/qmdiarea.cpp
582-void QMdiAreaTabBar::mousePressEvent(QMouseEvent *event)
583-{
584:if (event-button() != Qt::MidButton) {
585-QTabBar::mousePressEvent(event);
586-return;
587-}
588-
589-QMdiSubWindow *subWindow = subWindowFromIndex(tabAt(event-pos()));
590-if (!subWindow) {
591-event-ignore();
592-return;
593-}
594-
595-subWindow-close();
596-}
Worth trying to patch this into QTabBar right away, I think.
Cheers
--
Kevin Funk | kf...@kde.org | http://kfunk.org
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 121082: Add TODO for private signals in KJob
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121082/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Can't change that now because it would be BIC. Diffs - src/lib/jobs/kjob.h d4b7abd3774626f450aadb4e43185ed5bb654792 Diff: https://git.reviewboard.kde.org/r/121082/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121007: Fix warning when using newer upower backend.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121007/#review69967 --- Ship it! Finally! - Kevin Funk On Nov. 6, 2014, 1:05 a.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121007/ --- (Updated Nov. 6, 2014, 1:05 a.m.) Review request for KDE Frameworks. Repository: solid Description --- No such signal org::freedesktop::UPower::DeviceAdded(...) The signature change can be detected at runtime using Qt's QMetaObject introspection mechanism. That prevents us from emitting the two pesky warnings at runtime, polluting our konsoles. Google is full of that warning, and there is also: https://bugzilla.redhat.com/show_bug.cgi?id=1056769 Diffs - src/solid/devices/backends/upower/upowermanager.cpp 53c858093a1c439f0faca0c956a51199f4e882e4 Diff: https://git.reviewboard.kde.org/r/121007/diff/ Testing --- warning gone! Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Replacement for KMimeType::isBinaryData?
Heya, I didn't find a suitable replacement for KMimeType::isBinaryData in KF5. Is there some? http://lxr.kde.org/ident?v=kf5-qt5_i=isBinaryData_remember=1 shows exactly two users of this function. Worth considering upstreaming to Qt? -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120435: Declare InheritanceChecker before actual use
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120435/ --- (Updated Oct. 11, 2014, 8:40 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Ben Cooksley. Repository: kcoreaddons Description --- Declare InheritanceChecker before actual use This is actually not needed for proper compilers, because the use is inside a template, The type is only required at instantiation time. However, this patch makes the Coverity build tool happy. Without this patch, we get an error for every translation unit including kpluginfactory.h, telling us that InheritanceChecker is not a template Also see https://communities.coverity.com/thread/2903 Diffs - src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 Diff: https://git.reviewboard.kde.org/r/120435/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120435: Declare InheritanceChecker before actual use
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120435/#review67849 --- Bump. This is a super trivial patch. :) - Kevin Funk On Sept. 30, 2014, 11:36 a.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120435/ --- (Updated Sept. 30, 2014, 11:36 a.m.) Review request for KDE Frameworks and Ben Cooksley. Repository: kcoreaddons Description --- Declare InheritanceChecker before actual use This is actually not needed for proper compilers, because the use is inside a template, The type is only required at instantiation time. However, this patch makes the Coverity build tool happy. Without this patch, we get an error for every translation unit including kpluginfactory.h, telling us that InheritanceChecker is not a template Also see https://communities.coverity.com/thread/2903 Diffs - src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 Diff: https://git.reviewboard.kde.org/r/120435/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120435: Declare InheritanceChecker before actual use
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120435/ --- Review request for KDE Frameworks and Ben Cooksley. Repository: kcoreaddons Description --- Declare InheritanceChecker before actual use This is actually not needed for proper compilers, because the use is inside a template, The type is only required at instantiation time. However, this patch makes the Coverity build tool happy. Without this patch, we get an error for every translation unit including kpluginfactory.h, telling us that InheritanceChecker is not a template Also see https://communities.coverity.com/thread/2903 Diffs - src/lib/plugin/kpluginfactory.h 70ffade3e071b839245b9b0d6468f7b804478178 Diff: https://git.reviewboard.kde.org/r/120435/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: plasmate fails to build on branch frameworks
On Sunday 14 September 2014 18:28:16 Marko Käning wrote: On 14 Sep 2014, at 16:24 , Marko Käning mk-li...@email.de wrote: Linux/CI hang, because there was a missing dependency to kdevplatform. This has been fixed by now, but Jenkins master hasn’t picked up the dependency change yet. After two hours I triggered another rebuild, which pulled the corrected deps in and eventually resulted in the same error as the OSX/CI system. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Note: Plasmate needs to be fixed to work on the current kdevplatform. We've done the invasive KUrl-QUrl port there which of course broke source compatibility. Greets -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Porting uses of 'accuracy' in KMimeType API
Heya, Context: Forward-porting some patches in KDevelop involving KMimeType API. I've just noticed that in Qt5, QMimeDataBase/QMimeType doesn't allow me to retrieve the accuracy of a match anymore, while KMimeType did. For example, compare the possible arguments for QMimeDataBase::mimeTypeForUrl vs. KMimeType::findByUrl. What's the suggested way to deal with this? As far as I can see, there are no porting notes about that particular matter. (Interestingly, the QMimeDataBase implementation internally plays around with accuracies a lot, it just isn't exposed in the public API) Thanks [1] http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKMimeType.html#a3417e83a30cff614a01a29ca2a615443 -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting uses of 'accuracy' in KMimeType API
On Friday 12 September 2014 10:50:36 David Faure wrote: On Friday 12 September 2014 09:39:42 Kevin Funk wrote: Heya, Context: Forward-porting some patches in KDevelop involving KMimeType API. I've just noticed that in Qt5, QMimeDataBase/QMimeType doesn't allow me to retrieve the accuracy of a match anymore, while KMimeType did. For example, compare the possible arguments for QMimeDataBase::mimeTypeForUrl vs. KMimeType::findByUrl. What's the suggested way to deal with this? As far as I can see, there are no porting notes about that particular matter. You're telling me everything I know already, but not the important bit which is: what do you need the accuracy for? Well, this is ancient, performance-critical code inside KDevelop. We basically cache a extension - language mapping for performance reasons. Just recently we introduced code that avoids caching extensions for which the KMimeType lookup yielded a very low accuracy. Also see: https://git.reviewboard.kde.org/r/120085/ Note: I never touched that code myself. The mime matching tries its best to find out the mimetype based on what you give it (filename and/or content). The output of that is the best idea we have about the mimetype. What difference does it make if that's a 20% or an 80% accuracy? (Interestingly, the QMimeDataBase implementation internally plays around with accuracies a lot, it just isn't exposed in the public API) Yes, as per the mimetype spec. My guess is that it was used as a workaround for bad api or implementation, like try with the content, and if that's not accurate, try with the filename, or vice-versa. But QMimeDatabase has the right all-in-one methods for this, following the spec, i.e. if both filename and content are available, then trust the filename, unless there are multiple mimetypes claiming the same glob, then look at content, and select the one that matches (or is a subclass of) one of the candidates based on the filename. The intended way to use this is to use isDefault() on the QMimeType, if that's true then it couldn't find any specific mimetype for the file (i.e. basically accuracy 0). And otherwise, that's the mimetype. -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kio_trash
On Sunday 17 August 2014 00:03:41 David Faure wrote: kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, support for trash in FileUndoManager, and I'm about to add a KIO::restoreFromTrash job). And KIO::trash is called from the file dialog (kdiroperator.cpp). So this is a missing runtime dependency if kde-workspace/kio-extras isn't installed. How about we move kio_trash to the kio framework? (If we agree, can someone do it? I still have no experience with doing this in a way that preserves the git history) I guess that'd also fix my CI-related issue here [1], right: QWARN : GitInitTest::testRemoveEmptyFolder() couldn't create slave: Unable to create io-slave: klauncher said: Unknown protocol 'trash'. (We're using KIO::trash, but the CI doesn't provide this particular slave because it's part of different module) Greets [1] http://build.kde.org/view/kdevelop/job/kdevplatform_frameworks_qt5/154/testReport/(root)/TestSuite/test_kdevgit/ -- Kevin Funk | kf...@kde.org | http://kfunk.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119564: Add define to re-enable Qt functionality we depend on.
On Aug. 2, 2014, 9:04 a.m., Alex Merry wrote: I would rather change the code. The Qt behaviour was changed for a reason, to prevent accidental use of dangerous behaviour, and I'm not too keen on undoing that move for all software that uses KDECompilerSettings. Sune Vuorela wrote: agreed. Kevin Funk wrote: Yep. I'm also *strongly* in favor of adjusting the code instead of enabling the define. In fact, I thought I've fixed all of KF5. (It isn't?). There are some compile errors in code *using* KF5, which I'm trying to port ASAP. Axel Rasmussen wrote: Would we prefer just using `static_cast` like QExplicitlySharedDataPointer used to do, or shall we use `dynamic_cast` and check for `NULL` results to be extra safe? I am willing to write up a patch that fixes this issue in KService over the next day or two. Alex Merry wrote: I'd expect most of the cases to be suitable for `static_cast` (if you can guarantee what it will be from the context). If in doubt, state your uncertainty in the review request description so that reviewers know to take extra care. Note: KService has already been fixed two weeks ago -- see https://git.reviewboard.kde.org/r/119241/ - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119564/#review63665 --- On Aug. 1, 2014, 4:06 p.m., Axel Rasmussen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119564/ --- (Updated Aug. 1, 2014, 4:06 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Bugs: 337472 http://bugs.kde.org/show_bug.cgi?id=337472 Repository: extra-cmake-modules Description --- Upstream Qt commit e112c2e altered the way QExplicitlySharedDataPointer behaves by default, such that it no longer uses a `static_cast` to cast compatible pointers. A nontrivial amount of KDE code (I encountered the build error in KService, although there are other users) depends on this functionality, so this commit adds a define to the build system which re-enables the code in Qt. Diffs - kde-modules/KDECompilerSettings.cmake fdc930e Diff: https://git.reviewboard.kde.org/r/119564/diff/ Testing --- I applied this patch, attempted to build KService, and the build succeeded, rather than exhibiting the compile errors found in the log provided on the bug report. Thanks, Axel Rasmussen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119152/ --- (Updated Aug. 5, 2014, 8:06 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Stephen Kelly. Repository: kdelibs4support Description --- Do not define QT_DISABLE_DEPRECATED_BEFORE When defining it in your own project, you'll get: command-line:0:0: warning: QT_DISABLE_DEPRECATED_BEFORE redefined [enabled by default] Is there any reason for it to be there? Diffs - cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc Diff: https://git.reviewboard.kde.org/r/119152/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119564: Add define to re-enable Qt functionality we depend on.
On Aug. 2, 2014, 9:04 a.m., Alex Merry wrote: I would rather change the code. The Qt behaviour was changed for a reason, to prevent accidental use of dangerous behaviour, and I'm not too keen on undoing that move for all software that uses KDECompilerSettings. Sune Vuorela wrote: agreed. Yep. I'm also *strongly* in favor of adjusting the code instead of enabling the define. In fact, I thought I've fixed all of KF5. (It isn't?). There are some compile errors in code *using* KF5, which I'm trying to port ASAP. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119564/#review63665 --- On Aug. 1, 2014, 4:06 p.m., Axel Rasmussen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119564/ --- (Updated Aug. 1, 2014, 4:06 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Bugs: 337472 http://bugs.kde.org/show_bug.cgi?id=337472 Repository: extra-cmake-modules Description --- Upstream Qt commit e112c2e altered the way QExplicitlySharedDataPointer behaves by default, such that it no longer uses a `static_cast` to cast compatible pointers. A nontrivial amount of KDE code (I encountered the build error in KService, although there are other users) depends on this functionality, so this commit adds a define to the build system which re-enables the code in Qt. Diffs - kde-modules/KDECompilerSettings.cmake fdc930e Diff: https://git.reviewboard.kde.org/r/119564/diff/ Testing --- I applied this patch, attempted to build KService, and the build succeeded, rather than exhibiting the compile errors found in the log provided on the bug report. Thanks, Axel Rasmussen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119241: Fix QExplicitlySharedDataPointer usage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119241/ --- (Updated July 15, 2014, 10:21 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kservice Description --- Fix QExplicitlySharedDataPointer usage One of the constructors of QExplicitlySharedDataPointer got disabled in Qt 5.4 due to being to permissive. Also see: http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/ Diffs - src/kbuildsycoca/kbuildservicefactory.cpp bc36a22ced38892a92656d37a5d63e768dec6d40 src/kbuildsycoca/kbuildservicegroupfactory.cpp ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 src/kbuildsycoca/kbuildservicetypefactory.cpp 8f577a4267e8818e7e2cf5109068659439ca3221 src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 src/services/kservicetypefactory.cpp 7599c4c73220b2aca366f41ac5cd7d05abfa8afc src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff Diff: https://git.reviewboard.kde.org/r/119241/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119242: Fix QExplicitlySharedDataPointer usage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119242/ --- (Updated July 15, 2014, 10:22 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kio Description --- Fix QExplicitlySharedDataPointer usage One of the constructors of QExplicitlySharedDataPointer got disabled in Qt 5.4 due to being to permissive. Also see: http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/ Diffs - src/widgets/kopenwithdialog.cpp 8cb659fde2028892de82bad64e0ea3ff285b5e3a Diff: https://git.reviewboard.kde.org/r/119242/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119241: Fix QExplicitlySharedDataPointer usage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119241/ --- Review request for KDE Frameworks. Repository: kservice Description --- Fix QExplicitlySharedDataPointer usage One of the constructors of QExplicitlySharedDataPointer got disabled in Qt 5.4 due to being to permissive. Also see: http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/ Diffs - src/kbuildsycoca/kbuildservicefactory.cpp bc36a22ced38892a92656d37a5d63e768dec6d40 src/kbuildsycoca/kbuildservicegroupfactory.cpp ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 src/kbuildsycoca/kbuildservicetypefactory.cpp 8f577a4267e8818e7e2cf5109068659439ca3221 src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 src/services/kservicetypefactory.cpp 7599c4c73220b2aca366f41ac5cd7d05abfa8afc src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff Diff: https://git.reviewboard.kde.org/r/119241/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119242: Fix QExplicitlySharedDataPointer usage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119242/ --- Review request for KDE Frameworks. Repository: kio Description --- Fix QExplicitlySharedDataPointer usage One of the constructors of QExplicitlySharedDataPointer got disabled in Qt 5.4 due to being to permissive. Also see: http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/ Diffs - src/widgets/kopenwithdialog.cpp 8cb659fde2028892de82bad64e0ea3ff285b5e3a Diff: https://git.reviewboard.kde.org/r/119242/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119241: Fix QExplicitlySharedDataPointer usage
On July 12, 2014, 2:01 p.m., Aleix Pol Gonzalez wrote: tests/ksycocatest.cpp, line 104 https://git.reviewboard.kde.org/r/119241/diff/1/?file=289736#file289736line104 Why does it need a static_cast if we're upcasting? Also constructing a shared pointer from the data field in another one seems dangerous... That' a downcast. The hierarchy is KService : KSycocaEntry : QSharedData. Also, construcing it from the data field isn't dangerous -- because the ref-counter is inside the tracked object (QSharedData). Note that QExplicitlySharedDataPointer is missing convenience API like we had in KSharedPtr, e.g. KSharedPtr::staticCast. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119241/#review62182 --- On July 12, 2014, 9:41 a.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119241/ --- (Updated July 12, 2014, 9:41 a.m.) Review request for KDE Frameworks. Repository: kservice Description --- Fix QExplicitlySharedDataPointer usage One of the constructors of QExplicitlySharedDataPointer got disabled in Qt 5.4 due to being to permissive. Also see: http://kfunk.org/2014/07/10/wrap-up-issues-with-qexplicitlyshareddatapointer-ksharedptr-successor/ Diffs - src/kbuildsycoca/kbuildservicefactory.cpp bc36a22ced38892a92656d37a5d63e768dec6d40 src/kbuildsycoca/kbuildservicegroupfactory.cpp ea0d6ed094347c4bb3f0ce2bfd9a26445a25c545 src/kbuildsycoca/kbuildservicetypefactory.cpp 8f577a4267e8818e7e2cf5109068659439ca3221 src/kbuildsycoca/kbuildsycoca.cpp ed2929f4e60a1841807ce8490c8057d5a7b55827 src/services/kmimetypefactory.cpp a52d07d1dd9040c0a79f36f1665822e714d9b369 src/services/kservicefactory.cpp bb1e0f58396a358c3168c74a89be04315a295fcd src/services/kservicegroup.cpp 0bda1340ae0356c3d5aca9a9f0b3dd5e905638d8 src/services/kservicetypefactory.cpp 7599c4c73220b2aca366f41ac5cd7d05abfa8afc src/sycoca/ksycocadict.cpp a584f933bff10f44bc257ab996aaee3ad38cc79c tests/ksycocatest.cpp d51d80a691427fa4295dd06802de2fb87112f0ff Diff: https://git.reviewboard.kde.org/r/119241/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119152/#review61876 --- Ah. QT_DISABLE_DEPRECATED_BEFORE defaults to QT_VERSION_CHECK(5, 0, 0) (qglobal.h). That means basic functions such as QString::fromAscii are disabled because they're marked as deprecated since 5.0. Question is: Do we really want to override the default value for QT_DISABLE_DEPRECATED_BEFORE? - Kevin Funk On July 6, 2014, 10:17 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119152/ --- (Updated July 6, 2014, 10:17 p.m.) Review request for KDE Frameworks and Stephen Kelly. Repository: kdelibs4support Description --- Do not define QT_DISABLE_DEPRECATED_BEFORE When defining it in your own project, you'll get: command-line:0:0: warning: QT_DISABLE_DEPRECATED_BEFORE redefined [enabled by default] Is there any reason for it to be there? Diffs - cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc Diff: https://git.reviewboard.kde.org/r/119152/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 119152: Do not define QT_DISABLE_DEPRECATED_BEFORE
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119152/ --- Review request for KDE Frameworks and Stephen Kelly. Repository: kdelibs4support Description --- Do not define QT_DISABLE_DEPRECATED_BEFORE When defining it in your own project, you'll get: command-line:0:0: warning: QT_DISABLE_DEPRECATED_BEFORE redefined [enabled by default] Is there any reason for it to be there? Diffs - cmake/modules/ECMQt4To5Porting.cmake 4204fa541790aa38c74b9d6f0b2111af2157b2bc Diff: https://git.reviewboard.kde.org/r/119152/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117951: trash: Fix KUrl-QUrl porting bug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117951/ --- Review request for KDE Frameworks and David Faure. Repository: kio-extras Description --- trash: Fix KUrl-QUrl porting bug Make sure we keep the old behavior Diffs - trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba Diff: https://git.reviewboard.kde.org/r/117951/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117952: Fix KIO::suggestName() for the case of leading dots, and no other dot.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117952/#review57150 --- Ship it! LGTM - Kevin Funk On May 2, 2014, 4:12 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117952/ --- (Updated May 2, 2014, 4:12 p.m.) Review request for KDE Frameworks and Kevin Funk. Repository: kio Description --- Fix KIO::suggestName() for the case of leading dots, and no other dot. We don't want to change the extension in that case. With a unittest for that method, finally. Diffs - autotests/globaltest.h b955329cf7d5841d9f9c1230e41d1261a268420e autotests/globaltest.cpp 4367e53b44e077c566316081e21f429ac15b74a0 src/core/global.cpp b6f523d66ef5b9308f615c485d6dcf3069b26ace Diff: https://git.reviewboard.kde.org/r/117952/diff/ Testing --- Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117951: trash: Fix KUrl-QUrl porting bug
On May 2, 2014, 4:14 p.m., David Faure wrote: I assume the test failed before the fix, right? ;-) Yep. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117951/#review57148 --- On May 2, 2014, 4:10 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117951/ --- (Updated May 2, 2014, 4:10 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio-extras Description --- trash: Fix KUrl-QUrl porting bug Make sure we keep the old behavior Diffs - trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba Diff: https://git.reviewboard.kde.org/r/117951/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117951: trash: Fix KUrl-QUrl porting bug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117951/ --- (Updated May 2, 2014, 4:24 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kio-extras Description --- trash: Fix KUrl-QUrl porting bug Make sure we keep the old behavior Diffs - trash/tests/testtrash.h f35574d7a18739652545cda751aa925a40bfc5d3 trash/tests/testtrash.cpp 411c7913193dbbb527edfe3601b91dd1f7af99e6 trash/trashimpl.cpp 91c671332dd9545486c2086944c247e0defe8bba Diff: https://git.reviewboard.kde.org/r/117951/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Hitting assertion in kio-trash (KF5KIOCore)
On Wednesday 16 April 2014 21:31:01 Kevin Funk wrote: Hey, While running unit tests from kdevplatform I hit the following assert in trash/trashimpl.cpp (from workspace/kio-extras) Output of the unit test (which attempts to trash some folders): trying to create /home/krf/.local/share/Trash/info/.trashinfo trying to create /home/krf/.local/share/Trash/info/.trashinfo 1 trying to create /home/krf/.local/share/Trash/info/.trashinfo 2 trying to create /home/krf/.local/share/Trash/info/.trashinfo 3 trying to create /home/krf/.local/share/Trash/info/.trashinfo 4 trying to create /home/krf/.local/share/Trash/info/.trashinfo 5 trying to create /home/krf/.local/share/Trash/info/.trashinfo 6 ASSERT: fileId.endsWith( QLatin1String(.trashinfo) ) in file /home/krf/devel/src/kf5/kde/workspace/kio-extras/trash/trashimpl.cpp, line 272 kioslave: ### CRASH ## protocol = trash pid = 6144 signal = 6 /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKF5KIOCore.so.5(+0x8d60 9) [0x7fbbbfe79609] (...) Looking at the code, that assert looks very suspicious. The code above the assert seems to generate file ids such as '.trashinfo' or '.trashinfo SOME_NUMBER'. In case of the latter, the assert will always be hit. Any ideas? Did KIO::RenameDialog::suggestName change? Reproducable with: ./plugins/git/tests/kdevgit-test testRemoveEmptyFolder from kdevplatform.git. Greets Hey, https://git.reviewboard.kde.org/r/117951/ fixed this, btw. It was a porting bug (KUrl - QUrl) within trashimpl.cpp Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117695: change where dynamic replace tabs is performed
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117695/#review56264 --- src/document/katedocument.cpp https://git.reviewboard.kde.org/r/117695/#comment39333 Early-return? if (!replacetabs) return str; ... - Kevin Funk On April 23, 2014, 8:49 a.m., Sven Brauch wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117695/ --- (Updated April 23, 2014, 8:49 a.m.) Review request for KDE Frameworks and Christoph Cullmann. Repository: ktexteditor Description --- This makes typeChars handle replacing tabs by spaces, instead of insertText. The rationale is that insertText is often called programatically, and the caller should be able to rely on the text he requests to be inserted is actually inserted, and not changed on-the-fly. Examples for where the previous solution caused problems are KDevelop (the codegen) and kte-collaborative. I'm not sure what the code I removed was doing (heh). It looks like it is supposed to advance to the next indent level if the current indent level is odd, but that still works after removing it. The obvious user-visible change here is that tabs in pasted text will no longer be replaced. But since I always found this behaviour undesirable anyways, I did not bother to replicate it. I will instead wait for people to yell at me for removing it. ;) Diffs - src/document/katedocument.h 83cc0317e26ef077d5292763d0ba9864103bf454 src/document/katedocument.cpp 546d3e6aadc57f24c3fa766ce235addc0f02e3c3 Diff: https://git.reviewboard.kde.org/r/117695/diff/ Testing --- Just some quick manual tests, it seems to still work as intended. Thanks, Sven Brauch ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hitting assertion in kio-trash (KF5KIOCore)
Hey, While running unit tests from kdevplatform I hit the following assert in trash/trashimpl.cpp (from workspace/kio-extras) Output of the unit test (which attempts to trash some folders): trying to create /home/krf/.local/share/Trash/info/.trashinfo trying to create /home/krf/.local/share/Trash/info/.trashinfo 1 trying to create /home/krf/.local/share/Trash/info/.trashinfo 2 trying to create /home/krf/.local/share/Trash/info/.trashinfo 3 trying to create /home/krf/.local/share/Trash/info/.trashinfo 4 trying to create /home/krf/.local/share/Trash/info/.trashinfo 5 trying to create /home/krf/.local/share/Trash/info/.trashinfo 6 ASSERT: fileId.endsWith( QLatin1String(.trashinfo) ) in file /home/krf/devel/src/kf5/kde/workspace/kio-extras/trash/trashimpl.cpp, line 272 kioslave: ### CRASH ## protocol = trash pid = 6144 signal = 6 /home/krf/devel/install/kf5/lib/x86_64-linux-gnu/libKF5KIOCore.so.5(+0x8d609) [0x7fbbbfe79609] (...) Looking at the code, that assert looks very suspicious. The code above the assert seems to generate file ids such as '.trashinfo' or '.trashinfo SOME_NUMBER'. In case of the latter, the assert will always be hit. Any ideas? Did KIO::RenameDialog::suggestName change? Reproducable with: ./plugins/git/tests/kdevgit-test testRemoveEmptyFolder from kdevplatform.git. Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Writing a Frameworks book at Randa
On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote: Hello folks, I know that August is months away, but if you want your Frameworks book, now is the time to step forward. Here are some things to think about: Most of this book is already written somewhere. When the words have already been written down, all we need do is gather and arrange them. When you think of such an email, dot story, blog post or have eloquent thoughts in your head, please make a note. If you are on this list, you are an expert. You know what the Frameworks will do for KDE, and you know what they *can* do for others. Our book will present that case. A good book will help grow the Frameworks team; I'm sure of it. And a good book will make your work more widely used. Oh, and you'll be a published author! While in Randa, none of us will be writing full-time. In fact, I hope that *all* of the Frameworks people will stop by the writing room, or log into Booki and review, add, re-arrange, correct, or make the text more graceful. To make this work a few people must volunteer to take on the writing of the book as their most important task at Randa. It will be mine, and our goal is to have a book by the end of the week. We've done it before, and I know we can do it again. This is a valuable work. We need to know the core members of this team, soon. Please step forward, and also add yourself to the Spints page for planning and funding. Valorie Hey, I'm wondering if we should rather try spending the time in making our KF5 apidocs shine. You could spend plenty of time on writing introductory parts for the individual modules, writing tutorials and examples, and make sure they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an integral part for the docs on qt-project.org, too. Just have a look at the first hit for qt docs: [1] There's a Getting Started section, with overviews [2] with examples and tutorials [3]. That's *exactly* what we need for KF5, too. That's the best place to point newcomers to whenever they want to get wet with KF5. But it also takes time and people to get to this state. Personally, from a developer POV, I don't really see the need for a separate book. There will always be a discrepancy between the book and the actual code (be it completeness, accuracy, its up-to-date-ness), and for developers it's always an extra burden to make sure to amend the contents of the book whenever they change something in source code. It's much more straight-forward to make sure that at least the apidocs are up-to-date. The apidocs being inline in the source code being is an integral part in making sure they're amended alongside of source code changes. Opinions? What do the frameworks devs think about it? Greets [1] http://qt-project.org/doc/qt-5/index.html [2] http://qt-project.org/doc/qt-5/overviews-main.html [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Writing a Frameworks book at Randa
On Wednesday 09 April 2014 15:42:47 Aleix Pol wrote: On Wed, Apr 9, 2014 at 3:05 PM, Kevin Funk kf...@kde.org wrote: On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote: Hello folks, I know that August is months away, but if you want your Frameworks book, now is the time to step forward. Here are some things to think about: Most of this book is already written somewhere. When the words have already been written down, all we need do is gather and arrange them. When you think of such an email, dot story, blog post or have eloquent thoughts in your head, please make a note. If you are on this list, you are an expert. You know what the Frameworks will do for KDE, and you know what they *can* do for others. Our book will present that case. A good book will help grow the Frameworks team; I'm sure of it. And a good book will make your work more widely used. Oh, and you'll be a published author! While in Randa, none of us will be writing full-time. In fact, I hope that *all* of the Frameworks people will stop by the writing room, or log into Booki and review, add, re-arrange, correct, or make the text more graceful. To make this work a few people must volunteer to take on the writing of the book as their most important task at Randa. It will be mine, and our goal is to have a book by the end of the week. We've done it before, and I know we can do it again. This is a valuable work. We need to know the core members of this team, soon. Please step forward, and also add yourself to the Spints page for planning and funding. Valorie Hey, I'm wondering if we should rather try spending the time in making our KF5 apidocs shine. You could spend plenty of time on writing introductory parts for the individual modules, writing tutorials and examples, and make sure they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an integral part for the docs on qt-project.org, too. Just have a look at the first hit for qt docs: [1] There's a Getting Started section, with overviews [2] with examples and tutorials [3]. That's *exactly* what we need for KF5, too. That's the best place to point newcomers to whenever they want to get wet with KF5. But it also takes time and people to get to this state. Personally, from a developer POV, I don't really see the need for a separate book. There will always be a discrepancy between the book and the actual code (be it completeness, accuracy, its up-to-date-ness), and for developers it's always an extra burden to make sure to amend the contents of the book whenever they change something in source code. It's much more straight-forward to make sure that at least the apidocs are up-to-date. The apidocs being inline in the source code being is an integral part in making sure they're amended alongside of source code changes. Opinions? What do the frameworks devs think about it? Greets [1] http://qt-project.org/doc/qt-5/index.html [2] http://qt-project.org/doc/qt-5/overviews-main.html [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, I'm unsure what to say. On one hand, people always seem inclined to have some literature available, especially in the shape of a book. It helps you go through the technologies when you don't know much what you're doing but you still want to learn. It offers a linear overview of interesting things on a related subject, meaning that if things are not interesting, you can opt to not include them in the book. On the other hand, documentation is much more future-proof in terms of having it actively-ish maintained and it will be more useful for the developers who decide to stay using KF5, since they will know what to look for. A proof of this is that even though we have wonderful Qt documentation, we see new books appearing all the time, and I guess this means they pay off, at least. Maybe we should consider the book more as a replacement to the TechBase [1], if it's even possible to offer it in a proper web shape as well, at least. Personally, given that there will be compromises either way, I would say that who codes (or writes) decides. I'll be happy to give a hand in either direction. Fair point. Regardless of what we do, it will be an improvement. From my point of view, proper API documentation/tutorials should be given primary focus, though, given the lack of manpower in this area. Don't get me wrong, I don't want to demotivate anyone from this kind of documentation work (be it in form of a book or apidocs). I'm happy to see it emerge either way. Aleix nails it, whoever does the work, decides. My worry is just that people
Review Request 117017: Remove forward headers for KTextEditor
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117017/ --- Review request for KDE Frameworks and Dominik Haumann. Repository: kde4support Description --- Remove forward headers for KTextEditor Some of the headers have actually been removed already. Keeping broken forward headers actually makes it *more* difficult to port. Diffs - src/includes/KTextEditor/CommandExtension 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/CodeCompletionModelControllerInterface a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 src/includes/KTextEditor/CodeCompletionModel 3511d00b212e5c56613bf4f06fedc5a5d76cb3bc src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae src/includes/KTextEditor/CodeCompletionInterface 41341c38dd92e7c1533b0ba74eceb735408a1d3f src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 src/includes/KTextEditor/ConfigPage b3904bee10ffc0245bca1a928389237813850ec3 src/includes/KTextEditor/ConfigInterface 0617835fc7621c4c26a2d50ca95d12d8870fffc2 src/includes/KTextEditor/CommandInterface 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/ModificationInterface 50df2902648156dc5cd4630f587add36d320a43a src/includes/KTextEditor/MessageInterface 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 src/includes/KTextEditor/HighlightInterface 8c8c94ec679877be7e3965eba86498f06b67a883 src/includes/KTextEditor/MarkInterface 87adf561b38045bdd65fc3f64f24311aa901d8ee src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/ParameterizedSessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/MovingRange 89f68605ffa863862476831cfb836660a70e4931 src/includes/KTextEditor/MovingInterface bde16eaca7d68517ce7c2068186eb641daf6eab1 src/includes/KTextEditor/MovingCursor 7c9eb3074e4feace09cca78962caf1ff27bd6394 src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 src/includes/KTextEditor/VariableInterface 126a93691700fab3134400907d0ba93a4e275f0d src/includes/KTextEditor/TextHintInterface 6b05d9a4a45ac8807294599e04c7dc15db076cf0 src/includes/KTextEditor/TemplateInterface2 de9d9451796710756287bfc2a627f7ae43a006b1 src/includes/KTextEditor/TemplateInterface 0142d17815fabb9136836effa61114aaa1994635 src/includes/KTextEditor/SessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 src/includes/KTextEditor/SearchInterface f7dffc91739e82cceffea35de0632cb19e92ab0a src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e Diff: https://git.reviewboard.kde.org/r/117017/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117017: Remove forward headers for KTextEditor
On March 24, 2014, 10:57 a.m., Aleix Pol Gonzalez wrote: There's a slight difference, and the reason we haven't been doing this for most headers. From KDE4Support you can include headers prefixing KDE/ (such as KDE/KTextEditor/MovingRange). If you remove these that won't be possible anymore thus making porting slightly harder. Arguably people won't be doing KDE/KTextEditor, but then I don't know why people added the KDE/ at all... Yep. I'm just fixing this up in KDevelop (where I hit that problem), replacing occurences of 'KDE/'. The problem with the KTE forward headers are that some of them are already broken (TemplateInterface*, HighlightInterface, and others). This makes it harder than easier to port, because you get compile errors in the middle of the build process. Arguably, I'd rather force people to get rid off the 'KDE/' prefix (which is easy to script) than to compile again and again to make your code work. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117017/#review53937 --- On March 24, 2014, 10:48 a.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117017/ --- (Updated March 24, 2014, 10:48 a.m.) Review request for KDE Frameworks and Dominik Haumann. Repository: kde4support Description --- Remove forward headers for KTextEditor Some of the headers have actually been removed already. Keeping broken forward headers actually makes it *more* difficult to port. Diffs - src/includes/KTextEditor/CommandExtension 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/CodeCompletionModelControllerInterface a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 src/includes/KTextEditor/CodeCompletionModel 3511d00b212e5c56613bf4f06fedc5a5d76cb3bc src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae src/includes/KTextEditor/CodeCompletionInterface 41341c38dd92e7c1533b0ba74eceb735408a1d3f src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 src/includes/KTextEditor/ConfigPage b3904bee10ffc0245bca1a928389237813850ec3 src/includes/KTextEditor/ConfigInterface 0617835fc7621c4c26a2d50ca95d12d8870fffc2 src/includes/KTextEditor/CommandInterface 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/ModificationInterface 50df2902648156dc5cd4630f587add36d320a43a src/includes/KTextEditor/MessageInterface 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 src/includes/KTextEditor/HighlightInterface 8c8c94ec679877be7e3965eba86498f06b67a883 src/includes/KTextEditor/MarkInterface 87adf561b38045bdd65fc3f64f24311aa901d8ee src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/ParameterizedSessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/MovingRange 89f68605ffa863862476831cfb836660a70e4931 src/includes/KTextEditor/MovingInterface bde16eaca7d68517ce7c2068186eb641daf6eab1 src/includes/KTextEditor/MovingCursor 7c9eb3074e4feace09cca78962caf1ff27bd6394 src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 src/includes/KTextEditor/VariableInterface 126a93691700fab3134400907d0ba93a4e275f0d src/includes/KTextEditor/TextHintInterface 6b05d9a4a45ac8807294599e04c7dc15db076cf0 src/includes/KTextEditor/TemplateInterface2 de9d9451796710756287bfc2a627f7ae43a006b1 src/includes/KTextEditor/TemplateInterface 0142d17815fabb9136836effa61114aaa1994635 src/includes/KTextEditor/SessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 src/includes/KTextEditor/SearchInterface f7dffc91739e82cceffea35de0632cb19e92ab0a src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e Diff: https://git.reviewboard.kde.org/r/117017/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117017: Remove forward headers for KTextEditor
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117017/ --- (Updated March 24, 2014, 2:58 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Dominik Haumann. Repository: kde4support Description --- Remove forward headers for KTextEditor Some of the headers have actually been removed already. Keeping broken forward headers actually makes it *more* difficult to port. Diffs - src/includes/KTextEditor/CommandExtension 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/Command 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/CodeCompletionModelControllerInterface a92ceb40a0d0afbf42d8b3302492b8e52a7f8505 src/includes/KTextEditor/CodeCompletionModel 3511d00b212e5c56613bf4f06fedc5a5d76cb3bc src/includes/CMakeLists.txt bc7d00f85012ec436937fd3d402e9c08e28f6b74 src/includes/KTextEditor/Attribute 6420e896e93532188d08894853176842c7d8ccae src/includes/KTextEditor/CodeCompletionInterface 41341c38dd92e7c1533b0ba74eceb735408a1d3f src/includes/KTextEditor/Document 858d360f8ae751c16b03d350d7e415bea400906d src/includes/KTextEditor/Cursor 2811cda0f69b3c263ac8b2dd210b50f6239f7ff2 src/includes/KTextEditor/ConfigPage b3904bee10ffc0245bca1a928389237813850ec3 src/includes/KTextEditor/ConfigInterface 0617835fc7621c4c26a2d50ca95d12d8870fffc2 src/includes/KTextEditor/CommandInterface 4187c61882a83cab906fa87cd16bd18229b6efb5 src/includes/KTextEditor/ModificationInterface 50df2902648156dc5cd4630f587add36d320a43a src/includes/KTextEditor/MessageInterface 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/Editor 76d55675c78248875996b0284288a34af303e8c7 src/includes/KTextEditor/HighlightInterface 8c8c94ec679877be7e3965eba86498f06b67a883 src/includes/KTextEditor/MarkInterface 87adf561b38045bdd65fc3f64f24311aa901d8ee src/includes/KTextEditor/Message 41d9aa45a8edb7b9b50e0b82c7b113b6e07bcb32 src/includes/KTextEditor/ParameterizedSessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/MovingRange 89f68605ffa863862476831cfb836660a70e4931 src/includes/KTextEditor/MovingInterface bde16eaca7d68517ce7c2068186eb641daf6eab1 src/includes/KTextEditor/MovingCursor 7c9eb3074e4feace09cca78962caf1ff27bd6394 src/includes/KTextEditor/View 411c995972b47e7a2ad4a385a6924e3a67f8c892 src/includes/KTextEditor/VariableInterface 126a93691700fab3134400907d0ba93a4e275f0d src/includes/KTextEditor/TextHintInterface 6b05d9a4a45ac8807294599e04c7dc15db076cf0 src/includes/KTextEditor/TemplateInterface2 de9d9451796710756287bfc2a627f7ae43a006b1 src/includes/KTextEditor/TemplateInterface 0142d17815fabb9136836effa61114aaa1994635 src/includes/KTextEditor/SessionConfigInterface 8c26b7d418e81072df4e7dffe0038d7fdc1e3010 src/includes/KTextEditor/Range 15aad643ee6f1f95b96f579bc66cc84f4873d006 src/includes/KTextEditor/SearchInterface f7dffc91739e82cceffea35de0632cb19e92ab0a src/includes/KTextEditor/Plugin 1016b2e5c5f930afcceb1110b00468ee1158cf7e Diff: https://git.reviewboard.kde.org/r/117017/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
Am Donnerstag, 27. Februar 2014, 21:15:54 schrieb Michael Pyne: On Thu, February 27, 2014 11:35:16 Kevin Funk wrote: Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne: On Wed, February 26, 2014 22:30:48 Milian Wolff wrote: Also, while at it, could we get a truly verbose flag, which actually outputs the output from whatever tool is currently running? If you file a bug I'd probably implement it. --debug did this kind of thing (it might even still do it, but it would be too annoying to use here). I say file a bug only because it's guaranteed it'll drop off my plate otherwise. Yep, --debug still works as intended. I use it a lot, but only if I build single packages or combined with --stop- on-failure=1. You should document that --debug flag, too, I'd say. I had to grep the code for it as well when I first wondered how to make kdesrc-build print everything to stdout. It's documented in both the man page and the DocBook/website documentation. Do you mean that the documentation is inadequate? It's also possible it wasn't documented when you looked but I've already fixed it. ;) Regards, - Michael Pyne Indeed, that's true. I was more referring to the help out you get with --help. Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne:
On Wed, February 26, 2014 22:30:48 Milian Wolff wrote:
Hey,
not sure this is the right list. I noticed that kdesrc-build happily
continues building even when a module failed to build. Is this desired?
Yes, it's on purpose. The idea is that most people are not building KDE for
the first time and don't need to have the whole compile aborted because
mpyne committed a fail-to-build bug in juk or something.
Couldn't instead the _full_ error log be cat'ed and the build stopped?
Now,
I have to hunt down the error log manually which is really cumbersome. If
others think this behavior is good, could I vote for an additional cli
argument to stop after any failure?
Yes, kdesrc-build can do (most) of this. I thought I documented it as a
command line option but it turns out that it was a kdesrc-buildrc option.
But you can still reach it via command line by passing --stop-on-failure=1
As far as the error log file, its location gets output at the end (which
will be very soon indeed if you pass --stop-on-failure), and I think dfaure
might still have an open bug about reporting the logfile location
immediately upon failure.
However, what I personally do is that I added a small bash function to my
.bashrc, errorLog, which does something like:
errorLog() {
$EDITOR ~/log-kdesrc-build/latest/$1/error.log
}
where ~/log-kdesrc-build should be wherever your log directory is (probably
$srcdir/log). kdesrc-build maintains symlinks throughout the log directory
to make it easy to find the last log set for a given module, and which log
contains the error if the module failed (i.e. if you see an error.log in a
specific log directory it means that module failed to build that run).
Also, while at it, could we get a truly verbose flag, which actually
outputs the output from whatever tool is currently running?
If you file a bug I'd probably implement it. --debug did this kind of thing
(it might even still do it, but it would be too annoying to use here). I say
file a bug only because it's guaranteed it'll drop off my plate
otherwise.
Yep, --debug still works as intended.
I use it a lot, but only if I build single packages or combined with --stop-
on-failure=1.
You should document that --debug flag, too, I'd say. I had to grep the code
for it as well when I first wondered how to make kdesrc-build print everything
to stdout.
For me as a
developer, its really annoying having to tail -f on some random log files
to get my hands on the make output... How are other developers handling
this?
I just watch the percentages in the kdesrc-build output personally. When I'm
doing development I don't use kdesrc-build at all; I still retain my 'cs'
and 'cb' shell macros to switch between individual source/build dirs as
needed and manually do my git-fu and make-n-shake so that I can see
compiler warnings.
I'm sorry if it's been annoying to use but I'm always open to improvements
(especially improvements with patches, but no one else seems to like Perl...
;)
In the meantime there are other, better-documented, command line options
which are useful. Documentation is available at
http://kdesrc-build.kde.org/documentation/, and if you build kdesrc-build
it should install a man page to $KDEDIR/share/man/man1 or thereabouts.
I've recently become a big fan of --resume-from (or -after), --stop-before
(or -after) and --ignore-modules options myself. And always --pretend.
Regards,
- Michael Pyne
Cheers
--
Kevin Funk
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Compile errors originating from libKF5XsltKde.a
Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile errors originating from libKF5XsltKde.a
Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk: Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets Note: That happens with any static library it seems -- just got the same for libkatefiletree.a. So, any ideas how to solve this in a generic way? Cheers -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile errors originating from libKF5XsltKde.a
Am Donnerstag, 27. Februar 2014, 15:24:30 schrieb Kevin Funk: Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk: Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets Note: That happens with any static library it seems -- just got the same for libkatefiletree.a. So, any ideas how to solve this in a generic way? Cheers Just discussed this a bit with Stephen on IRC: We need to set the compile flags manually on each static library used in a shared library -- there's no way for CMake to figure out if a static library will be added to a shared one. So, we have to specify set_target_properties(MyStaticLib PROPERTIES POSITION_INDEPENDENT_CODE TRUE) manually for each of them Also see: http://cmake.3232098.n2.nabble.com/SHARED-library-containing-OBJECT-library-Missing-fPIC-tp7580514p7580571.html I'll file some patches Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
