Re: c++ plugins with Frameworks 5
On Monday 03 March 2014 12:28:07 Aaron J. Seigo wrote: do we want .desktop files as well as generated .json? if so, for applications that wish to put additional data in the json files, is it expected that they continue to do this by adding more “X-Foo” entries to the [Desktop Entry] group in their .desktop files? (as opposed to providing actual json) whatever the decision is, more work will be needed: * desktoptjson does not support translations currently (made difficult by use of KConfig) and does not support application extensions to the json very well, both of which need attention. * in the json-only approach is adopted, KPluginInfo and possibly even ksycoca would need adjusting (the latter to preserve the ability to do KService-based queries) i’m willing and able to do the latter if the decision is made to support json- only. (i’m not willing to do that work if it isn’t, as i prefer not to waste my time :) I am completely in favour of dropping .desktop files so that we can drop ksycoca, which is my number one target for being shot down. The plan for app desktop files (as per my last freedesktop-summit report) is a mmap'able binary cache generated at install time with a cross-desktop tool. This leaves no room for kde-specific plugins (Type=Service desktop files), so either we make our own binary cache for these, or... we drop desktop files altogether. But then the question is indeed, how will we make queries (other than give me all the plugins of type foo which can and should be done by organizing them in a subdir foo). What I don't know is how much do we need support for queries that filter this further, and whether just reading the json from all the plugins of type foo is good enough. All this being said, please ensure you get feedback from Sebas too, who worked a lot on this stuff :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On Tuesday 04 March 2014 01:04:05 John Layt wrote: So, now KPrintUtils and KUnitConversion are about done (bar the KCurrencyCode move), are there any other Frameworks needing review? All the unmaintained ones, some of the maintained ones too. At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime are unclaimed? Is it an offer to be the maintainer for more frameworks? Be my guest. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116568: Fixes to PIC image format handler
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/#review51854 --- Ship it! Too many C casts to not get nightmares, but other than that... src/imageformats/pic.cpp https://git.reviewboard.kde.org/r/116568/#comment36898 Does this work on both big endian and little endian architectures? It looks like it's extracting individual bytes out of an int, which is not portable... - David Faure On March 3, 2014, 1:15 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/ --- (Updated March 3, 2014, 1:15 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Fixes to PIC image format handler Better error handling (returns false on error in read() and write()) and use the correct format if there is no alpha channel. Diffs - src/imageformats/CMakeLists.txt 44f07dd7bfb7daa1be21ececdfb5061a262e0fc8 src/imageformats/pic.cpp 9d8a7ede31c5c03a699d6a76c88aeb5e3d37ac4a src/imageformats/pic_read.cpp 484c63426723e04e5c7e96ae5355ccceccab03f4 src/imageformats/pic_rw.h 2cc958927403de57049bbd7cb3200f0b7489da3c src/imageformats/pic_write.cpp 0632eebd507e58e480856b53e71c24afc543de26 Diff: https://git.reviewboard.kde.org/r/116568/diff/ Testing --- Builds and tests pass, both with and without https://git.reviewboard.kde.org/r/116567/ applied. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Tue, Mar 4, 2014 at 9:30 PM, David Faure fa...@kde.org wrote: On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? Jenkins has an Web API which can be used, as well as a Java client to help interact with it. In terms of modifying the configuration files on disk - they're XML based data, and i'm not sure if we can get Jenkins to reparse them short of restarting it completely. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: knotifications_master_qt5 #36
See http://build.kde.org/job/knotifications_master_qt5/36/changes Changes: [mklapetek] Bump the tier to tier 3 -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 4 in workspace http://build.kde.org/job/knotifications_master_qt5/ws/ Running Prebuild steps [knotifications_master_qt5] $ /bin/sh -xe /tmp/hudson356438499265688336.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/knotifications 188ff5e..7cf525f master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 188ff5e Merge branch 'mklapetek/knotify-merge' Removing build/ Success build forhudson.tasks.Shell@58d90e59 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/knotifications Checking out Revision 7cf525fa62dca45f5694e887d1f81886af89fee8 (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [knotifications_master_qt5] $ /bin/sh -xe /tmp/hudson5708246479811502213.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: knotifications - Branch master == Build Dependencies: kwindowsystem - Branch master extra-cmake-modules - Branch master cmake - Branch master qt5 - Branch stable == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib64/libX11.so CMake Error at CMakeLists.txt:42 (find_package): By not providing FindKF5Service.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by KF5Service, but CMake did not find one. Could not find a package configuration file provided by KF5Service (requested version 4.97.0) with any of the following names: KF5ServiceConfig.cmake kf5service-config.cmake Add the installation prefix of KF5Service to CMAKE_PREFIX_PATH or set KF5Service_DIR to a directory containing one of the above files. If KF5Service provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! See also http://build.kde.org/job/knotifications_master_qt5/ws/build/CMakeFiles/CMakeOutput.log;. Configure step exited with non-zero code, assuming failure to configure for project knotifications. Build step 'Execute shell' marked build as failure [File exists] check if file exists [build/JUnitTestResults.xml] Run condition [File exists] preventing perform for step [Publish JUnit test result report] [File exists] check if file exists [build/cppcheck.xml] Run condition [File exists] preventing perform for step [Publish Cppcheck results] [WARNINGS] Skipping publisher since build result is FAILURE ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: knotifications_master_qt5 #37
See http://build.kde.org/job/knotifications_master_qt5/37/ -- Started by user gateau Building remotely on LinuxSlave - 4 in workspace http://build.kde.org/job/knotifications_master_qt5/ws/ Running Prebuild steps [knotifications_master_qt5] $ /bin/sh -xe /tmp/hudson8851217383914655247.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 7cf525f Bump the tier to tier 3 Removing build/ Success build forhudson.tasks.Shell@58d90e59 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/knotifications Checking out Revision 7cf525fa62dca45f5694e887d1f81886af89fee8 (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [knotifications_master_qt5] $ /bin/sh -xe /tmp/hudson2358948367663513724.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: knotifications - Branch master == Build Dependencies: kiconthemes - Branch master kdbusaddons - Branch master kguiaddons - Branch master kwindowsystem - Branch master kdoctools - Branch master kjs - Branch master ki18n - Branch master cmake - Branch master polkit-qt-1 - Branch qt5 kcrash - Branch master kwidgetsaddons - Branch master karchive - Branch master kservice - Branch master kconfigwidgets - Branch master kitemviews - Branch master kcoreaddons - Branch master kconfig - Branch master kcodecs - Branch master kauth - Branch master extra-cmake-modules - Branch master qt5 - Branch stable == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib64/libX11.so CMake Error at CMakeLists.txt:48 (find_package): Could not find a package configuration file provided by Phonon4Qt5 (requested version 4.6.60) with any of the following names: Phonon4Qt5Config.cmake phonon4qt5-config.cmake Add the installation prefix of Phonon4Qt5 to CMAKE_PREFIX_PATH or set Phonon4Qt5_DIR to a directory containing one of the above files. If Phonon4Qt5 provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! See also http://build.kde.org/job/knotifications_master_qt5/ws/build/CMakeFiles/CMakeOutput.log;. Configure step exited with non-zero code, assuming failure to configure for project knotifications. Build step 'Execute shell' marked build as failure [File exists] check if file exists [build/JUnitTestResults.xml] Run condition [File exists] preventing perform for step [Publish JUnit test result report] [File exists] check if file exists [build/cppcheck.xml] Run condition [File exists] preventing perform for step [Publish Cppcheck results] [WARNINGS] Skipping publisher since build result is FAILURE ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116591: Use dedicated NET::Properties and NET::Properties2 in NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116591/ --- Review request for KDE Frameworks. Repository: kwindowsystem Description --- Use dedicated NET::Properties and NET::Properties2 in NETWinInfo This replaces the usage of the unsinged long[] array with NET::Properties as first element and optional NET::Properties2 as second element by a dedecated variable for each of them. This includes the following changes: * NETWinInfo::event(xcb_generic_event_t*) return NET::Properties * new overload added for NETWinInfo::event taking NET::Properties* and NET::Properties2* as arguments * existing overload for NETWinInfo::event taking unsigned long* as argument is deprecated and forwards to the new added overload * NETWinInfo::passedProperties returns NET::Properties and a new NETWinInfo::passedProperties2 is added which returns the NET::Properties2. This is a SC-break, but it's only used internally in KWindowInfo * ctor taking unsigned long* is changed to taking NET::Properties and NET::Properties2. This is also a SC-break, but the ctor broke already caused by the change from Display* to xcb_connection_t* * other ctor is deprecated as the difference is no longer relevant Diffs - autotests/netwininfotestclient.cpp 030881cf47ddc38b89e49a59dfd5deff309a0038 autotests/netwininfotestwm.cpp 5a6697c56462d52777cc9eec0a3eb5b3d03b7693 src/kwindowinfo_x11.cpp 358bcfedc6c5c75c104fbb4ec3666bd8578bff7d src/netwm.h a5ad46fa1f0255ca6719224079bdea4598b48c51 src/netwm.cpp 288a34348f464e1158640afa1d931d9d05690cc4 src/netwm_p.h 1c26d47257a4f3ce71c360c394cc5be16f32b18c Diff: https://git.reviewboard.kde.org/r/116591/diff/ Testing --- unit tests still succeed; further testing: installing and compiling KWin and Plasma against it. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116591: Use dedicated NET::Properties and NET::Properties2 in NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116591/ --- (Updated March 4, 2014, 10:50 a.m.) Review request for KDE Frameworks. Changes --- adjusted KWin and Plasma for testing Repository: kwindowsystem Description --- Use dedicated NET::Properties and NET::Properties2 in NETWinInfo This replaces the usage of the unsinged long[] array with NET::Properties as first element and optional NET::Properties2 as second element by a dedecated variable for each of them. This includes the following changes: * NETWinInfo::event(xcb_generic_event_t*) return NET::Properties * new overload added for NETWinInfo::event taking NET::Properties* and NET::Properties2* as arguments * existing overload for NETWinInfo::event taking unsigned long* as argument is deprecated and forwards to the new added overload * NETWinInfo::passedProperties returns NET::Properties and a new NETWinInfo::passedProperties2 is added which returns the NET::Properties2. This is a SC-break, but it's only used internally in KWindowInfo * ctor taking unsigned long* is changed to taking NET::Properties and NET::Properties2. This is also a SC-break, but the ctor broke already caused by the change from Display* to xcb_connection_t* * other ctor is deprecated as the difference is no longer relevant Diffs - autotests/netwininfotestclient.cpp 030881cf47ddc38b89e49a59dfd5deff309a0038 autotests/netwininfotestwm.cpp 5a6697c56462d52777cc9eec0a3eb5b3d03b7693 src/kwindowinfo_x11.cpp 358bcfedc6c5c75c104fbb4ec3666bd8578bff7d src/netwm.h a5ad46fa1f0255ca6719224079bdea4598b48c51 src/netwm.cpp 288a34348f464e1158640afa1d931d9d05690cc4 src/netwm_p.h 1c26d47257a4f3ce71c360c394cc5be16f32b18c Diff: https://git.reviewboard.kde.org/r/116591/diff/ Testing (updated) --- unit tests still succeed; further testing: KWin and Plasma are still working Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On March 4, 2014, 12:06 a.m., Aleix Pol Gonzalez wrote: Ok, I just realized this was being dealt with and I did a different patch: https://git.reviewboard.kde.org/r/116573/ I think that having UI strings on a header file is quite bad TBH, but since I see there's consensus I'll discard it. Somewhat confusingly, the diff in this RR was not what was committed, but instead the diff in the comments. See http://commits.kde.org/kio/bf41a9aa94881db1d7f85c41aa35277c6e118574 - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/#review51844 --- On March 3, 2014, 8:59 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/ --- (Updated March 3, 2014, 8:59 p.m.) Review request for KDE Frameworks. Repository: kio Description --- include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is publically installed. Diffs - KF5KIOConfig.cmake.in 3a947b7 src/core/CMakeLists.txt d897e37 Diff: https://git.reviewboard.kde.org/r/116103/diff/ Testing --- Thanks, Matthieu Gallien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: c++ plugins with Frameworks 5
On Tuesday, March 04, 2014 09:22:11 David Faure wrote: What I don't know is how much do we need support for queries that filter this further, and whether just reading the json from all the plugins of type foo is good enough. In my tests it was expectedly slow: scaling linearly with number of plugins and touching disk all the time. My conclusion is that without a cache, we'll be introducing performance regressions, which means if you need fast plugin querying, KPluginTrader right now is not for you. When working in KPluginTrader, I've ported the query system from KServiceTypeTrader, so querying should not be a problem -- it works today. Maybe I'm misunderstanding something? Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : knotifications_master_qt5 #38
See http://build.kde.org/job/knotifications_master_qt5/38/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: c++ plugins with Frameworks 5
On Tuesday 04 March 2014 11:21:06 Sebastian Kügler wrote: On Tuesday, March 04, 2014 09:22:11 David Faure wrote: What I don't know is how much do we need support for queries that filter this further, and whether just reading the json from all the plugins of type foo is good enough. In my tests it was expectedly slow: scaling linearly with number of plugins and touching disk all the time. My conclusion is that without a cache, we'll be introducing performance regressions, which means if you need fast plugin querying, KPluginTrader right now is not for you. When working in KPluginTrader, I've ported the query system from KServiceTypeTrader, so querying should not be a problem -- it works today. OK, so it works but it's slow for lack of a cache, then. So what we're missing is a cache :) Unless someone has a plan for it, my suggestion would be, let's model it after the upcoming app desktop cache, i.e. update it at install time. I'll be working on that later this year, hopefully. But meanwhile this confirms that we won't need .desktop files, so Aaron, you can go ahead -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116588: Improve the README
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/#review51865 --- README.md https://git.reviewboard.kde.org/r/116588/#comment36905 allows to interact with is bad grammar; allows interaction with would work, and allows foo to interact with would be better. Maybe clients in place of foo? - Alex Merry On March 4, 2014, 7:49 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 7:49 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the README Diffs - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 02/03/14 18:58, Kevin Ottens wrote: On Thursday 27 February 2014 17:15:56 John Layt wrote: I've done the first step, and I just need a volunteer to do the git magic required to: * Move kcurrencycode.h and kcurrencycode.cpp including history from kunitconversion/src to kde4support/src/kdecore * Move kde-runtime/localization and everything in it including history to kde4support/src/localization or kde4support/runtime/localization or wherever deemed appropriate * Move kde-runtime/l10n and everything in it including history into the same localization folder as above but folder renamed from l10n to localization/country (i.e. at same level as currency folder) * Make sure the data files are built and installed, but need to think about parallel installs with KDE4 data files The data file moves are part of the kde-runtime clean-up, but it makes sense to do them alongside the code moves. Any taker for those moves? Alex, I think you already did a couple of those right? OK, I'll have a look at some point this week. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116588: Improve the README
On March 4, 2014, 12:02 p.m., Alex Merry wrote: README.md, line 9 https://git.reviewboard.kde.org/r/116588/diff/1/?file=251921#file251921line9 allows to interact with is bad grammar; allows interaction with would work, and allows foo to interact with would be better. Maybe clients in place of foo? what are clients? It's obvious if one knows what the framework does, but if you don't know a client could be anything. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/#review51865 --- On March 4, 2014, 8:49 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 8:49 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the README Diffs - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116568: Fixes to PIC image format handler
On March 4, 2014, 8:28 a.m., David Faure wrote: src/imageformats/pic.cpp, line 452 https://git.reviewboard.kde.org/r/116568/diff/2/?file=251701#file251701line452 Does this work on both big endian and little endian architectures? It looks like it's extracting individual bytes out of an int, which is not portable... Hm, I think you're right. It also never checks or changes the QImage format. Given that I'm the maintainer of the kimageformats, it may be worth me setting up an emulator for a big-endian architecture. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/#review51854 --- On March 3, 2014, 1:15 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/ --- (Updated March 3, 2014, 1:15 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Fixes to PIC image format handler Better error handling (returns false on error in read() and write()) and use the correct format if there is no alpha channel. Diffs - src/imageformats/CMakeLists.txt 44f07dd7bfb7daa1be21ececdfb5061a262e0fc8 src/imageformats/pic.cpp 9d8a7ede31c5c03a699d6a76c88aeb5e3d37ac4a src/imageformats/pic_read.cpp 484c63426723e04e5c7e96ae5355ccceccab03f4 src/imageformats/pic_rw.h 2cc958927403de57049bbd7cb3200f0b7489da3c src/imageformats/pic_write.cpp 0632eebd507e58e480856b53e71c24afc543de26 Diff: https://git.reviewboard.kde.org/r/116568/diff/ Testing --- Builds and tests pass, both with and without https://git.reviewboard.kde.org/r/116567/ applied. 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 116588: Improve the README
On March 4, 2014, 11:02 a.m., Alex Merry wrote: README.md, line 9 https://git.reviewboard.kde.org/r/116588/diff/1/?file=251921#file251921line9 allows to interact with is bad grammar; allows interaction with would work, and allows foo to interact with would be better. Maybe clients in place of foo? Martin Gräßlin wrote: what are clients? It's obvious if one knows what the framework does, but if you don't know a client could be anything. Other options could be applications or programs. If you don't think any of them fit, and can't think of anything else, use the passive version (allows interaction with). - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/#review51865 --- On March 4, 2014, 7:49 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 7:49 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the README Diffs - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: c++ plugins with Frameworks 5
On Tuesday, March 4, 2014 11:52:11 David Faure wrote: Unless someone has a plan for it, my suggestion would be, let's model it after the upcoming app desktop cache, i.e. update it at install time. I'll This sounds perfect. In that vein, I did do some measuring of what takes time, and it really is nothing surprising. Extracting and parsing the json from the library files themselves is fast enough. My 3 year old laptop parse 1000+ plugins' info per second, complete with a few dozen translations in each. What is slow is actually getting the data off disk when the OS’s disk cache is cold. SSDs obviously incur less penalty here and rotating disks more. The performance on a typical rotating laptop HDD drops to ~50-70 plugins per second. Not horrible, but also not awesome. But meanwhile this confirms that we won't need .desktop files, so Aaron, you can go ahead Great :) If we can eventually get the i18n process using the json directly, then we can get rid of the .desktop files altogether. Until then, however, we’ll need to keep them. So currently my game plan is this: * create a small QtCore-only tool that transforms a .desktop file into a .json file, without translations * adapt the tool I already have written that updates translations from .desktop files into the json files; it will remain QtCore only * change the kservice_desktop_to_json cmake macro to use that tool * adjust KPluginInfo to read the metadata correctly (inc. i18n) once the app desktop cache is in place, then we can stop installing the .desktop files. once the i18n process has been migrated to use the json files directly, then we can remove the .desktop files from the repositories. -- Aaron J. Seigo 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 116588: Improve the README
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 1:32 p.m.) Review request for KDE Frameworks. Changes --- went for allows interaction with Repository: kwindowsystem Description --- Improve the README Diffs (updated) - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116588: Improve the README
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/#review51872 --- Ship it! Ship It! - Alex Merry On March 4, 2014, 12:32 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 12:32 p.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the README Diffs - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 4 March 2014 09:25, Kevin Ottens er...@kde.org wrote: On Tuesday 04 March 2014 01:04:05 John Layt wrote: So, now KPrintUtils and KUnitConversion are about done (bar the KCurrencyCode move), are there any other Frameworks needing review? All the unmaintained ones, some of the maintained ones too. At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime are unclaimed? Is it an offer to be the maintainer for more frameworks? Be my guest. :-) It is, as I seem to have lost one along the way ;-) I was thinking by reviewing some of them I'd get a better idea of what would be suitable for me, so if there's any you think are higher priority let me know. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On Tuesday 04 March 2014 15:29:33 John Layt wrote: On 4 March 2014 09:25, Kevin Ottens er...@kde.org wrote: On Tuesday 04 March 2014 01:04:05 John Layt wrote: So, now KPrintUtils and KUnitConversion are about done (bar the KCurrencyCode move), are there any other Frameworks needing review? All the unmaintained ones, some of the maintained ones too. At Tier 1 level it just looks like KCodecs, KGuiAddons and KIdleTime are unclaimed? Is it an offer to be the maintainer for more frameworks? Be my guest. :-) It is, as I seem to have lost one along the way ;-) I was thinking by reviewing some of them I'd get a better idea of what would be suitable for me, so if there's any you think are higher priority let me know. KGuiAddons definitely. The other two are important too, but this one is even more important. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On 4 March 2014 15:59, Kevin Ottens er...@kde.org wrote: KGuiAddons definitely. The other two are important too, but this one is even more important. OK, I'll get onto that then. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116090: Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
On Feb. 27, 2014, 10:54 a.m., Alex Merry wrote:
The problem with doing this in support code is that it is not strictly
source compatible. An example this would break is if you want to embed the
value of QT_QMAKE_EXECUTABLE into a C++ executable using something like
add_definitions(-DQMAKE=\${QT_QMAKE_EXECUTABLE}\)
Any use of QMAKE in the program would then expand to
$TARGET_FILE:Qt5::qmake, which is obviously not what was wanted.
Ah, didn't know that, should I drop this request?
- Alexander
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/#review51010
---
On Feb. 26, 2014, 6:03 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/
---
(Updated Feb. 26, 2014, 6:03 p.m.)
Review request for KDE Frameworks.
Repository: kde4support
Description
---
Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
This means CMake no longer warns about Policy CMP0026 is not set when
building projects that need kde4support
Diffs
-
cmake/modules/ECMQt4To5Porting.cmake
4204fa541790aa38c74b9d6f0b2111af2157b2bc
cmake/modules/KDE4Macros.cmake 192094b1c5c6877cd9dfa18dc27338c491d753f3
src/CMakeLists.txt 6bda0996c118ce212860e02d0505fd3bdc026833
src/KDEUIMacros.cmake 1570df340a672a597a0b7480885c340faca0069d
Diff: https://git.reviewboard.kde.org/r/116090/diff/
Testing
---
kde4support compiles, kde-workspace compiles
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116598: Check versions for individual components of Wayland
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116598/
---
Review request for Build System, Extra Cmake Modules, KDE Frameworks, and
Martin Gräßlin.
Repository: extra-cmake-modules
Description
---
First part of the diff makes sure find_package_handle_standard_args() gets a
version number to check against.
Second part ensures we get proper results from pkg-config even if not all
components are available. find_package(Wayland COMPONENTS Client Egl) was
failing for me because I have Client installed but not Egl, causing
pkg_check_modules() to not set any PKG_Wayland_${comp} variable.
Diffs
-
find-modules/FindWayland.cmake 21014fc
Diff: https://git.reviewboard.kde.org/r/116598/diff/
Testing
---
Together with a change for kde-workspace, it fixes the build of kde-workspace
on my system with wayland-client 1.1 and no wayland-egl.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes 2014-w10
Hello everyone, This is the minutes of the Week 10 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, mck182, mgraesslin, notmart, Riddell, sebas, teo, tosky and myself. Announcement: * Alpha 2 is out! * Next stop beta 1, once it hits the door we freeze API and feature set, you have a small window if you still want to tackle those; * Repository merges for kwallet and kdnssd still reported as pending... * If you plan to attend the KF5 sprint, please register before friday, we need to settle on the budget: https://sprints.kde.org/sprint/224 * afiestas has kwallet patches in need of review, valir being unresponsive help is welcome; * he also worked on cleaning up kded removing obsoleted bits; * agateau finally got the dependency diagrams on api.kde.org; * he's also looking in avoiding hardcoded frameworks list on api.kde.org; * he also did some reviews and fixes; * he's waiting for review on https://git.reviewboard.kde.org/r/116088/ ; * last but not least he's about to post some wayland cmake fixes; * alexmerry did a bunch of git merges; * he's also dealing with the kdnssd merges (which turn out into not merging and introducing kioslaves framework); * he also did reviews and fixes here and there; * and finally he wrote docs for writing FindFoo.cmake to be upstreamed; * apol is working on kde-runtime tasks, porting to KF5, help is welcome; * mck182 merged the knotify branch in knotifications; * he's now going to kill knotify from kde-runtime; * mgraesslin worked on ecm to improve FindEGL and FindWayland; * he also worked on frameworkintegration to get QSystemTrayIcon mapped to a status notifier; * he's also doing a few more cleanups in NETWM; * notmart is planning to move some of the imports depending on a single framework to the framework itself; * he also plans to remove a method which is dead code; * sebas requested to do an exceptional 4.97.1 release of plasma-framework for the needs of Plasma Next Alpha next week; * he promised to make that a one time event though, next releases of plasma will depend only on released KF5; * Riddell changed the SONAME of all the libraries to 5; * he also got busy bees packaging alpha 2; * he reminds us that we should get serious at l10n: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/l10n * last but not least, this review is in need of love: https://git.reviewboard.kde.org/r/116583 * teo is still working on ksecrets and got a bit burned out; * he moved to kde-baseapps for a while; * tosky is waiting on feedback on the docbook changes (PLEASE REVIEW): https://git.reviewboard.kde.org/r/116068/ https://git.reviewboard.kde.org/r/116069/ * he's also investigating a bug in meinproc; * and he's planning to do some cleanups in kdoctool; * and he's asking to review the requests above PLEASE; * ervin is just sending emails around; If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KCodecs - Quick Review
Hi, I know nothing about text codecs, but I've had a *very* quick look at KCodecs: * Original code by Lars dated 1999! * One method marked as deprecated to be removed for KDE4 * ###FIXME KDE4: the name of the encodings should mostly be uppercase * Code generated by script generate_string_table.pl located in kdesdk/scripts * Algorithms marked as copyright by RSA Data Security and others, but no mention what the original licence was or real link to original source * Encoding probers and lookup tables marked as copyright Mozilla 1998, X11 license * kentities.c is documented as generated by gperf from either kentities.gperf and/or khtmlentities.gperf but neither are in kcodecs, instead they are in khtml as is another copy of kentities.c. * Public API using boolean parms This suggests it could do with some attention: * Check still valid to remove deprecated code? * Check if encoding names should be made uppercase? * The generate_string_table.pl script should probably be moved into KCodecs, unless it has more general use? * The RSA and other algorithms may need checking for licensing issues, or at least improve the license documentation? * The probers may need to be checked they are still up to date with the original Mozilla code and look-up tables? * kentities.c needs investigation and I suspect moving all the files from khtml to kcodecs, with khtml then using kcodecs? Or at least docs added that this is where it comes from and should be kept in sync. I wonder how much of this functionality is now done in Qt5? Would it benefit from a functional review by someone who knows what they're doing, like Thiago or David? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Use KDEInstallDirs
On March 1, 2014, 1:32 p.m., Lamarque Souza wrote: CMakeLists.txt, line 23 https://git.reviewboard.kde.org/r/116098/diff/2/?file=246596#file246596line23 NMQt is supposed to depend on Qt only. What is E-C-M? Does GNUInstallDirs support all platforms that NetworkManager support? I do not want to break things for those that have NetworkManager but not GNUInstallDirs. Using -DLIB_SUFFIX=64 is simple and works for everybody. Is there any real issue solved by GNUInstallDirs that cannot be solved by -DLIB_SUFFIX=64? GNUInstallDirs comes with CMake, so should be available everywhere. E-C-M (extra-cmake-modules) is currently a hard dependency, however not used anywhere, I will remove it in the new diff. GNUInstallDirs fixes the issue that I had with -DLIB_SUFFIX=64, I didn't know I needed it, because all other frameworks install into the correct directory without it. I only noticed because network management didn't work with my KF5 installation. Only after looking at the CMakeLists.txt did I find out why. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/#review51427 --- On March 1, 2014, 12:14 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated March 1, 2014, 12:14 p.m.) Review request for KDE Frameworks, Daniel Nicoletti, Lamarque Souza, and Sebastian Kügler. Repository: libnm-qt Description --- When I build libnm-qt on my openSuSE 64bit system libnm-qt ends up installing into $prefix/lib instead of $prefix/lib64. I know this can be fixed using -DLIB_SUFFIX=64, but KDEInstallDirs already handles this so why not use it. E-C-M is already required, so that is no problem. Not sure however whether it is okay to use one of the KDE modules for libnm-qt. If not I will update this request to use GNUInstallDirs which also handles the openSuSE case. Not sure who is responsible for the qt5 branch, so I just added kdeframeworks as reviewers. Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. grep -irn LIB_SUFFIX * returns nothing Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116087: KCrash: remove usage of strlcpy
On March 1, 2014, 5:17 p.m., David Faure wrote:
Hmm, this might be equivalent, but all it means is that the orig code was
wrong.
We should not make any memory allocations within the crash handler.
So we should instead store the startup id as a const char* somewhere and
use strlcpy.
Unless we can make sure that the call to startupId() will always just
return an existing QByteArray - but looking at the code, this doesn't seem
to be the case.
Alex Merry wrote:
Hrm... I think we're actually querying the wrong place anyway. We should
be asking the xcb platform plugin, since that's what actually handles the
startup notifications, since the demise of KApplication (perhaps that part of
KStartupInfo's functionality should be stripped out?).
Note that the platform plugin does always just return an existing
QByteArray, so that should be fine. Which is good, because taking our own
copy outside the handler would not work, as we would need to know when it was
cleared.
Alex Merry wrote:
Actually, you don't get access to the QByteArray. You could do something
like
QPlatformNativeInterface *platform =
QGuiApplication::platformNativeInterface();
const char * startupId = reinterpret_castchar
*(platform-nativeResourceForIntegration(QByteArrayLiteral(startupid)));
if (startupId *startupId) {
argv[i++] = --startupid;
argv[i++] = startupId;
}
Since we're in the crash handler, is it safe to assume that the rest of
the application is stopped, and so that string will never disappear from
underneath us?
I'll update the review to use this solution if someone else can confirm that
this is safe. Even in multithreaded environments? Does the crash handler stop
all threads?
- Alexander
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116087/#review51440
---
On Feb. 26, 2014, 6 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116087/
---
(Updated Feb. 26, 2014, 6 p.m.)
Review request for KDE Frameworks.
Repository: kcrash
Description
---
remove usage of strlcpy
That copy was actually unnecessary, incrementing the refcount on
QByteArray and then calling constData() is enough
Diffs
-
src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f
src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d
src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e
src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8
Diff: https://git.reviewboard.kde.org/r/116087/diff/
Testing
---
Compiles
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116598: Check versions for individual components of Wayland
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116598/#review51904
---
+1 but someone else has to approve
- Martin Gräßlin
On March 4, 2014, 4:53 p.m., Aurélien Gâteau wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116598/
---
(Updated March 4, 2014, 4:53 p.m.)
Review request for Build System, Extra Cmake Modules, KDE Frameworks, and
Martin Gräßlin.
Repository: extra-cmake-modules
Description
---
First part of the diff makes sure find_package_handle_standard_args() gets a
version number to check against.
Second part ensures we get proper results from pkg-config even if not all
components are available. find_package(Wayland COMPONENTS Client Egl) was
failing for me because I have Client installed but not Egl, causing
pkg_check_modules() to not set any PKG_Wayland_${comp} variable.
Diffs
-
find-modules/FindWayland.cmake 21014fc
Diff: https://git.reviewboard.kde.org/r/116598/diff/
Testing
---
Together with a change for kde-workspace, it fixes the build of kde-workspace
on my system with wayland-client 1.1 and no wayland-egl.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/#review51909 --- Ship it! Ship It! - Lamarque Souza On March 4, 2014, 4:13 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated March 4, 2014, 4:13 p.m.) Review request for KDE Frameworks, Daniel Nicoletti, Lamarque Souza, and Sebastian Kügler. Repository: libnm-qt Description --- Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs This means there is no longer a need for passing -DLIB_SUFFIX=64 on e.g. openSuSE, since CMake will detect the correct install directory for most distributions. If for some reason CMake doesn't detect the correct directory it can be overriden using e.g. -DCMAKE_INSTALL_LIBDIR=lib32 Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 include/CMakeLists.txt 2b51ced include/settings/CMakeLists.txt 1a00bdb Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116598: Check versions for individual components of Wayland
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116598/#review51912
---
Ship it!
Looks good to me.
- Aleix Pol Gonzalez
On March 4, 2014, 3:53 p.m., Aurélien Gâteau wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116598/
---
(Updated March 4, 2014, 3:53 p.m.)
Review request for Build System, Extra Cmake Modules, KDE Frameworks, and
Martin Gräßlin.
Repository: extra-cmake-modules
Description
---
First part of the diff makes sure find_package_handle_standard_args() gets a
version number to check against.
Second part ensures we get proper results from pkg-config even if not all
components are available. find_package(Wayland COMPONENTS Client Egl) was
failing for me because I have Client installed but not Egl, causing
pkg_check_modules() to not set any PKG_Wayland_${comp} variable.
Diffs
-
find-modules/FindWayland.cmake 21014fc
Diff: https://git.reviewboard.kde.org/r/116598/diff/
Testing
---
Together with a change for kde-workspace, it fixes the build of kde-workspace
on my system with wayland-client 1.1 and no wayland-egl.
Thanks,
Aurélien Gâteau
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KIdleTime Quick Review
Hi, Nice simple one this, one public class, looks OK. Has QWidget, Windows, Mac, and X11 (XScreensaver/XSync) backends, will need Wayland or systemd support eventually? Does have one TODO, but that's an implementation detail: widgetbasedpoller.cpp # TODO: make optional, to avoid always depending on QtWidgets? Or port to QtGui? One small point, the idle time is an int value, perhaps a uint would be better? Also uses an int for a unique timeout identifier, perhaps a QUuid might be better? If you're looking for a maintainer, Dario Freddi wrote all the code... Just sayin ;-) John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115982: Add a tool that creates a Mac OS X icns (icon) file from a svg file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115982/ --- (Updated March 4, 2014, 6:42 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This is a small tool that generates Mac OS X icon files from (oxygen) svg[z] files. Diffs - src/tools/ksvg2icns/ksvg2icns.cpp PRE-CREATION src/tools/ksvg2icns/CMakeLists.txt PRE-CREATION src/CMakeLists.txt 76932ca87c7de2dc25398e1fca8916426ce7e566 Diff: https://git.reviewboard.kde.org/r/115982/diff/ Testing --- Builds on Mac OS X Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KGuiAddons Review
Hi, Here's my first pass through KGuiAddons, focussing on the public api. KColorCollection - Should probably become a QSharedDataPointer KWorkdWrap - // KDE5 TODO: return a value, not a pointer, and use QSharedDataPointer. KModifierKeyInfo - Generally looks OK - Has lots of bool isKeyPressed(Qt::Key) style methods and keyPressed(Qt::Key, bool) style signals when perhaps a KeyState enum would be better? - Uses X11 / XKB / XCB, will need Wayland backend eventually? - Perhaps really belongs in Qt, or somewhere else? KImageCache KSharedPixmapCacheMixin KLocalImageCacheImplementation - Looks OK - KImageCache not exported, but KLocalImageCacheImplementation is, some CMake magic involved? KColorMimeData KFontUtils KIconUtils - Looks OK KColorUtils - Looks OK - Qt should probably get some of these methods? KDateValidator - Looks OK - Qt should probably have one, QTime as well? And the usual documentation improvements of course. Otherwise looks in good shape. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
El Dimarts, 4 de març de 2014, a les 21:34:12, Ben Cooksley va escriure: On Tue, Mar 4, 2014 at 9:30 PM, David Faure fa...@kde.org wrote: On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? Jenkins has an Web API which can be used, as well as a Java client to help interact with it. In terms of modifying the configuration files on disk - they're XML based data, and i'm not sure if we can get Jenkins to reparse them short of restarting it completely. You can just update the xml via the Java api with http://build.kde.org/cli/command/get-job and http://build.kde.org/cli/command/update-job Cheers, Albert -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/#review51923 --- Ship it! Ship It! - Burkhard Lück On Feb. 27, 2014, 10:43 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116068: Bump supported DocBookXML version to 4.5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116068/#review51924 --- Ship it! Ship It! - Burkhard Lück On Feb. 27, 2014, 10:40 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116068/ --- (Updated Feb. 27, 2014, 10:40 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- - rename the DTD file (the old one will be kept for for compatibility in kde4support) - adapt the existing documentation: - please note that these changes (usage of the new DTD) should be applied to all the documentation shipped with other Frameworks and with the documentation of modules that do not require KDE4Support (see next RR).-- The change should be mostly a matter of replacing the DTD, as DocBookXML 4.5 is backward compatible with 4.2 according the specifications. This RR comprises the steps 3a) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - src/CMakeLists.txt 0329bd3 docs/meinproc5/man-meinproc5.8.docbook 77799b4 docs/qt5options/man-qt5options.7.docbook 7afbf07 docs/kf5options/man-kf5options.7.docbook cb7973d cmake/FindDocBookXML4.cmake eb4bfd8 docs/checkXML5/man-checkXML5.1.docbook 68509b9 src/customization/catalog.xml 229ae70 src/customization/dtd/kdedbx45.dtd.cmake PRE-CREATION src/customization/dtd/kdex.dtd.cmake c2f7b2c src/man-template.docbook bdc88c7 src/template.docbook 08762e5 Diff: https://git.reviewboard.kde.org/r/116068/diff/ Testing --- Compilation (including the other RR) Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116542: Fix compilation with clang 3.4.
On March 4, 2014, 6:03 a.m., Michael Pyne wrote:
From what I can tell declaring *any* type A::B is a qualified id per the
C++ spec and therefore changes the template lookup rules for
argument-dependent lookup (which means the specialized function to be
called must already be in scope with matching argument types). However I
think clang might actually be wrong here as the lookup is happening at the
template instantiation (i.e. the QCOMPARE of two UDSEntryLists, which are
properly declared in kio as using an unqualified id). But then again I
think ADL works based on which names are available in the dependent
namespace (in this case KIO) at the time of the lookup, and operator==() is
not part of KIO namespace until your patch, and so might not get included
as an option during ADL (and the compiler has no other official way to tie
UDSEntry back to KIO::UDSEntry).
Well, there might be one: Does adding a using KIO::UDSEntry at the top of
the file work instead? It doesn't actually matter, all the solutions are
probably equally a hack...
so can I merge this then?
- Milian
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/#review51851
---
On March 2, 2014, 8:20 p.m., Milian Wolff wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/
---
(Updated March 2, 2014, 8:20 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
Fix compilation with clang 3.4.
Note that I'm not too sure why this compiled with GCC
and why clang rejects the global operator== definition and
wants to have it in the KIO namespace. Someone with more C++
ADL knowledge should chime in whether this is the right fix.
In file included from kio/tests/udsentrybenchmark.cpp:22:
In file included from /usr/include/qt/QtTest/QTest:1:
/usr/include/qt/QtTest/qtest.h:203:24:
error: call to function 'operator==' that is neither visible
in the template definition nor found by argument-dependent lookup
if (!(t1.at(i) == t2.at(i))) {
^
kio/tests/udsentrybenchmark.cpp:286:22: note: in instantiation of
function template specialization 'QTest::qCompareKIO::UDSEntry'
requested here
do { if (!QTest::qCompare(entries, m_smallEntries, entries,
m_smallEntries, kio/tests/udsentrybenchmark.cpp, 286)) return;}
while (0);
kio/tests/udsentrybenchmark.cpp:246:6: note: 'operator==' should be
declared prior to the call site or in namespace 'KIO'
bool operator==(const KIO::UDSEntry a, const KIO::UDSEntry b)
^
1 error generated.
udsentrybenchmark.dir/build.make:54: recipe for target
'tests/CMakeFiles/udsentrybenchmark.dir/udsentrybenchmark.cpp.o'
failed
Diffs
-
tests/udsentrybenchmark.cpp 75fc758e583f7586c7b9a576d984b40912fa3ace
Diff: https://git.reviewboard.kde.org/r/116542/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: KIdleTime Quick Review
On Tuesday 04 March 2014 19:35:10 John Layt wrote: Hi, Nice simple one this, one public class, looks OK. Has QWidget, Windows, Mac, and X11 (XScreensaver/XSync) backends, will need Wayland or systemd support eventually? Does have one TODO, but that's an implementation detail: widgetbasedpoller.cpp # TODO: make optional, to avoid always depending on QtWidgets? Or port to QtGui? One small point, the idle time is an int value, perhaps a uint would be better? Also uses an int for a unique timeout identifier, perhaps a QUuid might be better? If you're looking for a maintainer, Dario Freddi wrote all the code... Just sayin ;-) Yes, but he's pretty much inactive these days unfortunately... Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115478: Add QFileDialog unit autotest for filters (which reveals a QPA bug)
On Feb. 4, 2014, 5:17 p.m., Alex Merry wrote:
Has the Qt patch been submitted upstream?
Dominik Haumann wrote:
Meanwhile yes: https://codereview.qt-project.org/#change,77390
Alex Merry wrote:
I don't think it's useful to have tests that fail because of upstream
issues in the repo, at least not in such a way that it causes the testsuite
as a whole to report a failure.
My suggestion is to mark (1) as an expected failure
(http://qt-project.org/doc/qt-5/qtest.html#QEXPECT_FAIL), and mark (2) as an
expected failure only if the Qt version is too old. With comments about why
the failures are expected, of course.
Dominik Haumann wrote:
I've pushed these changes to the Qt stable branch:
https://codereview.qt-project.org/#change,77390
So if build.kde.org uses a recent enough Qt version, I'd expect this test
to pass. What Qt version does build.kde.org use right now?
Alex Merry wrote:
It's not just build.kde.org, it's also users (or, more likely, packagers
and developers). If you know what point-release will get this fix, then just
test for that.
Ben Cooksley wrote:
The CI system rebuilds Qt once a week.
The latest build log is visible at
http://build.kde.org/job/qt5_master_qt5/119/consoleText - it built revision
805c735 of the qt5.git supermodule.
I agree with Alex, please adjust the test to use QEXPECT_FAIL.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115478/#review48954
---
On Feb. 4, 2014, 5:07 p.m., Dominik Haumann wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115478/
---
(Updated Feb. 4, 2014, 5:07 p.m.)
Review request for KDE Frameworks, Àlex Fiestas and Gregor Mi.
Repository: frameworkintegration
Description
---
The following QPA integration does not work as expected:
QStringList nameFilterList = QStringList() c (*.cpp) h (*.h);
dialog.setNameFilters(nameFilterList);
QString selectNameFilter(h (*.h));
dialog.selectNameFilter(selectNameFilter);
// QCOMPARE(dialog.selectedNameFilter(), selectNameFilter); // (1) always
fails, no matter what
dialog.show();
QCOMPARE(dialog.selectedNameFilter(), selectNameFilter); // (2) currently
also fails, Qt patch required
The problem is described in detail in:
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/010691.html
The Qt patches that make (2) work are as follows:
diff --git a/src/widgets/dialogs/qfiledialog.cpp
b/src/widgets/dialogs/qfiledialog.cpp
index da026d2..72b2310 100644
--- a/src/widgets/dialogs/qfiledialog.cpp
+++ b/src/widgets/dialogs/qfiledialog.cpp
@@ -627,7 +627,8 @@ void
QFileDialogPrivate::helperPrepareShow(QPlatformDialogHelper *)
options-setInitialDirectory(directory.exists() ?
QUrl::fromLocalFile(directory.absolutePath()) :
QUrl());
-options-setInitiallySelectedNameFilter(q-selectedNameFilter());
+if (options-initiallySelectedNameFilter().isEmpty())
+options-setInitiallySelectedNameFilter(q-selectedNameFilter());
if (options-initiallySelectedFiles().isEmpty())
options-setInitiallySelectedFiles(userSelectedFiles());
}
@@ -1447,6 +1448,7 @@ void QFileDialog::selectNameFilter(const QString
filter)
{
Q_D(QFileDialog);
if (!d-usingWidgets()) {
+d-options-setInitiallySelectedNameFilter(filter);
d-selectNameFilter_sys(filter);
return;
}
However, the QCOMPARE in (1) is still an open issue. And no fix in sight...
Ok to commit this to frameworksintegration (and therewith make it unstable?)
Diffs
-
autotests/kfiledialog_unittest.cpp PRE-CREATION
autotests/CMakeLists.txt fb58b3a
Diff: https://git.reviewboard.kde.org/r/115478/diff/
Testing
---
The attached unit test currently fails due to a bug in the Qt QPA.
With the Qt patch above, (2) in the unit test passes, so one is able to call
QFileDialog::selectNameFilter().
However, (1) remains broken.
Thanks,
Dominik Haumann
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115137: Provide information about the active screen in KWindowSystem
On Feb. 20, 2014, 12:07 p.m., Kevin Ottens wrote: Aren't the concern raised initially on that patch addressed now? Please make a second round of reviews or ship it. More than a week with no reaction, should it be discarded? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review50339 --- On Jan. 31, 2014, 1:01 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 31, 2014, 1:01 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where to position e.g. a notification window. It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and announced in the supported properties. Diffs - tests/activeoutputtest.cpp PRE-CREATION tests/CMakeLists.txt ce68cc505a69ea9a3cf645e9ae587bd89abe1648 src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d src/netwm.cpp 84eb137492e0afaaac80e8d26561fd8f8aff9c27 src/netwm.h 393a29de3153a8b291b9fb249bd3eaeb1ba4e7d5 src/kwindowsystem_x11.cpp 01c78c1debf95d5a176e2153139da19abf383c41 src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 src/kwindowsystem.h 3de0fea179dd468a78a265808fc64704027ec30d src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c Diff: https://git.reviewboard.kde.org/r/115137/diff/ Testing --- * wm part of NETWM is unit tested * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment of this writing: none) * Windows and Mac is not even compile tested, that's why kdewin is included in the review. If you have the time for it, please do a compile test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115752: Change DATA_INSTALL_DIR on Mac OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115752/ --- (Updated March 4, 2014, 8:09 p.m.) Status -- This change has been discarded. Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Let it point to ~/Library/Application Support as that is what QStandardPaths expects This is actually a tricky one - I'd rather have $HOMEBREW_PREFIX/share as data path, but Qt only reports ~/Library/Application\ Support So - do we add some magic to Qt to allow user-configurable extra data dirs (juck), implement our own magic (juck), or just change the DATA_INSTALL_DIR to ~/Library/Application\ Support? Diffs - kde-modules/KDEInstallDirs.cmake 9ff23540f00a2794b1ebd842656c3d61b047a500 Diff: https://git.reviewboard.kde.org/r/115752/diff/ Testing --- Tested with homebrew tap at https://github.com/haraldF/homebrew-kf5 Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115916: Fix MSVC build of kprintpreview_test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115916/#review51930 --- Ship it! Ship It! - Kevin Ottens On Feb. 20, 2014, 4:41 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115916/ --- (Updated Feb. 20, 2014, 4:41 p.m.) Review request for KDE Frameworks. Repository: kprintutils Description --- Fix MSVC build of kprintpreview_test I am not sure whether this is the best solution, but I don't want to make the Linux code less efficient. However it is a test application so it probably doesn't matter... Diffs - tests/kprintpreview_test.cpp 79cac037ab38bce89b97e4ede58eb58d821b25f3 Diff: https://git.reviewboard.kde.org/r/115916/diff/ Testing --- Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115717: Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set
On Feb. 19, 2014, 2:07 p.m., Alex Merry wrote: I don't think papering over the X11-ness of kdesu like this is the right approach. Of course, what this framework really needs is a test app; maybe a simple port of the kdesu app from kde-runtime? Kevin Ottens wrote: This kind of papering over can only be temporary indeed. Just wondering if Martin has the possibility to clean that up better at that stage? As for the test app: hell yes, definitely needed. Martin Gräßlin wrote: well yes if there's a testapp and that works I can implement it properly. But IIRC kdesu never worked on my setup (not having a password for root). You can use it for other users than root you know. ;-) - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/#review50240 --- On Feb. 13, 2014, 9:41 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115717/ --- (Updated Feb. 13, 2014, 9:41 a.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Do not require to have a DISPLAY env variable if WAYLAND_DISPLAY is set If kdesu is compiled with X11 it required the DISPLAY variable to be set. This is no longer correct as it might have been compiled with X11 but is run on Wayland. Thus the code checks now also for WAYLAND_DISPLAY in the HAVE_X11 ifdef blocks. The Wayland support should become more complete, I do not know how it behaves if we compile without X11 support. Unfortunately there are no autotests and no test applications which one could use. Diffs - src/client.cpp 91bfd78fbca6e5d8d365d924c0260087e3937948 src/kcookie.cpp 59448351696c503b34b7507e9c3fa8efc53139f9 Diff: https://git.reviewboard.kde.org/r/115717/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115602: Rename kactivitymanagerd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115602/ --- (Updated March 4, 2014, 8:15 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Ivan Čukić. Repository: kactivities Description --- ...so it can co-exists with kactivities4 in the same prefix Diffs - autotests/Process.cpp a7a0507 src/lib/core/manager_p.cpp 57f60be src/service/CMakeLists.txt 141e9b7 src/service/files/kactivitymanagerd.desktop ce68a49 Diff: https://git.reviewboard.kde.org/r/115602/diff/ Testing --- Both Plasma1 and Next ran fine with this patch and withouth kactivitymanagerd(4) installed. Haven't tested the case when they are both installed. Thanks, Hrvoje Senjan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115907: Link tests with extra libraries as well
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115907/ --- (Updated March 4, 2014, 8:17 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kxmlgui Description --- Uses the optional extra libraries in the tests as well. Diffs - CMakeLists.txt 4db9ac5 autotests/CMakeLists.txt 01725da src/CMakeLists.txt a0dd642 tests/CMakeLists.txt 413fa92 tests/krichtexteditor/CMakeLists.txt 45c1abe Diff: https://git.reviewboard.kde.org/r/115907/diff/ Testing --- Tests build with and without KF5Attica. Thanks, Adrián Chaves Fernández ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
On Feb. 22, 2014, 9:09 a.m., David Faure wrote: src/lib/kaboutdata.cpp, line 919 https://git.reviewboard.kde.org/r/115207/diff/3/?file=245365#file245365line919 A unittest would have shown you the bug in this line... (you're modifying a copy - no effect). Use setProperty, just like the existing line for applicationIconName does. And then I would remove the inherits() call. It will become a dynamic property if the app isn't a QGuiApplication, no big deal. Please address David's comments it's been more than a week. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review50501 --- On Feb. 21, 2014, 2:03 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Feb. 21, 2014, 2:03 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115395: Also pass -fno-exceptions when building with clang
On Feb. 3, 2014, 6:07 p.m., Raphael Kubo da Costa wrote:
Please see the big comment below the elseif line, the link to the
kde-core-devel and
http://lists.kde.org/?l=kde-core-develm=138244424421211w=2: the issue
here is that if you pass -fno-exceptions to clang you need to guarantee it
is not going to include any headers that throw exceptions either, even if
it is in some template code that never gets instantiated.
For example, this does not build with clang++ -fno-exceptions, but does
with GCC 4.8:
#include exception
template typename T
struct S { void f() { throw std::exception(); } };
This was a problem for kdelibs including OpenEXR headers, or kdepim
including pimlibs headers that all fell into this case.
Alex Merry wrote:
Arguably, the solution here is to always enable exceptions for code that
encounters this (as we do for the OpenEXR QImage format plugin, for example).
Alexander Richardson wrote:
It works with all the STL headers, the question is should we have
everything built with clang be 7% bigger, or just enable exceptions in those
cases where it breaks compilation? I don't really mind either way, I just
realized that all of frameworks builds fine even with -fno-exceptions.
Raphael Kubo da Costa wrote:
The situation might be easier with frameworks and we can choose to
selectively enable exceptions where necessary; I only worry about ending up
having to play catch up with libraries that suddenly end up including headers
that throw exceptions via a dependency of a dependency, or issues going
undetected due to everyone using GCC.
Alex Merry wrote:
The choice, I guess, is between making life easy for Clang users by
avoiding errors that don't crop up with GCC, and making use of Clang's better
diagnostics to catch these sorts of problems. I'm not sure which we should
be going for.
Kevin Ottens wrote:
I'd lean toward making use of clang's better diagnostics to be honest.
Means we need a clang build of frameworks too on the CI though.
Alexander Richardson wrote:
Ok good, I will update this review to address the raised issues.
Any news?
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115395/#review48846
---
On Jan. 29, 2014, 11:18 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115395/
---
(Updated Jan. 29, 2014, 11:18 p.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
Also pass -fno-exceptions when building with clang
All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions
The only problem related to clang and -fno-exceptions I could find was
http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since
clang version 3.0 which was released in December 2011
Diffs
-
kde-modules/KDECompilerSettings.cmake
335e1270d19f8342e41b22e7081dea3f7ac0fbfc
Diff: https://git.reviewboard.kde.org/r/115395/diff/
Testing
---
compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3
Would be good if someone with an older clang version could test it and see
whether it works.
May also be related to the libstdc++ headers (4.8 installed here).
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115977: RFC: Install KArchive as Mac OS X Framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115977/#review51936 --- src/karchive.h https://git.reviewboard.kde.org/r/115977/#comment36925 Hm, why the change to for the includes? We try to stick to in public headers. - Kevin Ottens On Feb. 23, 2014, 7:15 p.m., Harald Fernengel wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115977/ --- (Updated Feb. 23, 2014, 7:15 p.m.) Review request for KDE Frameworks. Repository: karchive Description --- Change CMakeLists.txt to create Mac OS X frameworks Diffs - CMakeLists.txt f5dc644fdba13e29c94940c77d628e92e0759787 src/CMakeLists.txt 53e97284cab199f5eb75aa276adfadc18d677682 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchivedirectory.h 60225d0be9fc2e28ff2b998dcc8fb28512c6e3cd src/karchiveentry.h aad6840ee0dc22e5760ddda99ce975a1d9a9dc92 src/karchivefile.h c7d2e0e0735f75a8e490082aa8598fd08206a998 src/ktar.h 4bca89884e646ffae90aa1a9e15a985e998e843f Diff: https://git.reviewboard.kde.org/r/115977/diff/ Testing --- 'make install' on Mac OS X Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115316: Add demo for KRecentFileList
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115316/#review51937 --- Ship it! Ship It! - Kevin Ottens On Feb. 24, 2014, 10:05 p.m., Gregor Mi wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115316/ --- (Updated Feb. 24, 2014, 10:05 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- This is a demo test for KRecentFileList (in combination with KSharedConfig). The patch also contains a documentation update for krecentfilesaction.h/loadEntries() saying that Local file entries that do not exist anymore are not restored.. As a side note: Does it makes sense to optionally disable the automated removal of non-existing recent files? Or have the possibility to return the files that were automatically removed? Diffs - src/krecentfilesaction.h 38d1b5e3455d081304b064d13bccfc2164d12a14 tests/CMakeLists.txt 617a55944b2c91c9b09125ad92d070d3cd9a6551 tests/krecentfilesactiontest.h PRE-CREATION tests/krecentfilesactiontest.cpp PRE-CREATION tests/krecentfilesactiontest.ui PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115316/diff/ Testing --- Thanks, Gregor Mi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116044: In kstyle: Use the iconSize from mainToolbar
On Feb. 25, 2014, 12:10 p.m., David Faure wrote: The part of the description that says if accepted will modify kstyle as well doesn't really make sense anymore (to fix if it's in your commit log too). The bit I'm not sure about is: using MainToolbar icon style everywhere ... how does that take care of other toolbars then? The idea (long ago) was to be able to have (large) icons and text in the main toolbar, and (small) icons only in other toolbars. Is that idea dropped, or handled elsewhere? Hugo Pereira Da Costa wrote: The bit I'm not sure about is: using MainToolbar icon style everywhere ... how does that take care of other toolbars then? Thing is, old code was treating 'main ToolBar' as 'other toolbars'. New one (iiur) treats 'other toolbars' as 'main toolbar'. The latter is as 'incomplete' as the former, but more consistent. Not sure where exactly the distinction between 'main' and 'all' toolbars is performed. Alex ? Is it kapplication ? (as opposed to Qt only, which has no such distinction) ? David Faure wrote: I know consistency is better than inconsistency, but still, while looking at this we might as well make it correct, too :) The logic used to be in KToolBar, based on objectName == mainToolBar (yes, you could say that's ugly and fragile, but since that comes from the kxmlgui ui_standards.rc file, it actually happens automatically in all apps). I'm not sure what's the plan for making this work in the QToolBar+KF5 world. But if nothing else has been planned already, kstyle and/or platformtheme [I'm not sure why they both handle toolbar icon sizes] can take care of checking the objectName too, given a pointer to the toolbar. The style is indeed able to have that pointer to the toolbar, so it could be a simple if there. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116044/#review50807 --- On Feb. 25, 2014, 12:34 p.m., Hugo Pereira Da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116044/ --- (Updated Feb. 25, 2014, 12:34 p.m.) Review request for KDE Frameworks and Àlex Fiestas. Repository: frameworkintegration Description --- This is a spinoff of https://git.reviewboard.kde.org/r/112335/ originally from afiestas Copying his own words: In the qplatformplugin we use information from MainToolbar (which makes sense) but in the styles we use information from Toolbar. This unify both by using MainToolbar in styles Code has been removed from oxygen now that it derives from KStyle again Diffs - src/kstyle/kstyle.cpp c0528b3 Diff: https://git.reviewboard.kde.org/r/116044/diff/ Testing --- Thanks, Hugo Pereira Da Costa ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116025: Add documentation about writing find modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116025/#review51940 --- Anything blocking you from addressing the last two issues? - Kevin Ottens On Feb. 25, 2014, 8:11 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116025/ --- (Updated Feb. 25, 2014, 8:11 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Add documentation about writing find modules Diffs - README.md 85b97b7fa003282e1eeb1113c4668a9b73e3f731 docs/writing-find-modules.md PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116025/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116096: Re-enable autotests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116096/#review51943 --- autotests/proxymodeltestsuite/CMakeLists.txt https://git.reviewboard.kde.org/r/116096/#comment36928 Hm, why removing this block while using if(FALSE) on the one above? I'd expect either both to disappear or both to use if(FALSE). - Kevin Ottens On Feb. 26, 2014, 5:49 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116096/ --- (Updated Feb. 26, 2014, 5:49 p.m.) Review request for KDE Frameworks. Repository: kitemmodels Description --- Re-enable autotests modeltest.(cpp|h) are taken from Qt 5.3. The license header has been trimmed to clarify which license we are using it under, and to reflect the fact we use a COPYING.LIB file instead of LICENSE.LGPL. Grantlee is disabled. That apparently affects some sort of logging functionality, but I haven't really investigated it. Diffs - autotests/klinkitemselectionmodeltest.cpp e1a47e4cf58e85d690c58fb1b40bfdd8cfb81431 autotests/kselectionproxymodeltestsuite.h 6204b7733f995614c43930af03d12d13e0cb2a3f autotests/proxymodeltestsuite/CMakeLists.txt 972226b7dd3477b7d064ececb307609e67d81670 autotests/proxymodeltestsuite/eventloggerregister.cpp 6be780108c71db6c32cfbb2c88524366435ea301 autotests/proxymodeltestsuite/modelselector.h c1163084170d4409112949057562abbfa909dc14 autotests/proxymodeltestsuite/modeltest.h 20d5c36e32e69bb69fffad86ccc02e44bfade425 autotests/proxymodeltestsuite/modeltest.cpp 51ad27f3fef5cf0d62e92eb149e4cf9149b45e95 CMakeLists.txt d153ba3d658ba70a0dca2b9e04b6cdd1e17d9db3 autotests/bihash/CMakeLists.txt 44c965c7597ac48c81bba70f07979b51bf8547aa Diff: https://git.reviewboard.kde.org/r/116096/diff/ Testing --- Tests build. 3 out of 4 pass. 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 115932: Add declarative plugin for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated March 4, 2014, 8:41 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116088: Remove FindDBusMenuQt5.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116088/#review51945 --- Ship it! Ship It! - Kevin Ottens On Feb. 27, 2014, 12:19 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116088/ --- (Updated Feb. 27, 2014, 12:19 p.m.) Review request for KDE Frameworks. Repository: knotifications Description --- Remove FindDBusMenuQt5.cmake dbusmenu-qt ships a CMake config file so we don't need a Find* file anymore. Unfortunately the target defined does not set the include dir so for the time being it is still necessary to call include_directories() (might look into this if I find time) Diffs - CMakeLists.txt ef84eb6 cmake/FindDBusMenuQt5.cmake 7d43489 src/CMakeLists.txt 900cb38 Diff: https://git.reviewboard.kde.org/r/116088/diff/ Testing --- Builds, manual tests run as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115918: Fix kservice_desktop_to_json for Visual Studio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/ --- (Updated March 4, 2014, 8:45 p.m.) Review request for KDE Frameworks and Stephen Kelly. Repository: kservice Description --- Fix kservice_desktop_to_json for Visual Studio The CMake generator for Visual Studio cannot handle the new build-time kservice_desktop_to_json macro - fall back to configure-time generation Diffs - KF5ServiceMacros.cmake f70a185f4cd48293cb9f1e2ca4cf13defaf2aec3 Diff: https://git.reviewboard.kde.org/r/115918/diff/ Testing --- ktexteditor fails to build before this patch (because moc can't find the .json file), with the patch it compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115918: Fix kservice_desktop_to_json for Visual Studio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/#review51946 --- Ship it! And I agree with Aurélien, a bug should be filed and Stephen involved in that issue. - Kevin Ottens On March 4, 2014, 8:45 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/ --- (Updated March 4, 2014, 8:45 p.m.) Review request for KDE Frameworks and Stephen Kelly. Repository: kservice Description --- Fix kservice_desktop_to_json for Visual Studio The CMake generator for Visual Studio cannot handle the new build-time kservice_desktop_to_json macro - fall back to configure-time generation Diffs - KF5ServiceMacros.cmake f70a185f4cd48293cb9f1e2ca4cf13defaf2aec3 Diff: https://git.reviewboard.kde.org/r/115918/diff/ Testing --- ktexteditor fails to build before this patch (because moc can't find the .json file), with the patch it compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review51947 --- Ship it! Ship It! - Kevin Ottens On Feb. 25, 2014, 10:50 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 25, 2014, 10:50 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - autotests/kcombobox_unittest.cpp 49ef721 src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116538: Make README.md consistent with other frameworks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116538/#review51950 --- Ship it! Ship It! - Kevin Ottens On March 2, 2014, 8:05 p.m., Cornelius Schumacher wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116538/ --- (Updated March 2, 2014, 8:05 p.m.) Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Repository: sonnet Description --- Adapt formatting and content of links to make the README.md consistent with all the other frameworks. Diffs - README.md b211ae21d8f4414c025ac628dcbee009b05c9e36 Diff: https://git.reviewboard.kde.org/r/116538/diff/ Testing --- Thanks, Cornelius Schumacher ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116545: Fix KHTML compilation when using clang.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116545/#review51953
---
Ship it!
Ship It!
- Kevin Ottens
On March 2, 2014, 9:11 p.m., Milian Wolff wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116545/
---
(Updated March 2, 2014, 9:11 p.m.)
Review request for KDE Frameworks and David Faure.
Repository: kjs
Description
---
Fix KHTML compilation when using clang.
In file included from src/ecma/kjs_traversal.cpp:21:
src/kjs_traversal.lut.h:49:18: error: constant expression
evaluates to 4294967295 which cannot be narrowed to type 'int'
[-Wc++11-narrowing]
{ SHOW_ALL, DOM::NodeFilter::SHOW_ALL,
KJS::DontDelete|KJS::ReadOnly, 0, 0 } ,
src/kjs_traversal.lut.h:49:18: note: override this message by
inserting an explicit cast
{ SHOW_ALL, DOM::NodeFilter::SHOW_ALL,
^
static_castint()
Diffs
-
src/kjs/create_hash_table 94f3e4358a6d78fc7c658369d65b0e75ca131bc8
Diff: https://git.reviewboard.kde.org/r/116545/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 116561: Drop KWindowEffects::showWindowThumbnails
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116561/#review51957 --- Ship it! Ship It! - Kevin Ottens On March 3, 2014, 8:48 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116561/ --- (Updated March 3, 2014, 8:48 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Drop KWindowEffects::showWindowThumbnails The effect got removed from KWin, thus it doesn't make any sense to expose the functionality in KWindowEffects. As KWindowEffects is new in 5.0 it's removed and not deprecated. It used to be in Plasma::WindowEffects before. Diffs - src/kwindoweffects_dummy.cpp c4e67e816157695bb49812e04f271ef1a0ea817c src/kwindoweffects.cpp 471e15d06fc2cd81a3a3f7c555d9140cab4536a1 src/kwindoweffects.h e0c2b25026227065b885f3794dbcf4b8924441a7 autotests/kwindoweffectstest.cpp 7a00ebc8e0e34f7244bf1e673645384e8c961459 src/kwindoweffects_p.h fd26b03b9a627acdb6c9598c6df26b4f1d044930 src/kwindoweffects_x11.cpp 8b1e1d186231be8118190cb04651ba3507f47da2 Diff: https://git.reviewboard.kde.org/r/116561/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116567: Implement fuzzy image matching in readtest
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116567/#review51959 --- Ship it! Ship It! - Kevin Ottens On March 3, 2014, 3:23 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116567/ --- (Updated March 3, 2014, 3:23 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- Implement fuzzy image matching in readtest Images are converted to ARGB32 format, then each byte (ie: each pixel channel) in the read image is allowed to deviate by some specified amount from the corresponding byte in the expected image, to allow for rounding errors etc. By default, no deviation is permitted, but the XCF tests are allowed a deviation of 1, as the alpha blending can result in rounding errors (depending on whether hardware acceleration is used, for example). In the end, we are not too concerned about a small deviation that is invisible to the human eye. Extract QImage::Format parsing into its own header Use the array-of-strings suggested by David Faure so that only one list has to be maintained instead of three. Diffs - autotests/CMakeLists.txt 5c6508490344ca29097a3f13d01571658ad34786 autotests/readtest.cpp dec9686e38389b04296fdf176db9fb8c1f3a56a4 tests/format-enum.h PRE-CREATION tests/imagedump.cpp 4b38c07d151d9bcb895f49a76e2bd03ddee41487 Diff: https://git.reviewboard.kde.org/r/116567/diff/ Testing --- imagedump still works. Most tests still pass; note that the non-alpha pic tests fail without https://git.reviewboard.kde.org/r/116568/diff/ as the wrong format (ARGB32 instead of RGB32) is constructed. This should make the xcf tests pass again on Jenkins. 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 116588: Improve the README
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/#review51960 --- Ship it! Ship It! - Kevin Ottens On March 4, 2014, 12:32 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116588/ --- (Updated March 4, 2014, 12:32 p.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Improve the README Diffs - README.md 2685b2e441ee2745c50712aac712be1081fec60d Diff: https://git.reviewboard.kde.org/r/116588/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115875: kconfigtest: write everything into a subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/#review51961 --- Ship it! autotests/kconfigtest.cpp https://git.reviewboard.kde.org/r/115875/#comment36932 Just curious, what's the reason for the .. then? Doesn't this still make this test potentially conflict with other tests that use kdeglobals? - David Faure On March 4, 2014, 8:58 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/ --- (Updated March 4, 2014, 8:58 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- kconfigtest: write everything into a subdirectory This test keeps deleting the whole ~/.qttest directory. By moving all data into a subdirectory it is now possible to run multiple tests that use kconfig in parallel. Diffs - autotests/kconfigtest.cpp 1c0dc1cf63539e29236ab57e1e848930b468053a Diff: https://git.reviewboard.kde.org/r/115875/diff/ Testing --- Test still passes. No files (except kdeglobals) are created in ~/.qttest/config Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/#review51963 --- Ship it! Ship It! - Kevin Ottens On Feb. 27, 2014, 10:43 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116542: Fix compilation with clang 3.4.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/#review51966
---
Ship it!
Ship It!
- Kevin Ottens
On March 2, 2014, 8:20 p.m., Milian Wolff wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/
---
(Updated March 2, 2014, 8:20 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
Fix compilation with clang 3.4.
Note that I'm not too sure why this compiled with GCC
and why clang rejects the global operator== definition and
wants to have it in the KIO namespace. Someone with more C++
ADL knowledge should chime in whether this is the right fix.
In file included from kio/tests/udsentrybenchmark.cpp:22:
In file included from /usr/include/qt/QtTest/QTest:1:
/usr/include/qt/QtTest/qtest.h:203:24:
error: call to function 'operator==' that is neither visible
in the template definition nor found by argument-dependent lookup
if (!(t1.at(i) == t2.at(i))) {
^
kio/tests/udsentrybenchmark.cpp:286:22: note: in instantiation of
function template specialization 'QTest::qCompareKIO::UDSEntry'
requested here
do { if (!QTest::qCompare(entries, m_smallEntries, entries,
m_smallEntries, kio/tests/udsentrybenchmark.cpp, 286)) return;}
while (0);
kio/tests/udsentrybenchmark.cpp:246:6: note: 'operator==' should be
declared prior to the call site or in namespace 'KIO'
bool operator==(const KIO::UDSEntry a, const KIO::UDSEntry b)
^
1 error generated.
udsentrybenchmark.dir/build.make:54: recipe for target
'tests/CMakeFiles/udsentrybenchmark.dir/udsentrybenchmark.cpp.o'
failed
Diffs
-
tests/udsentrybenchmark.cpp 75fc758e583f7586c7b9a576d984b40912fa3ace
Diff: https://git.reviewboard.kde.org/r/116542/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 115137: Provide information about the active screen in KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/#review51954 --- src/kwindowsystem_x11.cpp https://git.reviewboard.kde.org/r/115137/#comment36936 Brainstorm. Assuming this is of rare interest and we would want to limit X11 roundtrips and pointer tracking. The WM could then simply set the strategy (mouse/active window) and ::activeOutput() could check that to calculate the reult on request. KWindowSystem could (on connect notify) track the mouse/active window to emit the signal. This way tracking would only be required if/while some client is really interested. Downside is that 2 or more clients could be tracking simultanously. Benefit would be that other WMs can adapt this very easily and we don't rely on XI2 support (what will probably also not work if the mouse is navigated by the keyboard?) src/netwm.cpp https://git.reviewboard.kde.org/r/115137/#comment36930 The API says the parameter can be NULL, nstrdup will then return a casted nullptr and this will segfault. (Or I missed something?) - Thomas Lübking On Jan. 31, 2014, 1:01 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115137/ --- (Updated Jan. 31, 2014, 1:01 p.m.) Review request for KDE Frameworks, kdewin and kwin. Repository: kwindowsystem Description --- The rational for these changes is based on the discussion in http://article.gmane.org/gmane.comp.kde.devel.plasma/27579/ Plasma needs to know which is the active screen and so far only KWin knows it, so we need to make everybody aware of it. --- Add convenient wrapper for active screen to KWindowSystem A method is added to get the identifier of the active screen as a QString and a signal whenever the active screen changes. This method is only provided for X11, on Windows and Mac a null QString is returned as the identifier. Add an active screen property to NETRootInfo The active screen is intended to be set by KWin to the active screen it's using. This can be used by a Client to manually position e.g. override redirect windows on the active screen. It's intended as a help for multi-screen setups where a Client can only do guesses on where to position e.g. a notification window. It's a KDE specific extension as property _KDE_NET_ACTIVE_SCREEN and announced in the supported properties. Diffs - tests/activeoutputtest.cpp PRE-CREATION tests/CMakeLists.txt ce68cc505a69ea9a3cf645e9ae587bd89abe1648 src/netwm_p.h 41792b330f7405034f4d51fb31a4de5dd674b6d0 src/netwm_def.h 8b1ccb8bd731aefb9559c8f2b450337b0312ed4d src/netwm.cpp 84eb137492e0afaaac80e8d26561fd8f8aff9c27 src/netwm.h 393a29de3153a8b291b9fb249bd3eaeb1ba4e7d5 src/kwindowsystem_x11.cpp 01c78c1debf95d5a176e2153139da19abf383c41 src/kwindowsystem_win.cpp 96148b2d808396a3046204e55fd19d767db017c5 autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 src/kwindowsystem.h 3de0fea179dd468a78a265808fc64704027ec30d src/kwindowsystem_mac.cpp 8bd2ac763fa26ba49e7733fc3ba93e755383928c Diff: https://git.reviewboard.kde.org/r/115137/diff/ Testing --- * wm part of NETWM is unit tested * KWindowSystem is only compile tested (unit testing is difficult as we need a window manager which supports this property which is at the moment of this writing: none) * Windows and Mac is not even compile tested, that's why kdewin is included in the review. If you have the time for it, please do a compile test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 8:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade. I
Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/#review51972 --- This review has been submitted with commit eea8251903f427f02452f390374335297afe0e09 by David Faure to branch master. - Commit Hook On Feb. 23, 2014, 11 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/ --- (Updated Feb. 23, 2014, 11 a.m.) Review request for KDE Frameworks and Albert Astals Cid. Repository: kconfigwidgets Description --- 3 commits: Unittest: make errors readable -- Resurrect KConfigDialog::setHelp (used to come from KDialog). It controls the default behavior of showHelp(), which is implemented using KHelpClient. REVIEW: 115959 -- Move KHelpClient down from kxmlgui, for use in KConfigDialog. Diffs - autotests/kconfigdialog_unittest.cpp e5322c1782c2a68c15451777066e28a9b7afea23 src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 src/khelpclient.h PRE-CREATION src/khelpclient.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115959/diff/ Testing --- Compiled all of KF5. 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 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review51973 --- This review has been submitted with commit c132a0d84ca4a51bb099257e9bad20f32e590b6d by David Gil to branch master. - Commit Hook On Feb. 25, 2014, 10:50 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 25, 2014, 10:50 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - autotests/kcombobox_unittest.cpp 49ef721 src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115395: Also pass -fno-exceptions when building with clang
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115395/#review51974 --- Ship it! Let's give it a try as the situation in frameworks land looks better than the one in KDE4. - Raphael Kubo da Costa On March 4, 2014, 11:02 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115395/ --- (Updated March 4, 2014, 11:02 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Also pass -fno-exceptions when building with clang All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions The only problem related to clang and -fno-exceptions I could find was http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since clang version 3.0 which was released in December 2011 Diffs - kde-modules/KDECompilerSettings.cmake 5225b167106481db700e4bd906a1063e737102d4 Diff: https://git.reviewboard.kde.org/r/115395/diff/ Testing --- compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3 Would be good if someone with an older clang version could test it and see whether it works. May also be related to the libstdc++ headers (4.8 installed here). Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdesrc-build] /: kf5: Port rc files to use branch-groups consistently.
On Tuesday 04 March 2014 01:32:14 Michael Pyne wrote: kf5: Port rc files to use branch-groups consistently. Thanks! This should be absolutely transparent except that kde-kactivities will rename to kactivities, though you might have to update kde-build-metadata first if you're using --pretend to test changes. It wasn't that transparent at all - a number of modules have been re- downloaded in a different location in my local source directory: * plasma-frameworks moved under playground/libs * kactivities moved under kde/kdelibs/kactivities (a very odd location in the frameworks world, but kde_projects.xml is global, not branch-dependent) * kde-runtime moved under kde * kde-workspace moved under kde When I say moved -- it's more like there are two copies now, the old one and the new one. Warning to developers of these modules: move your changes over to the new location and delete the old one! Otherwise kdesrc-build will overwrite (in your install dir) what you manually installed from the old location. I am in favour of this change (to use module-sets and centralize branch information in kde-build-metadata), but beware of the migration !! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Building KF5/Kate fails
Building KF5 mostly works, except I now get the error (cleaned build + install folder) below when building kate. It looks as if Qt4 is somehow in the way now. This used to work before, so is there any way to get it working again? The detailed cmake logs are on paste.kde.org (see below). Greetings ;) Dominik # kdesrc-build running: 'cmake' '/home/dh/kde/kf5/src/kde/applications/kate' '-DKDE4_BUILD_TESTS=TRUE' '-DLIB_SUFFIX=64' '-DCMAKE_BUILD_TYPE=Debug' '-DCMAKE_CXX_FLAGS:STRING=-pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op ' '-DCMAKE_INSTALL_PREFIX=/home/dh/kde/kf5/usr' # from directory: /home/dh/kde/kf5/build/kde/applications/kate -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- 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 -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found CMake Error at /usr/share/kde4/apps/cmake/modules/FindQt4.cmake:886 (MESSAGE): Could NOT find QtCore. Check /home/dh/kde/kf5/build/kde/applications/kate/CMakeFiles/CMakeError.log for more details. Call Stack (most recent call first): /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:420 (find_package) /home/dh/kde/kf5/usr/share/cmake-3.0/Modules/FindKDE4.cmake:108 (find_package) CMakeLists.txt:8 (find_package) -- Configuring incomplete, errors occurred! See also /home/dh/kde/kf5/build/kde/applications/kate/CMakeFiles/CMakeOutput.log. ( http://paste.kde.org/pin3zxzhc ) See also /home/dh/kde/kf5/build/kde/applications/kate/CMakeFiles/CMakeError.log. ( http://paste.kde.org/pqfrz4jie ) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116068: Bump supported DocBookXML version to 4.5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116068/#review51978 --- This review has been submitted with commit 60f900ce562a4fb1148c7495e750c1a679012315 by Luigi Toscano to branch master. - Commit Hook On Feb. 27, 2014, 10:40 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116068/ --- (Updated Feb. 27, 2014, 10:40 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- - rename the DTD file (the old one will be kept for for compatibility in kde4support) - adapt the existing documentation: - please note that these changes (usage of the new DTD) should be applied to all the documentation shipped with other Frameworks and with the documentation of modules that do not require KDE4Support (see next RR).-- The change should be mostly a matter of replacing the DTD, as DocBookXML 4.5 is backward compatible with 4.2 according the specifications. This RR comprises the steps 3a) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - src/CMakeLists.txt 0329bd3 docs/meinproc5/man-meinproc5.8.docbook 77799b4 docs/qt5options/man-qt5options.7.docbook 7afbf07 docs/kf5options/man-kf5options.7.docbook cb7973d cmake/FindDocBookXML4.cmake eb4bfd8 docs/checkXML5/man-checkXML5.1.docbook 68509b9 src/customization/catalog.xml 229ae70 src/customization/dtd/kdedbx45.dtd.cmake PRE-CREATION src/customization/dtd/kdex.dtd.cmake c2f7b2c src/man-template.docbook bdc88c7 src/template.docbook 08762e5 Diff: https://git.reviewboard.kde.org/r/116068/diff/ Testing --- Compilation (including the other RR) Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115875: kconfigtest: write everything into a subdirectory
On March 4, 2014, 10:11 p.m., David Faure wrote: autotests/kconfigtest.cpp, line 86 https://git.reviewboard.kde.org/r/115875/diff/2/?file=251983#file251983line86 Just curious, what's the reason for the .. then? Doesn't this still make this test potentially conflict with other tests that use kdeglobals? Yeah it does. But now only tests using kdeglobals are a problem, before it deleted the whole ~/.qttest/config directory which means all config files were lost. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/#review51961 --- On March 4, 2014, 9:58 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/ --- (Updated March 4, 2014, 9:58 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- kconfigtest: write everything into a subdirectory This test keeps deleting the whole ~/.qttest directory. By moving all data into a subdirectory it is now possible to run multiple tests that use kconfig in parallel. Diffs - autotests/kconfigtest.cpp 1c0dc1cf63539e29236ab57e1e848930b468053a Diff: https://git.reviewboard.kde.org/r/115875/diff/ Testing --- Test still passes. No files (except kdeglobals) are created in ~/.qttest/config Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115395: Also pass -fno-exceptions when building with clang
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115395/ --- (Updated March 4, 2014, 10:22 p.m.) Status -- This change has been marked as submitted. Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Also pass -fno-exceptions when building with clang All of KF5 + kate + kde-workspace compile with clang and -fno-exceptions The only problem related to clang and -fno-exceptions I could find was http://llvm.org/bugs/show_bug.cgi?id=10910 and that is fixed since clang version 3.0 which was released in December 2011 Diffs - kde-modules/KDECompilerSettings.cmake 5225b167106481db700e4bd906a1063e737102d4 Diff: https://git.reviewboard.kde.org/r/115395/diff/ Testing --- compiled all of kf5 + kate + kde-workspace without any issues using clang 3.3 Would be good if someone with an older clang version could test it and see whether it works. May also be related to the libstdc++ headers (4.8 installed here). Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/#review51985 --- This review has been submitted with commit ee93faa6b3cc4dc1437d754963dc17a13a18eacd by Luigi Toscano to branch master. - Commit Hook On Feb. 27, 2014, 10:43 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/#review51987 --- This review has been submitted with commit 8a38d264352f45f9e4bd06048d118eaae864d438 by Luigi Toscano to branch master. - Commit Hook On Feb. 27, 2014, 10:43 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/#review51986 --- This review has been submitted with commit 301f25a128f19f73d93cd2e620fe671f2fbba789 by Luigi Toscano to branch master. - Commit Hook On Feb. 27, 2014, 10:43 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated March 4, 2014, 10:33 p.m.) Status -- This change has been marked as submitted. Review request for Documentation and KDE Frameworks. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116603: Expose the QDialogButtonBox in KPasswordDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116603/ --- Review request for KDE Frameworks. Repository: kwidgetsaddons Description --- KPasswordDialog used to be a KDialog. There, users could interact with the buttons setup (like sudlg.cpp in kde-runtime/kdesu). The fact that it was re-based to QDialog, we lost the ability of editing the buttons at all. This change exposes the buttonBox(), so the user re-gains this feature, through QDialogButtonBox. Diffs - src/kpassworddialog.h 069e301 src/kpassworddialog.cpp cacf31a Diff: https://git.reviewboard.kde.org/r/116603/diff/ Testing --- Ported sudlg.cpp to it, they need it because it requires an Ignore button over there. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
DocBookXML version is 4.5 in KF5: check your documentation
Hi all, the version of DocBookXML used by our documentation has been changed in Frameworks; our custom DTD is now based on 4.5 instead of 4.2. The change should be *almost* painless, because the new version is backward compatibile. Only the DTD needs to be changed. Exception: if your application still depends on kde4support, the old DTD should work. Otherwise you need to apply to all .docbook files a patch like: http://commits.kde.org/konsole/2871df82f73ca0bd27779853d3f6e7ff344c98e2 I ported all Frameworks, kde-runtime and few applications, but for sure I've missed something (plasma for sure), in case of failures (and you depends on a snapshot of KF5 and not the last alpha2) please fix it. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated March 4, 2014, 11:11 p.m.) Review request for KDE Frameworks. Changes --- Address David's remarks. I'm a noob. . Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs (updated) - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116603: Expose the QDialogButtonBox in KPasswordDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116603/#review51992 --- Ship it! Should this remain internal API? If yes, please mark it as such. If not, please add some documentation. - Christoph Feck On March 4, 2014, 11:05 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116603/ --- (Updated March 4, 2014, 11:05 p.m.) Review request for KDE Frameworks. Repository: kwidgetsaddons Description --- KPasswordDialog used to be a KDialog. There, users could interact with the buttons setup (like sudlg.cpp in kde-runtime/kdesu). The fact that it was re-based to QDialog, we lost the ability of editing the buttons at all. This change exposes the buttonBox(), so the user re-gains this feature, through QDialogButtonBox. Diffs - src/kpassworddialog.h 069e301 src/kpassworddialog.cpp cacf31a Diff: https://git.reviewboard.kde.org/r/116603/diff/ Testing --- Ported sudlg.cpp to it, they need it because it requires an Ignore button over there. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KSpeech
Hello all, I've realized a bit ago that kspeech was not included in the kdelibs split (probably because it was in staging at the time and didn't conform to the other framework policies yet). I've cleaned it up a bit and put it in my scratch space, but have some architectural questions about it before I make it a proper framework. 1. The KSpeech dbus interface is old and showing its age. Many of the methods are no longer implemented in the application itself since it was ported to speech-dispatcher. One thing I would definitely like to do is clean up/remove methods that aren't implemented currently (and possibly re add some later on if speech-dispatcher gets better/more support for job control, etc.) So the question about this is is KF5 time a good time to drop/clean up the dbus interface? 2. The KSpeech interface that was in kdelibs/interfaces is just that a dbus interface only. I would like to make it a proper library/framework with a QObject based class for talking to Jovie (the application that implements the KSpeech dbus interface) and wonder if other things such as what's currently in jovie/libkttsd should be in the kspeech library also. If I move code from jovie into libkspeech (or merge kspeech interface into libkttsd and make libkttsd a framework likely renamed to libkspeech since libkttsd isn't a public library anyway and has the old ktts name) what's the best way to preserve the history of both the kspeech interface and libkttsd sources. Didn't the plasma or kde-workspaces split do something fancy with git where old history pointed to the old git repo somehow? Along with this, if libkspeech is defining the kspeech dbus interface and has a class to talk to that interface, does the interface still need to be in servicetypes like the dbustexttospeech.desktop file that was installed in /usr/share/kde4/servicetypes in kde4 times? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116603: Expose the QDialogButtonBox in KPasswordDialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116603/#review51995 --- src/kpassworddialog.h https://git.reviewboard.kde.org/r/116603/#comment36946 Maybe move this below bool checkPassword() so that it is protected? I don't think it needs to be a public function, being able to customize it in subclasses is fine IMO - Alexander Richardson On March 5, 2014, 12:05 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116603/ --- (Updated March 5, 2014, 12:05 a.m.) Review request for KDE Frameworks. Repository: kwidgetsaddons Description --- KPasswordDialog used to be a KDialog. There, users could interact with the buttons setup (like sudlg.cpp in kde-runtime/kdesu). The fact that it was re-based to QDialog, we lost the ability of editing the buttons at all. This change exposes the buttonBox(), so the user re-gains this feature, through QDialogButtonBox. Diffs - src/kpassworddialog.h 069e301 src/kpassworddialog.cpp cacf31a Diff: https://git.reviewboard.kde.org/r/116603/diff/ Testing --- Ported sudlg.cpp to it, they need it because it requires an Ignore button over there. 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 116538: Make README.md consistent with other frameworks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116538/ --- (Updated March 5, 2014, 12:26 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Repository: sonnet Description --- Adapt formatting and content of links to make the README.md consistent with all the other frameworks. Diffs - README.md b211ae21d8f4414c025ac628dcbee009b05c9e36 Diff: https://git.reviewboard.kde.org/r/116538/diff/ Testing --- Thanks, Cornelius Schumacher ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs
On March 4, 2014, 4:42 p.m., Lamarque Souza wrote: Ship It! Lamarque Souza wrote: This should be ported to branches master and NM/0.9.8 as well. Alexander Richardson wrote: How should I commit it? Commit to oldest branch and then merge? Or rather put this into qt5 and then apply patches to the other branches? The latter might make merging a bit harder. I usually apply to master e cherry-pick individual commits to NM/0.9.8. The CMakeListst.txt in qt5 branch is quit different from the ones in the other branches, your patch does not apply. - Lamarque --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/#review51909 --- On March 4, 2014, 4:13 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated March 4, 2014, 4:13 p.m.) Review request for KDE Frameworks, Daniel Nicoletti, Lamarque Souza, and Sebastian Kügler. Repository: libnm-qt Description --- Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs This means there is no longer a need for passing -DLIB_SUFFIX=64 on e.g. openSuSE, since CMake will detect the correct install directory for most distributions. If for some reason CMake doesn't detect the correct directory it can be overriden using e.g. -DCMAKE_INSTALL_LIBDIR=lib32 Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 include/CMakeLists.txt 2b51ced include/settings/CMakeLists.txt 1a00bdb Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdesrc-build] /: kf5: Port rc files to use branch-groups consistently.
On Tue, March 4, 2014 22:54:42 David Faure wrote: On Tuesday 04 March 2014 01:32:14 Michael Pyne wrote: kf5: Port rc files to use branch-groups consistently. Thanks! This should be absolutely transparent except that kde-kactivities will rename to kactivities, though you might have to update kde-build-metadata first if you're using --pretend to test changes. It wasn't that transparent at all - a number of modules have been re- downloaded in a different location in my local source directory: Yes, sorry about that; I had manually migrated those myself and completely forgot to mention that you'd want to double-check these yourself. Thanks for bringing that up as a reminder. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116604: Allow directories with . as output for meinproc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116604/ --- Review request for Documentation, KDE Frameworks, kdelibs, and Aleix Pol Gonzalez. Bugs: 246755 https://bugs.kde.org/show_bug.cgi?id=246755 Repository: kdoctools Description --- The outputFile parameter is not used by the stylesheets, so don't pass it. If a directory starts with ., it is interpreted in a wrong way by libxslt with an error like: --- XPath error : Invalid expression /home/kde-devel/.cache5/khelpcenter/help/__home__kde- devel__kde__share__doc__HTML__en__kioslave__file__index.docbook ^ runtime error Evaluating user parameter outputFile failed --- This is an old issue, it was solved on windows by not compiling that code, but I suspect that the issue has been in UNIX systems too for a long time. Another way to solve the bug is quoting the value of the parameter with '...', replacing: params.append(qstrdup(parser.value(QStringLiteral(output)).toLocal8Bit().constData())); with something like QString quotedOutput = ' + parser.value(QStringLiteral(output)) + '; params.append(qstrdup(quotedOutput.toLocal8Bit().constData())); but anyway in this case the name of output file is not used, or I can't find any occurrence in the stylesheets. The stylesheet is applied and the name of the file is used only after to write the generated XML (see tranform() function). A similar patch can be applied to kdelibs/kdoctools too (same codepath). Diffs - src/meinproc.cpp 95adcea Diff: https://git.reviewboard.kde.org/r/116604/diff/ Testing --- Run meinproc5 (and 4) with -o /something/with/a/.dotdir/myfile.txt (the directory must exist), no error anymore and the file is generated. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KGuiAddons Review
On Tue, March 4, 2014 18:46:53 John Layt wrote: KImageCache KSharedPixmapCacheMixin KLocalImageCacheImplementation - Looks OK - KImageCache not exported, but KLocalImageCacheImplementation is, some CMake magic involved? No CMake. :) KImageCache depends on KSharedDataCache from KCoreAddons but we didn't want to make a hard dep on KCoreAddons from KGuiAddons. So instead the differences between KImageCache are coded into a class KLocalImageCacheImplementation (which is exported as you noted). The API of KSharedDataCache that is needed is replaced by a template class KSharedPixmapCacheMixin. KImageCache itself then becomes a macro expanding to KSharedPixmapCacheMixinKSharedDataCache, which is generated by the compiler and thus doesn't need an export (this despite being an internal class marked as @internal). Doing it this way allows a sort of weak reference to KSharedDataCache without having to define KSharedDataCache. It might even be possible to forward-declare KSharedDataCache and use a typedef instead but I didn't even do the porting work here and that didn't occur to me when I was reviewing the patch a few months back. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Building KF5/Kate fails
On Tue, March 4, 2014 22:56:03 Dominik Haumann wrote: Building KF5 mostly works, except I now get the error (cleaned build + install folder) below when building kate. It looks as if Qt4 is somehow in the way now. This used to work before, so is there any way to get it working again? It seems to be looking for Qt4 specifically. You might want to see if kdesrc- build didn't accidentally switch the source git-branch to the KDE4 one instead of KDE5 one (it should list the branch it's using as it updates the module). Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: DocBookXML version is 4.5 in KF5: check your documentation
On Wed, March 5, 2014 00:07:30 Luigi Toscano wrote: Hi all, the version of DocBookXML used by our documentation has been changed in Frameworks; our custom DTD is now based on 4.5 instead of 4.2. The change should be *almost* painless, because the new version is backward compatibile. Only the DTD needs to be changed. Exception: if your application still depends on kde4support, the old DTD should work. Otherwise you need to apply to all .docbook files a patch like: http://commits.kde.org/konsole/2871df82f73ca0bd27779853d3f6e7ff344c98e2 I ported all Frameworks, kde-runtime and few applications, but for sure I've missed something (plasma for sure), in case of failures (and you depends on a snapshot of KF5 and not the last alpha2) please fix it. Thanks. I've also updated our Porting Notes at http://community.kde.org/Frameworks/Porting_Notes Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated March 5, 2014, 2:46 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, Daniel Nicoletti, Lamarque Souza, and Sebastian Kügler. Repository: libnm-qt Description --- Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs This means there is no longer a need for passing -DLIB_SUFFIX=64 on e.g. openSuSE, since CMake will detect the correct install directory for most distributions. If for some reason CMake doesn't detect the correct directory it can be overriden using e.g. -DCMAKE_INSTALL_LIBDIR=lib32 Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 include/CMakeLists.txt 2b51ced include/settings/CMakeLists.txt 1a00bdb Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/#review52000 --- This review has been submitted with commit fb5d0510dbc136ce9c815f106b943a7f0c87aa34 by Alex Richardson to branch qt5. - Commit Hook On March 4, 2014, 4:13 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated March 4, 2014, 4:13 p.m.) Review request for KDE Frameworks, Daniel Nicoletti, Lamarque Souza, and Sebastian Kügler. Repository: libnm-qt Description --- Drop unneccessary dependency on extra-cmake-modules and use GNUInstallDirs This means there is no longer a need for passing -DLIB_SUFFIX=64 on e.g. openSuSE, since CMake will detect the correct install directory for most distributions. If for some reason CMake doesn't detect the correct directory it can be overriden using e.g. -DCMAKE_INSTALL_LIBDIR=lib32 Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 include/CMakeLists.txt 2b51ced include/settings/CMakeLists.txt 1a00bdb Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review52006 --- Ship it! Ship It! - Kevin Ottens On March 4, 2014, 11:11 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated March 4, 2014, 11:11 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116542: Fix compilation with clang 3.4.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/#review52007
---
Ship it!
I wrote that code - sorry for the trouble and thanks for taking care of it. I
wasn't aware at all that there might be a problem if the operator== is
declared outside the namespace, but if I had been, then I would have put it
inside he namespace, of course. So Ship it! from me too.
- Frank Reininghaus
On March 2, 2014, 8:20 p.m., Milian Wolff wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116542/
---
(Updated March 2, 2014, 8:20 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
Fix compilation with clang 3.4.
Note that I'm not too sure why this compiled with GCC
and why clang rejects the global operator== definition and
wants to have it in the KIO namespace. Someone with more C++
ADL knowledge should chime in whether this is the right fix.
In file included from kio/tests/udsentrybenchmark.cpp:22:
In file included from /usr/include/qt/QtTest/QTest:1:
/usr/include/qt/QtTest/qtest.h:203:24:
error: call to function 'operator==' that is neither visible
in the template definition nor found by argument-dependent lookup
if (!(t1.at(i) == t2.at(i))) {
^
kio/tests/udsentrybenchmark.cpp:286:22: note: in instantiation of
function template specialization 'QTest::qCompareKIO::UDSEntry'
requested here
do { if (!QTest::qCompare(entries, m_smallEntries, entries,
m_smallEntries, kio/tests/udsentrybenchmark.cpp, 286)) return;}
while (0);
kio/tests/udsentrybenchmark.cpp:246:6: note: 'operator==' should be
declared prior to the call site or in namespace 'KIO'
bool operator==(const KIO::UDSEntry a, const KIO::UDSEntry b)
^
1 error generated.
udsentrybenchmark.dir/build.make:54: recipe for target
'tests/CMakeFiles/udsentrybenchmark.dir/udsentrybenchmark.cpp.o'
failed
Diffs
-
tests/udsentrybenchmark.cpp 75fc758e583f7586c7b9a576d984b40912fa3ace
Diff: https://git.reviewboard.kde.org/r/116542/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 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review52010 --- Ship it! Ship It! - David Faure On March 4, 2014, 11:11 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated March 4, 2014, 11:11 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp c347521 Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
