Review Request 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray 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 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/#review50904 --- src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/116075/#comment35725 couldn't this be replaced with m_items.removeOne(ours) ? - Thomas Braxton On Feb. 26, 2014, 8:09 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- (Updated Feb. 26, 2014, 8:09 a.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray 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 116064: @deprecated docs for KUrl methods that duplicate QUrl methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116064/#review50906 --- src/kdecore/kurl.h https://git.reviewboard.kde.org/r/116064/#comment35726 I would say: @deprecated since 5.0, use Foo instead. - David Gil Oliva On Feb. 25, 2014, 11:03 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116064/ --- (Updated Feb. 25, 2014, 11:03 p.m.) Review request for KDE Frameworks. Repository: kde4support Description --- @deprecated docs for KUrl methods that duplicate QUrl methods Some KUrl methods just forward to their QUrl counterparts (or do .isEmpty() on a QUrl method result); replace the apidox for these with a note saying what QUrl method should be used instead. Diffs - src/kdecore/kurl.h 4ac893382c76def83f8e6e12698931df243085f9 Diff: https://git.reviewboard.kde.org/r/116064/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: KDE 5 versioning in documentation
Am Dienstag, 25. Februar 2014, 22.47:51 schrieb Martin Klapetek: Hey, Morning [snip] Will the KDE Software Compilation still be a thing in the KF5 era, complete with its own versioned releases? If that's the case, we'll probably just want to change KDE to KDE SC in the releaseinfo for frameworks-based apps and call it a day. Not in its current form afaik. There will be three big modules - Frameworks, Plasma and Applications. Given the progress on their 5 versions is different, there are also different release schedules for both, so no more SC in the current sense (that name also got dropped couple years ago, no?). Correct. The SC was just an engineering/technical term. It was never intended to us in promo communication or for end users (of our apps, not our libs). See all the recent release announcement. There we never used SC. We'd like to put heavy accent on *not* using KDE anymore in around the workspace releases, so no more KDE Plasma, but just Plasma, possibly with by KDE touch. It'd be awesome to get it away from apps to, so it would become Dolphin for Plasma instead of KDE Dolphin etc. Dolphin for Plasma shouldn't be used as well, if I see it correctly, as Dolphin work on Gnome, razorqt and Co as well and not just on Plasma. So just Dolphin or Dolphin by KDE. Plus what Luigi wrote! If we're instead going to release all applications on their own schedules, we'll instead probably just want to drop any mention of a KDE version in applications' documentation. (Or add on KDE Frameworks 5 or something like that?) I'm not sure what's the plan for apps. Their 4 versions will just work with Plasma and we expect to actually ship the first Plasma with applications based on kdelibs (please correct me if I'm wrong). I'm also going to submit a review request shortly adding entities for all this new nomenclature so we can refer to it consistently in documentation in KF5-based applications. People interested in this sort of thing please double-check it for accuracy.. Cool, make sure you add kdeframeworks group as reviewers. Cheers Best regards Mario ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/#review50909 --- src/platformtheme/kdeplatformsystemtrayicon.h https://git.reviewboard.kde.org/r/116075/#comment35727 remove virtual and add Q_DECL_OVERRIDE? or change the signature at SystemTrayMenu? currently that is a bit inconsistent :) src/platformtheme/kdeplatformsystemtrayicon.h https://git.reviewboard.kde.org/r/116075/#comment35728 see above src/platformtheme/kdeplatformsystemtrayicon.cpp https://git.reviewboard.kde.org/r/116075/#comment35729 I see lambdas being using later on, in which case this looks like a candidate for std::find_if() with a lambda predicate - Kevin Krammer On Feb. 26, 2014, 8:09 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- (Updated Feb. 26, 2014, 8:09 a.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray 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 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/#review50910 --- +1 from me - Marco Martin On Feb. 26, 2014, 8:09 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- (Updated Feb. 26, 2014, 8:09 a.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray 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 116075: Provide an implementation for QPlatformSystemTrayIcon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/#review50911 --- +1 from me - Marco Martin On Feb. 26, 2014, 8:09 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116075/ --- (Updated Feb. 26, 2014, 8:09 a.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: frameworkintegration Description --- Add menu support to KDEPlatformSystemTrayIcon Uses new QPA API which got introduced in Qt 5.3. Provide an implementation for QPlatformSystemTrayIcon The idea is to force all QSystemTrayIcon to use our status notifiers as we don't want to provide an xembed based system tray in the next iteration of the Plasma desktop shell anymore. The KDEPlatformSystemTrayIcon uses a KStatusNotifierItem to implement the system tray icon. Unfortunately a complete wrapping is not yet possible as we cannot create a menu. We do not want to provide a QPlatformMenu in our PlatformTheme and thus the menu used by QSystemTrayIcon does not have a QPlatformMenu. This is adressed in Qt 5.3 which extends the QPA API. Diffs - autotests/CMakeLists.txt fb58b3a0cb9acc062be0edeb53210048e364c1be src/platformtheme/CMakeLists.txt 5fd949bee41b762120e120148de0b3b473de915c src/platformtheme/kdeplatformsystemtrayicon.h PRE-CREATION src/platformtheme/kdeplatformsystemtrayicon.cpp PRE-CREATION src/platformtheme/kdeplatformtheme.h f436eea4e3aa9cfda62654e5c6dc77aea05e8f27 src/platformtheme/kdeplatformtheme.cpp a5d86c27385447b7744cb8bca0cf65889872fb0b Diff: https://git.reviewboard.kde.org/r/116075/diff/ Testing --- Using systray from qtbase/examples/widgets/desktop/systray Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDNSSD merge
On 26/02/14 07:09, Kevin Ottens wrote: On Tuesday 25 February 2014 20:37:28 Alex Merry wrote: I've had a look at the kdnssd repositoy, and it contains two related bits of code: the zeroconf ioslave and a kded/KDirWatch module to notify KIO about changes to available services. These two obviously belong together; the question is where? They can go in kdnssd-framework, making it depend on KIO, or they can go in KIO, making it (optionally) depend on KDNSSD. My preference would be to put it in KIO, since KIO seems an unnecessarily big thing for KDNSSD to drag in. My preference as well. Would need confirmation from David that he's fine with that, but I'm not sure he'll be reading his emails in the coming days. Also, what happens to the old repo, which is part of kdenetwork, and hence KDE SC? I'd say it keeps the old copies until it is switched to KF5 itself. After that kdnssd stuff can disappear from there. Actually, having slept on it, my suggestion is: - rename kdnssd to zeroconf-ioslave - rename kdnssd-framework to kdnssd - merge the frameworks branch of zeroconf-ioslave into kio BTW, I hope you've seen Matthieu Gallien patch around kdnssd? Would be nice if you could take a shot at reviewing it, it's nice to see more people getting involved. I'll have a look. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116064: @deprecated docs for KUrl methods that duplicate QUrl methods
On Feb. 26, 2014, 9:12 a.m., David Gil Oliva wrote: src/kdecore/kurl.h, line 386 https://git.reviewboard.kde.org/r/116064/diff/1/?file=246155#file246155line386 I would say: @deprecated since 5.0, use Foo instead. I'm not sure how useful that is; everything in kde4support is deprecated since 5.0 by definition. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116064/#review50906 --- On Feb. 25, 2014, 11:03 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116064/ --- (Updated Feb. 25, 2014, 11:03 p.m.) Review request for KDE Frameworks. Repository: kde4support Description --- @deprecated docs for KUrl methods that duplicate QUrl methods Some KUrl methods just forward to their QUrl counterparts (or do .isEmpty() on a QUrl method result); replace the apidox for these with a note saying what QUrl method should be used instead. Diffs - src/kdecore/kurl.h 4ac893382c76def83f8e6e12698931df243085f9 Diff: https://git.reviewboard.kde.org/r/116064/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 116056: Port to Qt5 and Kf5 of dnssd ioslave and kded module
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116056/#review50915 --- Argh, sorry, I completely missed this review request, and just went ahead and created a ported frameworks branch. I'll give you some feedback anyway, for future reference... CMakeLists.txt https://git.reviewboard.kde.org/r/116056/#comment35733 Not needed, since this module only installs runtime code, and no headers ioslave/CMakeLists.txt https://git.reviewboard.kde.org/r/116056/#comment35738 I found I needed to link against KF5::I18n; I wonder why you didn't? ioslave/CMakeLists.txt https://git.reviewboard.kde.org/r/116056/#comment35734 Not needed, the KDECMakeSettings module already does this for MODULE library targets. ioslave/dnssd.h https://git.reviewboard.kde.org/r/116056/#comment35735 The comment should have gone as well. ioslave/dnssd.cpp https://git.reviewboard.kde.org/r/116056/#comment35736 qplatformdefs.h would add everything that was needed, and be cross-platform. ioslave/dnssd.cpp https://git.reviewboard.kde.org/r/116056/#comment35737 QStringLiteral is better than QLatin1String for arguments that will just be cast to QString like this. QLatin1String is more for things like equality tests with QStrings. kdedmodule/watcher.h https://git.reviewboard.kde.org/r/116056/#comment35739 With Qt 5, we can use Q_DECL_OVERRIDE in subclasses, like QUrl constructUrl() Q_DECL_OVERRIDE; Thanks for doing this work, and sorry for not using it! In terms of what to do instead, I suggest one of: - look into porting things in kde-runtime (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization) - the reduce mentions of kde 4 in source code task from http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation#Tasks_for_Final_Release - look for todos and warnings in the frameworks to resolve If you want more pointers, I and other frameworks folks are usually hanging around on #kde-devel on irc, and there's the kde-frameworks-devel email list. - Alex Merry On Feb. 25, 2014, 8:02 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116056/ --- (Updated Feb. 25, 2014, 8:02 p.m.) Review request for KDE Frameworks. Repository: kdnssd Description --- Basic port to Qt5 and Kf5 in order to help the merge of the two kdnssd repositories. Diffs - CMakeLists.txt df842d4 ioslave/CMakeLists.txt 40c2d67 ioslave/dnssd.h 89afd8d ioslave/dnssd.cpp c0c8ada ioslave/zeroconfurl.h f4f06de kdedmodule/CMakeLists.txt 6232940 kdedmodule/dnssdwatcher.h a2062fc kdedmodule/dnssdwatcher.cpp 2e4dc25 kdedmodule/watcher.h 5d5470b kdedmodule/watcher.cpp 21018b9 Diff: https://git.reviewboard.kde.org/r/116056/diff/ Testing --- Not much. I do not know how to test the ioslave without something like dolphin. Thanks, Matthieu Gallien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116079: Be more explicit with QFile include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE 5 versioning in documentation
On Wed, Feb 26, 2014 at 9:26 AM, Mario Fux KDE ML kde...@unormal.orgwrote: Dolphin for Plasma shouldn't be used as well, if I see it correctly, as Dolphin work on Gnome, razorqt and Co as well and not just on Plasma. So just Dolphin or Dolphin by KDE. Plus what Luigi wrote! Yup, that makes perfect sense. +1 to that. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116080: find_dependency: Update to match CMake's version
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116080/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- find_dependency: Update to match CMake's version Specifically, we namespace the variables to avoid conflicts, and make the version argument optional. Diffs - modules/ECMPackageConfigHelpers.cmake ee6bfd6f7e79a9f842ad6d34931a9273c2ee3c4f Diff: https://git.reviewboard.kde.org/r/116080/diff/ Testing --- None yet, but I'll do a rebuild of the frameworks before I commit. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDNSSD merge
On 26/02/14 10:01, Alex Merry wrote: Actually, having slept on it, my suggestion is: - rename kdnssd to zeroconf-ioslave - rename kdnssd-framework to kdnssd - merge the frameworks branch of zeroconf-ioslave into kio I don't think the last part is necessarily a blocker, either (although it's easy enough to do). As with the kde-runtime stuff, it's not really an issue if it gets delayed until 5.1. The repo name changes are going to be the painful parts. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kactivities5 build failure
doing a clean rebuild gcc-4.8.2 FAILED: /var/lib/sorcery/build/c++ -DKCOREADDONS_LIB -DQT_CORE_LIB - DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -D_GNU_SOURCE - D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -march=native -mtune=native -m64 - pipe -ffast-math -funroll-loops -O3 -std=c++0x -fno-exceptions -Wall -Wextra - Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -O3 - DNDEBUG -fPIE -Isrc/service -I/var/git/kf5/kactivities5/src/service -Isrc - I/var/git/kf5/kactivities5/src -Isrc/lib/core -isystem /opt/qt5/include - isystem /opt/qt5/include/QtCore -isystem /opt/qt5/mkspecs/linux-g++ -isystem /opt/qt5/include/QtDBus -isystem /opt/qt5/include/QtWidgets -isystem /opt/qt5/include/QtGui -isystem /opt/qt5/include/KF5/KDBusAddons -isystem /opt/qt5/include/KF5 -isystem /opt/qt5/include/KF5/KCoreAddons -isystem /opt/qt5/include/KF5/KConfigCore -isystem /opt/qt5/include/KF5/KI18n -isystem /opt/qt5/include/KF5/KService -isystem /opt/qt5/include/KF5/KWindowSystem -MMD -MT src/service/CMakeFiles/activity-manager.dir/Application.cpp.o -MF src/service/CMakeFiles/activity-manager.dir/Application.cpp.o.d -o src/service/CMakeFiles/activity-manager.dir/Application.cpp.o -c /var/git/kf5/kactivities5/src/service/Application.cpp /var/git/kf5/kactivities5/src/service/Application.cpp: In function 'int main(int, char**)': /var/git/kf5/kactivities5/src/service/Application.cpp:263:55: error: passing 'const QLoggingCategory' as 'this' argument of 'void QLoggingCategory::setEnabled(QtMsgType, bool)' discards qualifiers [- fpermissive] KAMD_LOG_APPLICATION().setEnabled(QtDebugMsg, true); ^ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Re: building Solid
On Wednesday, February 26, 2014 07:52:21 Martin GräÃlin wrote: On Tuesday 25 February 2014 21:27:02 Dominik Haumann wrote: On Tuesday 25 February 2014 20:34:38 Dominik Haumann wrote: Hi, a fresh Qt5 from stable branch, and a fresh frameworks build results in this error when building solid: $ make [ 0%] Automatic moc for target KF5Solid [ 0%] Built target KF5Solid_automoc [ 1%] Building CXX object src/solid/CMakeFiles/KF5Solid.dir/managerbase.cpp.o In file included from /home/dh/kde/kf5/src/frameworks/solid/src/solid/backends/udisks2/udisksm an a ger.h:25:0, from /home/dh/kde/kf5/src/frameworks/solid/src/solid/managerbase.cpp:35: /home/dh/kde/kf5/src/frameworks/solid/src/solid/backends/udisks2/udisks2 .h 30:27: error: conflicting declaration âtypedef class QListQByteArray QByteArrayListâ typedef QListQByteArray QByteArrayList; ^ In file included from /home/dh/kde/kf5/src/qt5/qtbase/include/QtCore/qbytearraylist.h:1:0, from /home/dh/kde/kf5/src/qt5/qtbase/include/QtCore/QtCore:119, from /home/dh/kde/kf5/src/qt5/qtbase/include/QtDBus/QtDBusDepends:2, from /home/dh/kde/kf5/src/qt5/qtbase/include/QtDBus/QtDBus:3, from /home/dh/kde/kf5/src/frameworks/solid/src/solid/backends/udisks2/udisks2 .h 25, from /home/dh/kde/kf5/src/frameworks/solid/src/solid/backends/udisks2/udisksm an a ger.h:25, from /home/dh/kde/kf5/src/frameworks/solid/src/solid/managerbase.cpp:35: /home/dh/kde/kf5/src/qt5/qtbase/src/corelib/tools/qbytearraylist.h:56:7: error: âclass QByteArrayListâ has a previous declaration as âclass QByteArrayListâ class QByteArrayList : public QListQByteArray ^ make[2]: *** [src/solid/CMakeFiles/KF5Solid.dir/managerbase.cpp.o] Error 1 make[1]: *** [src/solid/CMakeFiles/KF5Solid.dir/all] Error 2 make: *** [all] Error 2 So QByteArrayList is once typedeffed in solid/backends/udisks2/udisks2.h, and once in QtCore/qbytearraylist.h Is that intention? https://qt.gitorious.org/qt/qtbase/source/4f23f0530a9c59400a7f3821cd2c9355 80 1ed8cd:src/corelib/tools/qbytearraylist.cpp#L75 \since 5.3 I showed that compile error to Alex last week and he mentioned that there is already some code under review to fix this issue. Alex, what's the status on that? As workaround, one can add a #ifndef around the typedef as follows: + #ifndef QBYTEARRAYLIST_H typedef QListQByteArray QByteArrayList; + #endif That works, and one can at least compile. The correct fix is probably to change it to typedef QListQByteArray ByteArrayList; adapt all all code parts that use this, and all is good. Greetings, Dominik PS: It's never (!) a good idea to add a custom type that has Q* naming style. It leads to totally unnecessary issues like this one ;) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities5 build failure
On Wednesday, 26. February 2014. 13.15.51 Treeve Jelbert wrote: doing a clean rebuild gcc-4.8.2 Qt5.3? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: kactivities5 build failure
On Wednesday, February 26, 2014 14:00:45 Ivan ÄukiÄ wrote: On Wednesday, 26. February 2014. 13.15.51 Treeve Jelbert wrote: doing a clean rebuild gcc-4.8.2 Qt5.3? It fails for me as well with the same error. Yes, Qt 5.3. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDNSSD merge
Le mercredi 26 février 2014 11:54:16 Alex Merry a écrit : On 26/02/14 10:01, Alex Merry wrote: Actually, having slept on it, my suggestion is: - rename kdnssd to zeroconf-ioslave - rename kdnssd-framework to kdnssd - merge the frameworks branch of zeroconf-ioslave into kio I don't think the last part is necessarily a blocker, either (although it's easy enough to do). As with the kde-runtime stuff, it's not really an issue if it gets delayed until 5.1. The repo name changes are going to be the painful parts. Hi, as there is already a kdnssd tarball for kde 4, i think this would be safer to keep the -framework in the name. regards Nicolas. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDNSSD merge
On 02/27/2014 12:36 AM, Nicolas Lécureuil wrote: Le mercredi 26 février 2014 11:54:16 Alex Merry a écrit : On 26/02/14 10:01, Alex Merry wrote: Actually, having slept on it, my suggestion is: - rename kdnssd to zeroconf-ioslave - rename kdnssd-framework to kdnssd - merge the frameworks branch of zeroconf-ioslave into kio I don't think the last part is necessarily a blocker, either (although it's easy enough to do). As with the kde-runtime stuff, it's not really an issue if it gets delayed until 5.1. The repo name changes are going to be the painful parts. Hi, as there is already a kdnssd tarball for kde 4, i think this would be safer to keep the -framework in the name. regards Nicolas. Note that we already had such a change made with kwallet. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities5 build failure
Qt5.3? It fails for me as well with the same error. Yes, Qt 5.3. I'm not going to be able to deal with Qt 5.3 until next version of plasma is released since we are tiesd to 5.2. If anyone provides a patch, it would be appreciated. Cheerio, Ivan ___ 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
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 9
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line9
You can link to
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html
for upstream info on this.
Alex Merry wrote:
I guess
http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules
is the one to extend?
Yep.
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 50
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line50
The imported targets should be the primary way of using the module. I
don't think the _INCLUDES and _LIBRARIES etc variables should even be set
if imported targets are provided.
Alex Merry wrote:
Fair point, although for modules we've previously provided, I'm inclined
to set them for ease of porting.
include_directories(${Foo_INCLUDES})
should be harmless if Foo_INCLUDES is not set.
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 98
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line98
I don't think AUTHOR_WARNING is appropriate here. Why not WARNING?
Alex Merry wrote:
Because it's a warning for authors (of project build scripts) rather than
users (ie: those building the package). I thought that was exactly what
AUTHOR_WARNING was for...
Perhaps. ecm is different because the maintainer/author of the Find modules is
not the one using it, which is generally the case for third party find modules.
Anyway, the cmake-shipped Find-modules also use AUTHOR_WARNING. So, there's
precedent, whether it's the right or wrong thing to do.
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 153
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line153
Don't set Foo_VERSION_STRING, set Foo_VERSION. That is canonical
because of config-file packages.
Alex Merry wrote:
OK; I was following a pattern from other CMake scripts. Also, it is what
http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules
suggests.
The behavior of the config-files determines what is canonical. If the
documentation doesn't recommend the canonical variable name, then I argue the
documentation is incorrect.
On Feb. 25, 2014, 3:56 p.m., Stephen Kelly wrote:
docs/writing-find-modules.md, line 325
https://git.reviewboard.kde.org/r/116025/diff/2/?file=246011#file246011line325
Note that only build-properties of the target itself should be here.
Not those of dependencies (if the dependency provides imported targets,
which it should/must for this stuff to work). CMake will resolve that
itself.
Alex Merry wrote:
Are you saying that INTERFACE_INCLUDE_DIRECTORIES line is wrong? Or that
I should add a comment?
Perhaps add a comment. The INTERFACE_INCLUDE_DIRECTORIES line seems correct.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116025/#review50830
---
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: KItemModels, Solid KJS licenses
On Thursday 20 of February 2014 11:41:48 Alex Merry wrote: CC'd people: please can you confirm that you would be happy to have the files listed below relicensed from GPL to LGPLv2+? Small ping :) It would be awesome if we could get this sorted for alpha2 Cheers, Hrvoje ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel 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 116080: find_dependency: Update to match CMake's version
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116080/ --- (Updated Feb. 26, 2014, 3:07 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- find_dependency: Update to match CMake's version Specifically, we namespace the variables to avoid conflicts, and make the version argument optional. Diffs - modules/ECMPackageConfigHelpers.cmake ee6bfd6f7e79a9f842ad6d34931a9273c2ee3c4f Diff: https://git.reviewboard.kde.org/r/116080/diff/ Testing (updated) --- kdesrc-build with clean build and install dirs successful, using CMake 2.8.12 (and so using this version of find_dependency, rather than the one shipped with CMake 3.0). 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 116079: Be more explicit with QFile include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/#review50945 --- My memory may be failing me, but I think it was actually decided to go the other way around for Qt5 includes: not prepending the module dir. Can anyone else confirm? This should be mentioned in the framework policies, I think. - Aurélien Gâteau On Feb. 26, 2014, 12:19 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- (Updated Feb. 26, 2014, 12:19 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116079: Be more explicit with QFile include
On Feb. 26, 2014, 3:36 p.m., Aurélien Gâteau wrote: My memory may be failing me, but I think it was actually decided to go the other way around for Qt5 includes: not prepending the module dir. Can anyone else confirm? This should be mentioned in the framework policies, I think. Yeah, the conclusion was that using module names in includes caused more trouble than it was worth. We're generally assuming that downstreams will use either qmake or CMake; this shouldn't be an issue with either. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/#review50945 --- On Feb. 26, 2014, 11:19 a.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- (Updated Feb. 26, 2014, 11:19 a.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116079: Be more explicit with QFile include
On Feb. 26, 2014, 3:36 p.m., Aurélien Gâteau wrote: My memory may be failing me, but I think it was actually decided to go the other way around for Qt5 includes: not prepending the module dir. Can anyone else confirm? This should be mentioned in the framework policies, I think. Alex Merry wrote: Yeah, the conclusion was that using module names in includes caused more trouble than it was worth. We're generally assuming that downstreams will use either qmake or CMake; this shouldn't be an issue with either. Although: see http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012052.html - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/#review50945 --- On Feb. 26, 2014, 11:19 a.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- (Updated Feb. 26, 2014, 11:19 a.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116062: Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116062/#review50953 --- Ship it! Ship It! - Aurélien Gâteau On Feb. 25, 2014, 11:35 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116062/ --- (Updated Feb. 25, 2014, 11:35 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches for coherence with the other KCompletion classes. Diffs - src/kcompletionbox.h 8ed2b00 src/kcompletionbox.cpp 571b02f src/kcompletionmatches.h 481a4b9 src/kcompletionmatches.cpp bc381b1 Diff: https://git.reviewboard.kde.org/r/116062/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 116079: Be more explicit with QFile include
On Feb. 26, 2014, 4:36 p.m., Aurélien Gâteau wrote: My memory may be failing me, but I think it was actually decided to go the other way around for Qt5 includes: not prepending the module dir. Can anyone else confirm? This should be mentioned in the framework policies, I think. Alex Merry wrote: Yeah, the conclusion was that using module names in includes caused more trouble than it was worth. We're generally assuming that downstreams will use either qmake or CMake; this shouldn't be an issue with either. Alex Merry wrote: Although: see http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012052.html Fun :/ I'd say we definitely need an official policy on this. - Aurélien --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/#review50945 --- On Feb. 26, 2014, 12:19 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- (Updated Feb. 26, 2014, 12:19 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115695: Rework KNotification to work without KNotify daemon
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115695/ --- (Updated Feb. 26, 2014, 4:53 p.m.) Status -- This change has been discarded. Review request for kde-workspace, KDE Frameworks, Plasma, and Sune Vuorela. Repository: knotifications Description --- This patch merges KNotify daemon into KNotificationManager to have less daemons running and less dbus traffic. The patch is not yet finished (and for now it's full of QDebugs, that will all be removed and FIXMEs to indicate what needs doing), but as the Alpha2 is quite soon, I'd like to start the general review asap so some more changes can be done if needed. Now it's KNotificationManager that handles the KNotifyPlugin-s and hands them the notification directly. KNotifyConfig was repurposed a bit, now it serves mostly just as the .notifyrc wrapper, all the rest is reused from the KNotification object. There are some changes in the KNotification API - id() and appName() are now exposed to public and slotReceivedId(int) is now also public so that KNotificationManager can directly give it an id. I'd like to rename this and make it a non-slot. It's not the DBus/Galago server ID anymore, that is handled in NotifyByPopup which is responsible for communicating with the galago server (all the methods there were renamed to actually have *galago* in the name so it's clear), therefore the mapping of DBus/Galago Server ids is managed only there as it is actually only needed here. KNotitification::id() is assigned by the KNotificationManager and it's a simple increasing counter. The UI/Plasmoid changes will come next - basically the plan is to put only the Persistent notifications in the notifications history. Diffs - src/knotifyconfig.h PRE-CREATION src/knotifyconfig.cpp PRE-CREATION src/knotifyplugin.h PRE-CREATION src/knotifyplugin.cpp PRE-CREATION src/notifybypopup.h PRE-CREATION src/notifybypopup.cpp PRE-CREATION src/notifybypopupgrowl.h PRE-CREATION src/notifybypopupgrowl.cpp PRE-CREATION CMakeLists.txt 63ebf71 src/CMakeLists.txt a81b913 src/knotification.h 00554ba src/knotification.cpp 5d7405b src/knotificationmanager.cpp a4d0dfa src/knotificationmanager_p.h 81d962d Diff: https://git.reviewboard.kde.org/r/115695/diff/ Testing --- Works perfectly with both plasma notifications and kpassivepopup. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116079: Be more explicit with QFile include
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/ --- (Updated Feb. 26, 2014, 4:36 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks and David Faure. Repository: kio Description --- global.h is a public header, so not being more explicit with includes could cause a build failure for consumers. This should probably go into kdelibs too. Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 Diff: https://git.reviewboard.kde.org/r/116079/diff/ Testing --- Builds. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116088: Remove FindDBusMenuQt5.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116088/ --- 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 - 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
Review Request 116087: KCrash: remove usage of strlcpy
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- 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
Review Request 116090: Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116090/ --- 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
KNotify merge in KNotification now in branch
Hey, so as the patch on RB was apparently too big to review in 14 days, I tried to divide it in smaller commits and pushed into a branch mklapetek/knotify-merge in kde:knotifications. So please have a look at that, the commitdiffs might be a bit confusing as it was created from the big diff, but I tried explaining it in the commit message. Also the code has a lot of comments, so you can also just go over the code - it's only three files - knotification.cpp (400 LOC), knotificationmanager.cpp (200 LOC) and notifybypopup.cpp (760 LOC). I've been testing this for about a week now and it all works nicely. So at this point I'd like to get this into the alpha2 release and keep improving it afterwards, the public API shouldn't change anymore (that's KNotification only anyway). As I'd really like to get this in alpha2, I'm going to merge this by Friday night if there will be no hard objections. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: plasma-framework_master_qt5 » All,LINBUILDER #76
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/76/changes Changes: [notmart] add a building version of interactive console [notmart] port Package usage [notmart] instantiate the console [notmart] restore loadScriptInInteractiveConsole() [notmart] port away of kdialog [notmart] use a QFileDialog [notmart] remove klocale [notmart] remove KStandardDirs [notmart] remove KTextBrowser [notmart] remove KIcon [notmart] remove kcomponentdata [notmart] add copyright [notmart] initialize variabiles -- Started by upstream project plasma-framework_master_qt5 build number 76 originally caused by: Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 1 in workspace http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson8083917368408919842.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/plasma-framework c2812c3..d703996 mart/interactiveconsole - origin/mart/interactiveconsole b2fec90..1fd741b master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at b2fec90 Merge branch 'mart/svgHiDpi' Removing build/ Removing install/ Success build forhudson.tasks.Shell@79ad89b4 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision 1fd741b5d30929d18311c050cf3aa1d080088ab5 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson3161564558266472405.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: kwidgetsaddons - Branch master polkit-qt-1 - Branch qt5 kjs - Branch master kwallet - Branch master kactivities - Branch frameworks kross - Branch master kservice - Branch master kwindowsystem - Branch master kidletime - Branch master sonnet - Branch master extra-cmake-modules - Branch master threadweaver - Branch master kiconthemes - Branch master kio - Branch master kcrash - Branch master ktextwidgets - Branch master kdnssd-framework - Branch master ki18n - Branch master karchive - Branch master cmake - Branch master kauth - Branch master solid - Branch master kjobwidgets - Branch master kdeclarative - Branch master kdoctools - Branch master kcoreaddons - Branch master kitemviews - Branch master kdesupport-svn - Branch master kconfig - Branch master kbookmarks - Branch master knotifications - Branch master kxmlgui - Branch master kglobalaccel - Branch master kconfigwidgets - Branch master kdbusaddons - Branch master kguiaddons - Branch master kparts - Branch master kitemmodels - Branch master kcompletion - Branch master qt5 - Branch stable kunitconversion - Branch master kcodecs - Branch master == 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 -- Found PkgConfig: /usr/bin/pkg-config (found version 0.27.1) -- Found XCB_XCB: /usr/lib64/libxcb.so (found version 1.9) -- Found XCB_COMPOSITE: /usr/lib64/libxcb-composite.so (found version 1.9) -- Found XCB_DAMAGE: /usr/lib64/libxcb-damage.so (found version 1.9) -- Found XCB_SHAPE: /usr/lib64/libxcb-shape.so (found version 1.9) -- Found XCB: /usr/lib64/libxcb.so;/usr/lib64/libxcb-composite.so;/usr/lib64/libxcb-damage.so;/usr/lib64/libxcb-shape.so (found version 1.9) found components: XCB COMPOSITE DAMAGE SHAPE -- Found OpenGL: /usr/lib64/libGL.so -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -
Build failed in Jenkins: plasma-framework_master_qt5 » NoX11,LINBUILDER #76
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/76/changes Changes: [notmart] add a building version of interactive console [notmart] port Package usage [notmart] instantiate the console [notmart] restore loadScriptInInteractiveConsole() [notmart] port away of kdialog [notmart] use a QFileDialog [notmart] remove klocale [notmart] remove KStandardDirs [notmart] remove KTextBrowser [notmart] remove KIcon [notmart] remove kcomponentdata [notmart] add copyright [notmart] initialize variabiles -- Started by upstream project plasma-framework_master_qt5 build number 76 originally caused by: 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/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson4561668849385257576.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/plasma-framework c2812c3..d703996 mart/interactiveconsole - origin/mart/interactiveconsole b2fec90..1fd741b master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at b2fec90 Merge branch 'mart/svgHiDpi' Removing build/ Removing install/ Success build forhudson.tasks.Shell@79ad89b4 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision 1fd741b5d30929d18311c050cf3aa1d080088ab5 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson7008327825535198240.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: kguiaddons - Branch master kunitconversion - Branch master kcompletion - Branch master qt5 - Branch stable kparts - Branch master extra-cmake-modules - Branch master kwidgetsaddons - Branch master solid - Branch master kcrash - Branch master kdoctools - Branch master kjobwidgets - Branch master knotifications - Branch master ktextwidgets - Branch master kconfig - Branch master threadweaver - Branch master kservice - Branch master kdnssd-framework - Branch master kactivities - Branch frameworks karchive - Branch master kjs - Branch master kwindowsystem - Branch master kdbusaddons - Branch master kbookmarks - Branch master kcoreaddons - Branch master kio - Branch master kcodecs - Branch master kdesupport-svn - Branch master sonnet - Branch master kidletime - Branch master kitemviews - Branch master kauth - Branch master polkit-qt-1 - Branch qt5 kross - Branch master kxmlgui - Branch master kdeclarative - Branch master ki18n - Branch master cmake - Branch master kitemmodels - Branch master kiconthemes - Branch master kwallet - Branch master kconfigwidgets - Branch master kglobalaccel - Branch master == 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 -- Found PkgConfig: /usr/bin/pkg-config (found version 0.27.1) -- Found XCB_XCB: /usr/lib64/libxcb.so (found version 1.9) -- Found XCB_COMPOSITE: /usr/lib64/libxcb-composite.so (found version 1.9) -- Found XCB_DAMAGE: /usr/lib64/libxcb-damage.so (found version 1.9) -- Found XCB_SHAPE: /usr/lib64/libxcb-shape.so (found version 1.9) -- Found XCB: /usr/lib64/libxcb.so;/usr/lib64/libxcb-composite.so;/usr/lib64/libxcb-damage.so;/usr/lib64/libxcb-shape.so (found version 1.9) found components: XCB COMPOSITE DAMAGE SHAPE -- 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 -- Found OpenGL: /usr/lib64/libGL.so -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -
Re: KItemModels, Solid KJS licenses
On 20/02/14 11:41, Alex Merry wrote: [1] https://build.opensuse.org/request/show/223061 KItemModels kcheckableproxymodel.(cpp|h) is Stephen Kelly (and, for safety, David Faure). Changed. modeltest.(cpp|h) were taken from Qt Concurrent, and subsequently modified by Stephen Kelly, and touched by David Faure and Aurélien Gâteau (but I don't think the latter two count as copyright holders, judging from the commit messages). So we can't just relicense this, because it is forked from a GPL-only file, and Digia have only public LGPL-licensed a later version of it. Just dropping in the new (LGPLv2.1) file seems to work, though. That, however, means that this code is LGPLv2, rather than LGPLv2+. David is on record as being happy with relicensing to LGPLv2+ (with or without the e.V. clause) - see relicensecheck.pl in kde:kde-dev-scripts. [1] https://build.opensuse.org/request/show/223093 KJS propertydescriptor.(cpp|h) is Bernd Buschinski. Possibly also David Faure (although, as already noted, David's code is not an issue). git log runs out early, though, so more investigation might be needed. Changed. [1] https://build.opensuse.org/request/show/223081 Solid predicate_parser.(c|h) are false positives (Bison-generated; the skeleton has a license exception). other files: Ivan Čukić. Touched by me (not enough for me to hold any copyright, though) and Volker Krause (arguably the same, but he's on record as being happy with LGPLv2+ anyway, although without the e.V. clause). Still waiting. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116096: Re-enable autotests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116096/ --- 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: KItemModels, Solid KJS licenses
hi, I confirm that I would be happy to the files listed below relicensed from GPL to LGPLv2+. Seriously, I don't really care that much if its gpl or lgpl, as long as its available for everyone who want to improve it ; Or ,if possible, I would relicense it to LGPLv2+ beer license, but sadly they are incompatible ;-) 2014-02-26 15:27 GMT+01:00 šumski hrvoje.sen...@gmail.com: On Thursday 20 of February 2014 11:41:48 Alex Merry wrote: CC'd people: please can you confirm that you would be happy to have the files listed below relicensed from GPL to LGPLv2+? Small ping :) It would be awesome if we could get this sorted for alpha2 Cheers, Hrvoje ___ 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
Review Request 116098: Use KDEInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- Review request for KDE Frameworks. 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 115984: Implement the d-pointer in KCompletionBase as in the other classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115984/ --- (Updated Feb. 26, 2014, 9:05 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcompletion Description --- Implement the d-pointer in KCompletionBase as in the other classes Add two methods: setEmitSignals(bool) and setKeybindingsMap(KeyBindingMap) to be called from setDelegate(). Otherwise, it doesn't seem plausible to reach the private member variables like this (the compiler complains): delegate-d-emitsRotationSignals = d-emitsRotationSignals; Now that has become: delegate-setEmitSignals(d-emitsRotationSignals); For coherence, implement the QScopedPointer and the init() method. Diffs - src/kcompletionbase.h 105a6d0 src/kcompletionbase.cpp 66f9398 Diff: https://git.reviewboard.kde.org/r/115984/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 115984: Implement the d-pointer in KCompletionBase as in the other classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115984/#review50984 --- This review has been submitted with commit 3698faa2c1f2164a28e754b4defe8edbc68b774b by David Gil to branch master. - Commit Hook On Feb. 24, 2014, 12:06 a.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115984/ --- (Updated Feb. 24, 2014, 12:06 a.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Implement the d-pointer in KCompletionBase as in the other classes Add two methods: setEmitSignals(bool) and setKeybindingsMap(KeyBindingMap) to be called from setDelegate(). Otherwise, it doesn't seem plausible to reach the private member variables like this (the compiler complains): delegate-d-emitsRotationSignals = d-emitsRotationSignals; Now that has become: delegate-setEmitSignals(d-emitsRotationSignals); For coherence, implement the QScopedPointer and the init() method. Diffs - src/kcompletionbase.h 105a6d0 src/kcompletionbase.cpp 66f9398 Diff: https://git.reviewboard.kde.org/r/115984/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 116062: Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116062/ --- (Updated Feb. 26, 2014, 9:09 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches for coherence with the other KCompletion classes. Diffs - src/kcompletionbox.h 8ed2b00 src/kcompletionbox.cpp 571b02f src/kcompletionmatches.h 481a4b9 src/kcompletionmatches.cpp bc381b1 Diff: https://git.reviewboard.kde.org/r/116062/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 116062: Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116062/#review50985 --- This review has been submitted with commit 6a810298e56c2b1cc9ee129073867a5ad2bd3f4d by David Gil to branch master. - Commit Hook On Feb. 25, 2014, 10:35 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116062/ --- (Updated Feb. 25, 2014, 10:35 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private slots in KCompletionBox and modify d-pointer in KCompletionMatches for coherence with the other KCompletion classes. Diffs - src/kcompletionbox.h 8ed2b00 src/kcompletionbox.cpp 571b02f src/kcompletionmatches.h 481a4b9 src/kcompletionmatches.cpp bc381b1 Diff: https://git.reviewboard.kde.org/r/116062/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 116056: Port to Qt5 and Kf5 of dnssd ioslave and kded module
On Feb. 26, 2014, 12:07 p.m., Alex Merry wrote: ioslave/CMakeLists.txt, line 9 https://git.reviewboard.kde.org/r/116056/diff/1/?file=246123#file246123line9 I found I needed to link against KF5::I18n; I wonder why you didn't? The problem is in KIO (/home/mgallien/kde/include/KF5/KIOCore/kio/slavebase.h) and not in kdnssd. I have a review request to do for kio to fix that. On Feb. 26, 2014, 12:07 p.m., Matthieu Gallien wrote: Thanks for doing this work, and sorry for not using it! In terms of what to do instead, I suggest one of: - look into porting things in kde-runtime (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization) - the reduce mentions of kde 4 in source code task from http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation#Tasks_for_Final_Release - look for todos and warnings in the frameworks to resolve If you want more pointers, I and other frameworks folks are usually hanging around on #kde-devel on irc, and there's the kde-frameworks-devel email list. Do not worry. I only have very limited free time and cannot make any promises. This is why I avoid talking about things before finishing them. - Matthieu --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116056/#review50915 --- On Feb. 25, 2014, 9:02 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116056/ --- (Updated Feb. 25, 2014, 9:02 p.m.) Review request for KDE Frameworks. Repository: kdnssd Description --- Basic port to Qt5 and Kf5 in order to help the merge of the two kdnssd repositories. Diffs - CMakeLists.txt df842d4 ioslave/CMakeLists.txt 40c2d67 ioslave/dnssd.h 89afd8d ioslave/dnssd.cpp c0c8ada ioslave/zeroconfurl.h f4f06de kdedmodule/CMakeLists.txt 6232940 kdedmodule/dnssdwatcher.h a2062fc kdedmodule/dnssdwatcher.cpp 2e4dc25 kdedmodule/watcher.h 5d5470b kdedmodule/watcher.cpp 21018b9 Diff: https://git.reviewboard.kde.org/r/116056/diff/ Testing --- Not much. I do not know how to test the ioslave without something like dolphin. Thanks, Matthieu Gallien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116056: Port to Qt5 and Kf5 of dnssd ioslave and kded module
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116056/ --- (Updated Feb. 26, 2014, 10:39 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kdnssd Description --- Basic port to Qt5 and Kf5 in order to help the merge of the two kdnssd repositories. Diffs - CMakeLists.txt df842d4 ioslave/CMakeLists.txt 40c2d67 ioslave/dnssd.h 89afd8d ioslave/dnssd.cpp c0c8ada ioslave/zeroconfurl.h f4f06de kdedmodule/CMakeLists.txt 6232940 kdedmodule/dnssdwatcher.h a2062fc kdedmodule/dnssdwatcher.cpp 2e4dc25 kdedmodule/watcher.h 5d5470b kdedmodule/watcher.cpp 21018b9 Diff: https://git.reviewboard.kde.org/r/116056/diff/ Testing --- Not much. I do not know how to test the ioslave without something like dolphin. Thanks, Matthieu Gallien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/ --- 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
kdesrc-build: stop after failure? --truly-verbose?
Hey, not sure this is the right list. I noticed that kdesrc-build happily continues building even when a module failed to build. Is this desired? I find it highly unintuitive, esp. as most modules failing at the beginning will mean all following modules will fail as well if they depend on said module. Couldn't instead the _full_ error log be cat'ed and the build stopped? Now, I have to hunt down the error log manually which is really cumbersome. If others think this behavior is good, could I vote for an additional cli argument to stop after any failure? Also, while at it, could we get a truly verbose flag, which actually outputs the output from whatever tool is currently running? For me as a developer, its really annoying having to tail -f on some random log files to get my hands on the make output... How are other developers handling this? Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
clang fails to build khtml
Hey all,
apparently noone is trying to build khtml with clang. I spotted this one:
src/misc/AtomicString.cpp:175:28: error: non-constant-expression
cannot be narrowed from type 'int' to 'unsigned int' in initializer
list [-Wc++11-narrowing]
UCharBuffer buf = { s, length };
^~
src/misc/AtomicString.cpp:175:28: note: override this message by
inserting an explicit cast
UCharBuffer buf = { s, length };
^~
static_castunsigned int( )
Which seems easy enough to fix. I'll put it up on review board.
But what about this:
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, KJS::DontDelete|KJS::ReadOnly, 0,
0 } ,
^
static_castint()
this actually sounds pretty dangerous to me. Anyone with knowledge around who
knows what to do here?
There are also tons of warnings like this:
src/xml/dom_stringimpl.h:60:13: warning: cast from 'char *' to 'QChar *'
increases required alignment from 1 to 2 [-Wcast-align]
s = (QChar*) new char[ sizeof(QChar)*( havestr ? len : 1 ) ];
^~~~
These can afaik also be fixed by using explicit static_casts. Is that OK?
What about this one:
src/frameworks/khtml/src/imload/decoders/jpegloader.cpp:430:29: warning: cast
from 'uchar *' (aka 'unsigned char *') to 'QRgb *' (aka 'unsigned int *')
increases required alignment from 1 to 4 [-Wcast-align]
QRgb *out = (QRgb *)scanline;
^~~~
Bye
--
Milian Wolff
m...@milianw.de
http://milianw.de
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
qt5 polkit-qt-1 and kdesrc-build
Hey all, I today sat down trying to finally get a KF5 kdesrc-build setup done. After lots of issues related to missing dependencies not listed (fixed now) on techbase, I hit an issue with kauth, namely that it tried to build agains tthe _qt4_ version of polkit-1. Can/should this not be forbidden on the cmake level? Furthermore, why is the default dfaure-approved kdesrc-build setup not building polkit-1 in the qt5 branch? I now fixed it locally by adding something like this to my local setup: module-set repository kde-projects branch qt5 use-modules polkit-qt-1 cmake-options -DCMAKE_BUILD_TYPE:STRING=debug end module-set Considering that all other people should hit the same issue - how did you resolve this? Can we get the above into the default configuration somehow please? Thanks -- Milian Wolff m...@milianw.de http://milianw.de ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
On Wed, Feb 26, 2014 at 10:30 PM, Milian Wolff m...@milianw.de wrote: Hey, not sure this is the right list. I noticed that kdesrc-build happily continues building even when a module failed to build. Is this desired? I find it highly unintuitive, esp. as most modules failing at the beginning will mean all following modules will fail as well if they depend on said module. Couldn't instead the _full_ error log be cat'ed and the build stopped? Now, I have to hunt down the error log manually which is really cumbersome. If others think this behavior is good, could I vote for an additional cli argument to stop after any failure? Also, while at it, could we get a truly verbose flag, which actually outputs the output from whatever tool is currently running? For me as a developer, its really annoying having to tail -f on some random log files to get my hands on the make output... How are other developers handling this? Bye I personally kinda like that it continues building if a module failed. ___ 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
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/#review50988 --- have you tried removing the include? - Albert Astals Cid On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/ --- (Updated Feb. 26, 2014, 9:44 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
Build failed in Jenkins: plasma-framework_master_qt5 » All,LINBUILDER #77
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/77/changes Changes: [notmart] add a building version of interactive console [notmart] port Package usage [notmart] instantiate the console [notmart] restore loadScriptInInteractiveConsole() [notmart] port away of kdialog [notmart] use a QFileDialog [notmart] remove klocale [notmart] remove KStandardDirs [notmart] remove KTextBrowser [notmart] remove KIcon [notmart] remove kcomponentdata [notmart] add copyright [notmart] initialize variabiles -- Started by upstream project plasma-framework_master_qt5 build number 77 originally caused by: Started by user Ben Cooksley Building remotely on LinuxSlave - 1 in workspace http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson5476176340929197835.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 1fd741b Merge branch 'mart/interactiveconsole' Removing build/ Success build forhudson.tasks.Shell@79ad89b4 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision 1fd741b5d30929d18311c050cf3aa1d080088ab5 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson2588774974872486564.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: knotifications - Branch master extra-cmake-modules - Branch master kservice - Branch master ki18n - Branch master polkit-qt-1 - Branch qt5 kparts - Branch master kcrash - Branch master sonnet - Branch master kunitconversion - Branch master kjs - Branch master ktextwidgets - Branch master kconfigwidgets - Branch master cmake - Branch master kitemmodels - Branch master kauth - Branch master threadweaver - Branch master kio - Branch master kdeclarative - Branch master karchive - Branch master kcoreaddons - Branch master kconfig - Branch master solid - Branch master kiconthemes - Branch master kdoctools - Branch master kdnssd-framework - Branch master kglobalaccel - Branch master kdbusaddons - Branch master kross - Branch master kguiaddons - Branch master kxmlgui - Branch master kbookmarks - Branch master kidletime - Branch master qt5 - Branch stable kwindowsystem - Branch master kcodecs - Branch master kwidgetsaddons - Branch master kdesupport-svn - Branch master kjobwidgets - Branch master kwallet - Branch master kactivities - Branch frameworks kcompletion - Branch master kitemviews - Branch master == 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 -- Found PkgConfig: /usr/bin/pkg-config (found version 0.27.1) -- Found XCB_XCB: /usr/lib64/libxcb.so (found version 1.9) -- Found XCB_COMPOSITE: /usr/lib64/libxcb-composite.so (found version 1.9) -- Found XCB_DAMAGE: /usr/lib64/libxcb-damage.so (found version 1.9) -- Found XCB_SHAPE: /usr/lib64/libxcb-shape.so (found version 1.9) -- Found XCB: /usr/lib64/libxcb.so;/usr/lib64/libxcb-composite.so;/usr/lib64/libxcb-damage.so;/usr/lib64/libxcb-shape.so (found version 1.9) found components: XCB COMPOSITE DAMAGE SHAPE -- Found OpenGL: /usr/lib64/libGL.so -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test
Build failed in Jenkins: plasma-framework_master_qt5 » NoX11,LINBUILDER #77
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/77/changes Changes: [notmart] add a building version of interactive console [notmart] port Package usage [notmart] instantiate the console [notmart] restore loadScriptInInteractiveConsole() [notmart] port away of kdialog [notmart] use a QFileDialog [notmart] remove klocale [notmart] remove KStandardDirs [notmart] remove KTextBrowser [notmart] remove KIcon [notmart] remove kcomponentdata [notmart] add copyright [notmart] initialize variabiles -- Started by upstream project plasma-framework_master_qt5 build number 77 originally caused by: Started by user Ben Cooksley Building remotely on LinuxSlave - 4 in workspace http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/ Running Prebuild steps [LINBUILDER] $ /bin/sh -xe /tmp/hudson6524306697976083910.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 1fd741b Merge branch 'mart/interactiveconsole' Removing build/ Success build forhudson.tasks.Shell@79ad89b4 Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/plasma-framework.git Checking out Revision 1fd741b5d30929d18311c050cf3aa1d080088ab5 (refs/heads/jenkins) [LINBUILDER] $ /bin/sh -xe /tmp/hudson6950058343279702182.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: plasma-framework - Branch master == Build Dependencies: kdesupport-svn - Branch master kconfigwidgets - Branch master extra-cmake-modules - Branch master kservice - Branch master kiconthemes - Branch master polkit-qt-1 - Branch qt5 sonnet - Branch master kcrash - Branch master kdeclarative - Branch master cmake - Branch master kjs - Branch master ktextwidgets - Branch master kparts - Branch master kitemmodels - Branch master karchive - Branch master kidletime - Branch master threadweaver - Branch master kjobwidgets - Branch master kxmlgui - Branch master kauth - Branch master kcoreaddons - Branch master kross - Branch master kdnssd-framework - Branch master solid - Branch master ki18n - Branch master kdoctools - Branch master kglobalaccel - Branch master kdbusaddons - Branch master kguiaddons - Branch master kbookmarks - Branch master kcompletion - Branch master qt5 - Branch stable kunitconversion - Branch master kwindowsystem - Branch master kcodecs - Branch master kwidgetsaddons - Branch master kconfig - Branch master kio - Branch master kwallet - Branch master kactivities - Branch frameworks knotifications - Branch master kitemviews - Branch master == 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 -- Found PkgConfig: /usr/bin/pkg-config (found version 0.27.1) -- Found XCB_XCB: /usr/lib64/libxcb.so (found version 1.9) -- Found XCB_COMPOSITE: /usr/lib64/libxcb-composite.so (found version 1.9) -- Found XCB_DAMAGE: /usr/lib64/libxcb-damage.so (found version 1.9) -- Found XCB_SHAPE: /usr/lib64/libxcb-shape.so (found version 1.9) -- Found XCB: /usr/lib64/libxcb.so;/usr/lib64/libxcb-composite.so;/usr/lib64/libxcb-damage.so;/usr/lib64/libxcb-shape.so (found version 1.9) found components: XCB COMPOSITE DAMAGE SHAPE -- 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 -- Found OpenGL: /usr/lib64/libGL.so -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY -- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success -- Performing Test COMPILER_HAS_DEPRECATED_ATTR -- Performing Test
Build failed in Jenkins: plasma-framework_master_qt5 » All,LINBUILDER #78
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/78/ -- [...truncated 620 lines...] Scanning dependencies of target plasma_dataengine_example_sourcesOnRequest Scanning dependencies of target plasmapkg2 Scanning dependencies of target plasma_dataengine_example_simpleEngine [ 42%] [ 42%] Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/main.cpp.o Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/sourcesOnRequest.cpp.o [ 43%] Building CXX object examples/dataengines/simpleEngine/CMakeFiles/plasma_dataengine_example_simpleEngine.dir/simpleEngine.cpp.o Scanning dependencies of target plasmacomponentsplugin Scanning dependencies of target plasmaextracomponentsplugin [ 44%] Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/plasmacomponentsplugin.cpp.o [ 45%] Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/appbackgroundprovider.cpp.o [ 46%] Scanning dependencies of target sortfiltermodeltest [ 47%] Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/plasmapkg.cpp.o Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/plasma_dataengine_example_sourcesOnRequest_automoc.cpp.o [ 48%] Scanning dependencies of target qtextracomponentsplugin Building CXX object src/declarativeimports/core/tests/CMakeFiles/sortfiltermodeltest.dir/sortfiltermodeltest.cpp.o [ 49%] Building CXX object src/declarativeimports/qtextracomponents/CMakeFiles/qtextracomponentsplugin.dir/qtextracomponentsplugin.cpp.o Scanning dependencies of target KF5PlasmaQuick Linking CXX shared module plasma_dataengine_example_sourcesOnRequest.so [ 49%] [ 49%] Building CXX object src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/appletquickitem.cpp.o Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/plasmaextracomponentsplugin.cpp.o [ 49%] Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/qrangemodel.cpp.o [ 50%] Building CXX object src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/view.cpp.o http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/plasmaextracomponents/plasmaextracomponentsplugin.cpp:33:6: warning: unused parameter ‘uri’ [-Wunused-parameter] [ 50%] Built target plasma_dataengine_example_sourcesOnRequest [ 51%] [ 51%] [ 52%] [ 53%] Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/fallbackcomponent.cpp.o Building CXX object src/declarativeimports/qtextracomponents/CMakeFiles/qtextracomponentsplugin.dir/qpixmapitem.cpp.o Building CXX object src/declarativeimports/qtextracomponents/CMakeFiles/qtextracomponentsplugin.dir/qimageitem.cpp.o Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/enums.cpp.o http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:617:14: warning: #warning read config here [-Wcpp] http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:484:9: warning: unused parameter ‘pluginName’ [-Wunused-parameter] http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:484:9: warning: unused parameter ‘prefix’ [-Wunused-parameter] http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp: In member function ‘void Plasma::PlasmaPkgPrivate::listTypes()’: http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:593:37: warning: ‘KPluginInfo::KPluginInfo(KService::Ptr)’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kservice/inst/include/KF5/KService/kplugininfo.h:114) [-Wdeprecated-declarations] Scanning dependencies of target corebindingsplugin [ 53%] Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/plasmapkg2_automoc.cpp.o [ 53%] [ 54%] Building CXX object examples/dataengines/simpleEngine/CMakeFiles/plasma_dataengine_example_simpleEngine.dir/plasma_dataengine_example_simpleEngine_automoc.cpp.o Building CXX object src/declarativeimports/core/CMakeFiles/corebindingsplugin.dir/corebindingsplugin.cpp.o [ 54%] Building CXX object src/declarativeimports/core/CMakeFiles/corebindingsplugin.dir/datamodel.cpp.o Linking CXX executable plasmapkg2 [ 54%] Building CXX object src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/configmodel.cpp.o http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/ws/src/declarativeimports/qtextracomponents/qpixmapitem.cpp: In member function
Build failed in Jenkins: plasma-framework_master_qt5 » NoX11,LINBUILDER #78
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/78/ -- [...truncated 618 lines...] [ 42%] Scanning dependencies of target plasmapkg2 Scanning dependencies of target plasmaextracomponentsplugin Building CXX object examples/dataengines/simpleEngine/CMakeFiles/plasma_dataengine_example_simpleEngine.dir/simpleEngine.cpp.o [ 42%] [ 43%] Scanning dependencies of target plasmacomponentsplugin Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/appbackgroundprovider.cpp.o Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/main.cpp.o [ 43%] Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/plasmacomponentsplugin.cpp.o [ 44%] Scanning dependencies of target sortfiltermodeltest [ 44%] Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/plasmaextracomponentsplugin.cpp.o Scanning dependencies of target plasma_dataengine_example_sourcesOnRequest [ 45%] Building CXX object examples/dataengines/simpleEngine/CMakeFiles/plasma_dataengine_example_simpleEngine.dir/plasma_dataengine_example_simpleEngine_automoc.cpp.o [ 46%] Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/plasmapkg.cpp.o Building CXX object src/declarativeimports/core/tests/CMakeFiles/sortfiltermodeltest.dir/sortfiltermodeltest.cpp.o [ 47%] Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/qrangemodel.cpp.o [ 48%] Scanning dependencies of target qtextracomponentsplugin http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/plasmaextracomponents/plasmaextracomponentsplugin.cpp:33:6: warning: unused parameter ‘uri’ [-Wunused-parameter] Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/sourcesOnRequest.cpp.o Linking CXX shared module plasma_dataengine_example_simpleEngine.so [ 49%] [ 50%] Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/fallbackcomponent.cpp.o Scanning dependencies of target KF5PlasmaQuick [ 50%] Building CXX object src/declarativeimports/qtextracomponents/CMakeFiles/qtextracomponentsplugin.dir/qtextracomponentsplugin.cpp.o Building CXX object src/declarativeimports/core/tests/CMakeFiles/sortfiltermodeltest.dir/__/__/__/plasma/dataengineconsumer.cpp.o [ 50%] Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/enums.cpp.o [ 51%] [ 51%] Building CXX object src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/appletquickitem.cpp.o http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:617:14: warning: #warning read config here [-Wcpp] http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:484:9: warning: unused parameter ‘pluginName’ [-Wunused-parameter] http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:484:9: warning: unused parameter ‘prefix’ [-Wunused-parameter] http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp: In member function ‘void Plasma::PlasmaPkgPrivate::listTypes()’: http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/plasmapkg/plasmapkg.cpp:593:37: warning: ‘KPluginInfo::KPluginInfo(KService::Ptr)’ is deprecated (declared at /srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kservice/inst/include/KF5/KService/kplugininfo.h:114) [-Wdeprecated-declarations] Building CXX object src/declarativeimports/plasmaextracomponents/CMakeFiles/plasmaextracomponentsplugin.dir/plasmaextracomponentsplugin_automoc.cpp.o [ 52%] [ 52%] [ 52%] Building CXX object src/plasmapkg/CMakeFiles/plasmapkg2.dir/plasmapkg2_automoc.cpp.o [ 52%] Building CXX object src/declarativeimports/core/tests/CMakeFiles/sortfiltermodeltest.dir/__/datamodel.cpp.o Building CXX object examples/dataengines/sourcesOnRequest/CMakeFiles/plasma_dataengine_example_sourcesOnRequest.dir/plasma_dataengine_example_sourcesOnRequest_automoc.cpp.o Building CXX object src/declarativeimports/qtextracomponents/CMakeFiles/qtextracomponentsplugin.dir/qpixmapitem.cpp.o [ 53%] Linking CXX executable plasmapkg2 Building CXX object src/declarativeimports/plasmacomponents/CMakeFiles/plasmacomponentsplugin.dir/qmenu.cpp.o [ 53%] Building CXX object src/plasmaquick/CMakeFiles/KF5PlasmaQuick.dir/view.cpp.o http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/ws/src/declarativeimports/qtextracomponents/qpixmapitem.cpp: In member function ‘virtual void QPixmapItem::paint(QPainter*)’:
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote: have you tried removing the include? Ignore me, there's i18n calls in there :D - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/#review50988 --- On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/ --- (Updated Feb. 26, 2014, 9:44 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
Jenkins build is back to normal : plasma-framework_master_qt5 » All,LINBUILDER #79
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/79/ ___ 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 : plasma-framework_master_qt5 » NoX11,LINBUILDER #79
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=NoX11,label=LINBUILDER/79/ ___ 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 Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote: have you tried removing the include? Albert Astals Cid wrote: Ignore me, there's i18n calls in there :D However, I wonder if those calls should really be in the header. I have no idea what catalogue they will use at runtime; I suspect it will depend on whether code that includes the header defined TRANSLATION_DOMAIN and where, exactly, they do so. A better solution (SC but not BC) is probably to create overloaded methods and put those calls in the cpp file. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/#review50988 --- On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116103/ --- (Updated Feb. 26, 2014, 9:44 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: [kde-doc-english] Core documentation repository (was: Review Request 116038: replace old included sections with links to fundamentals)
Hi frameworks devs! We thought we'd solicit some input from you all on this as well. On Wed, Feb 26, 2014 at 3:52 PM, Luigi Toscano luigi.tosc...@tiscali.it wrote: T.C. Hollingsworth wrote: On Tue, Feb 25, 2014 at 4:38 AM, Luigi Toscano luigi.tosc...@tiscali.it wrote: I'm not sure if it enough: what if fundamentals is not installed? kde-runtime as we knows is going away. Maybe we should rethink how it works. Well then we probably should figure out a way to make sure it's always installed. :-) We're already linking to it heavily from other docbooks and the approach really makes a lot of things easier for the documentation team. And here is... the difficult part :) Well, it means they should be moved to some place which is always available when documentation is shipped with some module We can't just ship it with Plasma, since fundamentals is deliberately designed to be useful/relevant to people using KDE applications in other environments too. (e.g. people using Kate on GNOME probably still want to edit their keybindings, and kate just links to the excellent shortcut configuration documentation in fundamentals). Exactly. It should be pushed down in the stack. Also, kio help:/ requires the documentationnotfound docbook to display as sort of a 404 error, so that needs to be universally available too. So documentationnotfound docbook should be moved together with kio-help. We could ship them with khelpcenter, but there's no guarantee that that will always be the primary frontend to the help:/ kioslave, so it seems like it would be nicer to find a more general home that ensures it works no matter what you're using to browse help:/ URLs. Mhh.. that's true, so it should be in some level which is lower than kio-help. So, perhaps we need a kde-core-docs.git or something like that to house them in? And advise distros to make sure and add runtime Requires on it from kdoctools or whereever the help: kioslave is shipped? (Alternatively we could just include them in kdoctools.git, but there might be a bit of a chicken and egg problem keeping docbooks there?) Technically there is already some documentation in kdoctools, exactly as we had it kdelibs, so it could be included here. Do you want to raise the question on kde-frameworks-devel? I would like to hear from the other people in the list too. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-doc-english] Core documentation repository (was: Review Request 116038: replace old included sections with links to fundamentals)
On Wed, Feb 26, 2014 at 3:52 PM, Luigi Toscano luigi.tosc...@tiscali.it wrote: T.C. Hollingsworth wrote: Also, kio help:/ requires the documentationnotfound docbook to display as sort of a 404 error, so that needs to be universally available too. So documentationnotfound docbook should be moved together with kio-help. Yeah that actually makes more sense than shipping it where fundamentals goes. It's just an implementation detail of the help kioslave and not core to how our documentation is presented/assembled like fundamentals is. We could ship them with khelpcenter, but there's no guarantee that that will always be the primary frontend to the help:/ kioslave, so it seems like it would be nicer to find a more general home that ensures it works no matter what you're using to browse help:/ URLs. Mhh.. that's true, so it should be in some level which is lower than kio-help. Hmm, because the help kioslave might get replaced too? That seems significantly less likely, but kdoctools/something near it makes more sense to me anyway so why not? So, perhaps we need a kde-core-docs.git or something like that to house them in? And advise distros to make sure and add runtime Requires on it from kdoctools or whereever the help: kioslave is shipped? (Alternatively we could just include them in kdoctools.git, but there might be a bit of a chicken and egg problem keeping docbooks there?) Technically there is already some documentation in kdoctools, exactly as we had it kdelibs, so it could be included here. Oh yeah, d'oh! :-) In that case I'm fine with just keeping it in kdoctools if that works for everyone else. -T.C. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: building Solid
On Wed, February 26, 2014 13:51:52 Dominik Haumann wrote: PS: It's never (!) a good idea to add a custom type that has Q* naming style. It leads to totally unnecessary issues like this one ;) I agree completely with this. If we add a typedef it should always be with a symbol under our own namespace if it's at all possible (and it's almost always possible). This kind of thing happens to us every so often and it's always avoidable by naming things correctly. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities5 build failure
On Wed, February 26, 2014 14:54:37 Ivan Čukić wrote: Qt5.3? It fails for me as well with the same error. Yes, Qt 5.3. I'm not going to be able to deal with Qt 5.3 until next version of plasma is released since we are tiesd to 5.2. If anyone provides a patch, it would be appreciated. According to the Qt commit log by Kai, the workaround appears to be people should always have been using filter rules for this anyways. I resorted to simply ifdeffing the offending lines of code out here locally and things work great (if by work I mean compile ;) Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
On Wed, February 26, 2014 22:30:48 Milian Wolff wrote:
Hey,
not sure this is the right list. I noticed that kdesrc-build happily
continues building even when a module failed to build. Is this desired?
Yes, it's on purpose. The idea is that most people are not building KDE for
the first time and don't need to have the whole compile aborted because mpyne
committed a fail-to-build bug in juk or something.
Couldn't instead the _full_ error log be cat'ed and the build stopped? Now,
I have to hunt down the error log manually which is really cumbersome. If
others think this behavior is good, could I vote for an additional cli
argument to stop after any failure?
Yes, kdesrc-build can do (most) of this. I thought I documented it as a
command line option but it turns out that it was a kdesrc-buildrc option.
But you can still reach it via command line by passing --stop-on-failure=1
As far as the error log file, its location gets output at the end (which will
be very soon indeed if you pass --stop-on-failure), and I think dfaure might
still have an open bug about reporting the logfile location immediately upon
failure.
However, what I personally do is that I added a small bash function to my
.bashrc, errorLog, which does something like:
errorLog() {
$EDITOR ~/log-kdesrc-build/latest/$1/error.log
}
where ~/log-kdesrc-build should be wherever your log directory is (probably
$srcdir/log). kdesrc-build maintains symlinks throughout the log directory to
make it easy to find the last log set for a given module, and which log
contains the error if the module failed (i.e. if you see an error.log in a
specific log directory it means that module failed to build that run).
Also, while at it, could we get a truly verbose flag, which actually
outputs the output from whatever tool is currently running?
If you file a bug I'd probably implement it. --debug did this kind of thing
(it might even still do it, but it would be too annoying to use here). I say
file a bug only because it's guaranteed it'll drop off my plate otherwise.
For me as a
developer, its really annoying having to tail -f on some random log files
to get my hands on the make output... How are other developers handling
this?
I just watch the percentages in the kdesrc-build output personally. When I'm
doing development I don't use kdesrc-build at all; I still retain my 'cs' and
'cb' shell macros to switch between individual source/build dirs as needed and
manually do my git-fu and make-n-shake so that I can see compiler warnings.
I'm sorry if it's been annoying to use but I'm always open to improvements
(especially improvements with patches, but no one else seems to like Perl...
;)
In the meantime there are other, better-documented, command line options which
are useful. Documentation is available at
http://kdesrc-build.kde.org/documentation/, and if you build kdesrc-build it
should install
a man page to $KDEDIR/share/man/man1 or thereabouts.
I've recently become a big fan of --resume-from (or -after), --stop-before (or
-after) and --ignore-modules options myself. And always --pretend.
Regards,
- Michael Pyne
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: clang fails to build khtml
On Wed, February 26, 2014 22:43:31 Milian Wolff wrote:
But what about this:
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, KJS::DontDelete|KJS::ReadOnly,
0, 0 } ,
^
static_castint()
this actually sounds pretty dangerous to me. Anyone with knowledge around
who knows what to do here?
I'm not sure of the type of DOM::NodeFilter::SHOW_ALL (Bernd or someone might
know better) but it certainly seems like SHOW_ALL is supposed to be a constant
equaling -1, which should be perfectly fine for an int.
What's probably happening is that the type is unsigned and SHOW_ALL is
declared as the moral equivalent of (unsigned)-1 and clang rightly complains
when trying to stuff that very large unsigned constant back into an int.
Makes me wonder if whatever this structure is can't simply use the right enum
type here instead of int.
There are also tons of warnings like this:
src/xml/dom_stringimpl.h:60:13: warning: cast from 'char *' to 'QChar *'
increases required alignment from 1 to 2 [-Wcast-align]
s = (QChar*) new char[ sizeof(QChar)*( havestr ? len : 1 ) ];
^~~~
These can afaik also be fixed by using explicit static_casts. Is that OK?
Seems so. The standard I have says that static_cast is defined as long as
the alignment is compatible, and it also says that new for arrays must return
memory properly aligned for any object which could fit in the whole array,
explicitly for this use case.
What about this one:
src/frameworks/khtml/src/imload/decoders/jpegloader.cpp:430:29: warning:
cast from 'uchar *' (aka 'unsigned char *') to 'QRgb *' (aka 'unsigned int
*') increases required alignment from 1 to 4 [-Wcast-align]
QRgb *out = (QRgb *)scanline;
Even assuming the alignment is not correct here (which is unlikely here given
that the QRgb* seems to be going on multiples-of-4 here) then static_cast is
at worst unspecified, as opposed to undefined behavior where optimizers
start adding buffer overflows. So it still seems like the better answer here
unless we want to bring in some of those fancy image-swizzling graphics
libraries.
Regards,
- Michael Pyne
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Frameworks sprint: Register now!
Hello all, If you didn't yet, please register for the upcoming sprint: https://sprints.kde.org/sprint/224 Especially if you're not from Barcelona, it's necessary for budgeting the sprint, booking the accommodation, etc. The guys in Barcelona are kind enough to host us, so please let's be nice guests and make their job easier. :-) 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 115739: Make UDSEntry a Q_MOVABLE type, and add some benchmarks and tests
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115739/#review51000
---
This review has been submitted with commit
c8168fe82ee26af0ec049e823501929470e0b032 by Frank Reininghaus to branch master.
- Commit Hook
On Feb. 13, 2014, 8:23 p.m., Frank Reininghaus wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115739/
---
(Updated Feb. 13, 2014, 8:23 p.m.)
Review request for KDE Frameworks and David Faure.
Repository: kio
Description
---
I'm continuing my efforts to make UDSEntry more efficient, which were started
in https://git.reviewboard.kde.org/r/113591/. This is the second step, and
I'll probably do more in the future, for which I will split
https://git.reviewboard.kde.org/r/113355/ into independent parts.
This patch contains the following changes (which are separate commits):
1. Make UDSEntry a Q_MOVABLE type. This has the effect that a QListUDSEntry
a.k.a. UDSEntryList will store the actual entries in a single allocated block
of memory, and not pointers to UDSEntries which are allocated individually on
the heap (this means that this change is binary incompatible). This reduces
the memory usage by 32 bytes per UDSEntry in a QList because each memory
allocation uses at least 32 bytes on a 64-bit system.
This idea is similar to what I proposed for KFileItem in
https://git.reviewboard.kde.org/r/111789/. That one had to be reverted later
though because it turned out that KDirLister does rely on QListKFileItem
storing only pointers to the KFileItems. I'm confident that no such trouble
will happen for UDSEntry - all KIO unit tests still pass.
One could argue that we could simply use a UDSEntryVector instead of a
UDSEntyList to achieve the same memory savings, but considering that the list
is used quite frequently ( http://lxr.kde.org/ident?i=UDSEntryList ), this
might require a lot of porting work and cause other unexpected problems.
Note that I could not make the Q_DECLARE_TYPEINFO declaration work if it was
inside the KIO namespace, but I still preferred to do it immediately after
the class declaration, so I had to interrupt the namespace briefly.
2. Add some benchmarks to measure how long typical UDSEntry operations take:
add fields to an entry, read fields from an entry, store a UDSEntryList in a
QByteArray, and read it back from the QByteArray.
All measurements are done both for UDSEntries with 8 fields (this is a rather
typical use case because kio_file usually creates 8 fields), and for entries
with the maximum number of fields.
3. Add a simple manual test ('listjobtest') that runs a KIO::ListJob for a
given URL. This can be used to easily measure the memory usage of the
UDSEntryList that contains an entry for each file at that URL.
Diffs
-
src/core/udsentry.h 9550a7e
tests/CMakeLists.txt dbca6a5
tests/listjobtest.cpp PRE-CREATION
tests/udsentrybenchmark.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/115739/diff/
Testing
---
1. KIO unit tests still pass.
2. I've confirmed with the new 'listjobtest' and KSysGuard that the memory
usage is really lowered by 32 bytes per item in a UDSEntryList.
3. The benchmark results do not change significantly. I only tested it with a
debug build (i.e., with optimizations disabled) though, and I'm afraid I
might be lacking the resources to set up an additional build of Qt5 and all
of KF5 in release mode. However, since UDSEntry essentially only depends on
qtbase, I might be able to just do a release build of qtbase and build a
stand-alone version of UDSEntry+benchmarks on top of that. I'll look into
this option for getting reliable benchmark results when I work on further
improvements in the future.
Thanks,
Frank Reininghaus
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115739: Make UDSEntry a Q_MOVABLE type, and add some benchmarks and tests
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115739/
---
(Updated Feb. 27, 2014, 7:52 a.m.)
Status
--
This change has been marked as submitted.
Review request for KDE Frameworks and David Faure.
Repository: kio
Description
---
I'm continuing my efforts to make UDSEntry more efficient, which were started
in https://git.reviewboard.kde.org/r/113591/. This is the second step, and I'll
probably do more in the future, for which I will split
https://git.reviewboard.kde.org/r/113355/ into independent parts.
This patch contains the following changes (which are separate commits):
1. Make UDSEntry a Q_MOVABLE type. This has the effect that a QListUDSEntry
a.k.a. UDSEntryList will store the actual entries in a single allocated block
of memory, and not pointers to UDSEntries which are allocated individually on
the heap (this means that this change is binary incompatible). This reduces the
memory usage by 32 bytes per UDSEntry in a QList because each memory allocation
uses at least 32 bytes on a 64-bit system.
This idea is similar to what I proposed for KFileItem in
https://git.reviewboard.kde.org/r/111789/. That one had to be reverted later
though because it turned out that KDirLister does rely on QListKFileItem
storing only pointers to the KFileItems. I'm confident that no such trouble
will happen for UDSEntry - all KIO unit tests still pass.
One could argue that we could simply use a UDSEntryVector instead of a
UDSEntyList to achieve the same memory savings, but considering that the list
is used quite frequently ( http://lxr.kde.org/ident?i=UDSEntryList ), this
might require a lot of porting work and cause other unexpected problems.
Note that I could not make the Q_DECLARE_TYPEINFO declaration work if it was
inside the KIO namespace, but I still preferred to do it immediately after the
class declaration, so I had to interrupt the namespace briefly.
2. Add some benchmarks to measure how long typical UDSEntry operations take:
add fields to an entry, read fields from an entry, store a UDSEntryList in a
QByteArray, and read it back from the QByteArray.
All measurements are done both for UDSEntries with 8 fields (this is a rather
typical use case because kio_file usually creates 8 fields), and for entries
with the maximum number of fields.
3. Add a simple manual test ('listjobtest') that runs a KIO::ListJob for a
given URL. This can be used to easily measure the memory usage of the
UDSEntryList that contains an entry for each file at that URL.
Diffs
-
src/core/udsentry.h 9550a7e
tests/CMakeLists.txt dbca6a5
tests/listjobtest.cpp PRE-CREATION
tests/udsentrybenchmark.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/115739/diff/
Testing
---
1. KIO unit tests still pass.
2. I've confirmed with the new 'listjobtest' and KSysGuard that the memory
usage is really lowered by 32 bytes per item in a UDSEntryList.
3. The benchmark results do not change significantly. I only tested it with a
debug build (i.e., with optimizations disabled) though, and I'm afraid I might
be lacking the resources to set up an additional build of Qt5 and all of KF5 in
release mode. However, since UDSEntry essentially only depends on qtbase, I
might be able to just do a release build of qtbase and build a stand-alone
version of UDSEntry+benchmarks on top of that. I'll look into this option for
getting reliable benchmark results when I work on further improvements in the
future.
Thanks,
Frank Reininghaus
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
