Re: Review Request 113158: Implement queueing directly in KDialogJobUiDelegate
On Oct. 14, 2013, 9:05 a.m., Kevin Ottens wrote: I'm not sold on bastardizing QErrorMessage for that feature. The intent was more to have some code similar to what KDialogQueue (moved to KDE4Support) was doing directly in KDialogJobUiDelegate implementation. I'm surprised by this. Yes our initial idea was doing it in KF5, but if we can get what we need from Qt, isn't that even better? QErrorMessage has two features (queuing and dont-show-again checkbox), it makes sense to me to be able to use one and not the other. The only reason I can see where this Qt patch wouldn't be enough, would be if we need queueing of more complex dialogs than simple error messageboxes. But IIRC the only use case we have are the error messageboxes from KIO... right? - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113158/#review41683 --- On Oct. 31, 2013, 10:15 a.m., Rohan Garg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113158/ --- (Updated Oct. 31, 2013, 10:15 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Instead of implementing queueing in KDialogJobUiDelegate, I'm making use of QErrorMessage which has queueing built into it. We also inherit the Show this message again checkbox, but I have a review request here https://codereview.qt-project.org/67243 that adds new API to Qt 5.3 , so we can hide that once 5.3 comes out ( if that makes sense ). Diffs - staging/kjobwidgets/src/kdialogjobuidelegate.h 5d17a4d staging/kjobwidgets/src/kdialogjobuidelegate.cpp 29c2bae Diff: http://git.reviewboard.kde.org/r/113158/diff/ Testing --- Tested by writing a application that uses KIO to fetch an invalid site url. Dialog pops up just fine. Thanks, Rohan Garg ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
Hello, On Friday 01 November 2013 11:23:14 Mirko Boehm wrote: On 11/01/2013 10:46 AM, Alexander Neundorf wrote: [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its standard library I agree that a separation of CMake and the find_modules make sense. But. My position indeed. I would agree at a tier 0 if it didn't make it miserable for third parties wanting to use a tier 1 library in the sense of oh by the way you also need that, and that, and that thing no one else use. Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. This would also make a lot of things a lot easier. For example, nobody would need to separately install ECM, and updates to our ECM packages can be delivered globally by commits to that repo. Yep! 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
Build failed in Jenkins: kdelibs_frameworks_qt5 #1550
See http://build.kde.org/job/kdelibs_frameworks_qt5/1550/changes Changes: [mklapetek] Don't build UDisk backends if UDev libs weren't found [mklapetek] Don't print useless CMake variables while configuring KNewStuff3 -- [...truncated 611 lines...] httpheadertokenizetest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): cmake/modules/KDE4Macros.cmake:442 (kde4_handle_rpath_for_executable) cmake/modules/KDE4Macros.cmake:292 (kde4_add_executable) kioslave/http/tests/CMakeLists.txt:8 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:309 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpheadertokenizetest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): kioslave/http/tests/CMakeLists.txt:8 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:64 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpheaderdispositiontest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): cmake/modules/KDE4Macros.cmake:442 (kde4_handle_rpath_for_executable) cmake/modules/KDE4Macros.cmake:292 (kde4_add_executable) kioslave/http/tests/CMakeLists.txt:12 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:309 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpheaderdispositiontest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): kioslave/http/tests/CMakeLists.txt:12 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:64 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpauthenticationtest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): cmake/modules/KDE4Macros.cmake:442 (kde4_handle_rpath_for_executable) cmake/modules/KDE4Macros.cmake:292 (kde4_add_executable) kioslave/http/tests/CMakeLists.txt:16 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:309 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpauthenticationtest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): kioslave/http/tests/CMakeLists.txt:16 (kde4_add_unit_test) This warning is for project developers. Use -Wno-dev to suppress it. CMake Warning (dev) at cmake/modules/KDE4Macros.cmake:64 (get_target_property): Policy CMP0026 is not set: Disallow use of the LOCATION target property. Run cmake --help-policy CMP0026 for policy details. Use the cmake_policy command to set the policy and suppress this warning. The LOCATION property should not be read from target httpobjecttest. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. Call Stack (most recent call first): cmake/modules/KDE4Macros.cmake:442 (kde4_handle_rpath_for_executable) cmake/modules/KDE4Macros.cmake:292 (kde4_add_executable) kioslave/http/tests/CMakeLists.txt:23
Re: Review Request 113530: Adapt KDED to use DBus to communicate with KSplash
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113530/ --- (Updated Nov. 1, 2013, 12:37 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- The xatom interface was removed from KSplash and replaced with a DBus one. This makes kded use the DBus interface. Diffs (updated) - tier3/kded/src/kded.cpp a07c2fe Diff: http://git.reviewboard.kde.org/r/113530/diff/ Testing --- Works. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113530: Adapt KDED to use DBus to communicate with KSplash
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113530/ --- (Updated Nov. 1, 2013, 12:38 p.m.) Review request for KDE Frameworks. Changes --- Oops, wrong patch previously, sorry. Repository: kdelibs Description --- The xatom interface was removed from KSplash and replaced with a DBus one. This makes kded use the DBus interface. Diffs (updated) - tier3/kded/src/kded.cpp a07c2fe Diff: http://git.reviewboard.kde.org/r/113530/diff/ Testing --- Works. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013 12:53:17 Alexander Neundorf wrote: On Friday 01 November 2013, Kevin Ottens wrote: Hello, On Friday 01 November 2013 11:23:14 Mirko Boehm wrote: On 11/01/2013 10:46 AM, Alexander Neundorf wrote: [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its standard library I agree that a separation of CMake and the find_modules make sense. But. My position indeed. I would agree at a tier 0 if it didn't make it miserable for third parties wanting to use a tier 1 library in the sense of oh by the way you also need that, and that, and that thing no one else use. if a package foo uses ecm (or that non existing tier0 cmake package) itself, this does not mean that another package which uses foo, also needs ecm (or that tier0 package) at buildtime. Well, if the tier 0 package contains the compiler settings for our frameworks, it'd mean everything tier 1 and up would use it. The alternatives right now being: duplicate the info or have it in cmake/ecm. So far we chose the have it in cmake/ecm route. If we had what Mirko refers to, then that'd open the door to another solution. 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
Build failed in Jenkins: kdelibs_frameworks_qt5 #1551
See http://build.kde.org/job/kdelibs_frameworks_qt5/1551/changes Changes: [mklapetek] Fix build -- [...truncated 3538 lines...] [ 28%] Building CXX object tier1/kjs/src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/lexer.cpp.o [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/kxyselector.cpp.o [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/jobs/kjob.cpp.o [ 28%] Building CXX object tier1/kwindowsystem/src/CMakeFiles/KWindowSystem.dir/netwm.cpp.o [ 28%] Building CXX object tier2/ki18n/src/CMakeFiles/KI18n.dir/kuitmarkup.cpp.o [ 28%] Building CXX object tier1/kjs/src/kjs/CMakeFiles/icemaker.dir/bytecode/generator/parser.cpp.o [ 28%] Building CXX object tier1/kjs/src/kjs/CMakeFiles/icemaker.dir/icemaker_automoc.cpp.o [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/jobs/kjobtrackerinterface.cpp.o http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier1/kwindowsystem/src/netwm.cpp: In member function ‘void NETRootInfo::event(xcb_generic_event_t*, long unsigned int*, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier1/kwindowsystem/src/netwm.cpp:1933:44: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier1/kwindowsystem/src/netwm.cpp:1993:44: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier1/kwindowsystem/src/netwm.cpp: In member function ‘void NETWinInfo::event(xcb_generic_event_t*, long unsigned int*, int)’: http://build.kde.org/job/kdelibs_frameworks_qt5/ws/tier1/kwindowsystem/src/netwm.cpp:3765:44: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] [ 28%] Building CXX object tier1/kwindowsystem/src/CMakeFiles/KWindowSystem.dir/KWindowSystem_automoc.cpp.o Linking CXX executable icemaker [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/kseparator.cpp.o [ 28%] Building CXX object tier2/ki18n/src/CMakeFiles/KI18n.dir/common_helpers.cpp.o [ 28%] Built target icemaker [ 28%] Building CXX object tier2/ki18n/src/CMakeFiles/KI18n.dir/KI18n_automoc.cpp.o [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/ksqueezedtextlabel.cpp.o Scanning dependencies of target Solid Scanning dependencies of target Solid_static Linking CXX shared library libKWindowSystem.so [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/ktitlewidget.cpp.o Linking CXX shared library libKI18n.so [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/jobs/kjobuidelegate.cpp.o [ 28%] [ 28%] Scanning dependencies of target docbookl10nhelper Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/networking.cpp.o [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/ktoggleaction.cpp.o [ 28%] Building CXX object tier2/kdoctools/src/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/networking.cpp.o [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/randomness/krandom.cpp.o [ 28%] Built target KWindowSystem [ 28%] Building CXX object tier2/kdoctools/src/CMakeFiles/docbookl10nhelper.dir/docbookl10nhelper_automoc.cpp.o [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/ktogglefullscreenaction.cpp.o [ 28%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/solidnamespace.cpp.o [ 28%] Built target KI18n [ 28%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/managerbase.cpp.o Linking CXX executable docbookl10nhelper [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/randomness/krandomsequence.cpp.o [ 28%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/device.cpp.o [ 28%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/kviewstateserializer.cpp.o [ 28%] Building CXX object tier1/kcoreaddons/src/lib/CMakeFiles/KCoreAddons.dir/text/kmacroexpander.cpp.o [ 28%] Built target docbookl10nhelper [ 28%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/solidnamespace.cpp.o [ 29%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/devicemanager.cpp.o [ 29%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/managerbase.cpp.o [ 29%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/kviewstatemaintainerbase.cpp.o [ 29%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/deviceinterface.cpp.o [ 29%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/genericinterface.cpp.o [ 29%] Building CXX object tier1/kwidgetsaddons/src/CMakeFiles/KWidgetsAddons.dir/keditlistwidget.cpp.o Scanning dependencies of target
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 01:37 PM, Kevin Ottens wrote: if a package foo uses ecm (or that non existing tier0 cmake package) itself, this does not mean that another package which uses foo, also needs ecm (or that tier0 package) at buildtime. Well, if the tier 0 package contains the compiler settings for our frameworks, it'd mean everything tier 1 and up would use it. The alternatives right now being: duplicate the info or have it in cmake/ecm. So far we chose the have it in cmake/ecm route. If we had what Mirko refers to, then that'd open the door to another solution. Anyone up for hacking this up next week? I am available starting Monday afternoon. Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzoR4ACgkQYSSaITCTnKWHFACgv1aFktYPptBQ+G5hksS8qD/b 6ycAoJ09e/NwkonRqgMgtO3g70SyHJY8 =rnOY -END PGP SIGNATURE- ___ 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 : kdelibs_frameworks_qt5 #1552
See http://build.kde.org/job/kdelibs_frameworks_qt5/1552/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On 2013-11-01, Kevin Ottens er...@kde.org wrote: So far we chose the have it in cmake/ecm route. If we had what Mirko = refers=20 to, then that'd open the door to another solution. And it would open the first door towards alienating linux distributions. Of course, we could say and so what?. But that is our current primary way of getting our stuff to our users - so we shouldn't put obstacles in their way. Maven, ruby and stuff is all communities where there seem to be a strong tension with the linux distributions over issues like this. Let's not try to embrace that. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113533: Adapt KCMInit to use DBus to communicate with KSplash
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113533/ --- Review request for kde-workspace and KDE Frameworks. Repository: kde-workspace Description --- The xatom interface was removed from KSplash and replaced with a DBus one. This makes kcminit use the DBus interface and also removes the Xlib dependency (two commits). Diffs - kcminit/main.cpp 856d8b7 Diff: http://git.reviewboard.kde.org/r/113533/diff/ Testing --- KCMInit is still disabled for building, not much to test yet, but it works elsewhere, no reason to not work here. Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 01:53 PM, Sune Vuorela wrote: So far we chose the have it in cmake/ecm route. If we had what Mirko = refers=20 to, then that'd open the door to another solution. And it would open the first door towards alienating linux distributions. Of course, we could say and so what?. But that is our current primary way of getting our stuff to our users - so we shouldn't put obstacles in their way. Maven, ruby and stuff is all communities where there seem to be a strong tension with the linux distributions over issues like this. Let's not try to embrace that. Sune, with what I have suggested, there would be no difference for distributions regarding ECM. Now, they have to get ECM installed and tell CMake where to find it. Then, they will have to get the ECM repo installed, and tell CMake where to find it. For the offline case, I do not see a big difference. I don't want to downplay the concerns, but I think the problem is manageable. Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzpRMACgkQYSSaITCTnKXsZACfTa+FNQBFCwAW33kIXtcWcIzY BFcAoLDFhevjYbESagkg4J5V+uuX3+YQ =yVwn -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013, Mirko Boehm wrote: On 11/01/2013 01:37 PM, Kevin Ottens wrote: if a package foo uses ecm (or that non existing tier0 cmake package) itself, this does not mean that another package which uses foo, also needs ecm (or that tier0 package) at buildtime. Well, if the tier 0 package contains the compiler settings for our frameworks, it'd mean everything tier 1 and up would use it. The alternatives right now being: duplicate the info or have it in cmake/ecm. So far we chose the have it in cmake/ecm route. If we had what Mirko refers to, then that'd open the door to another solution. Anyone up for hacking this up next week? I am available starting Monday afternoon. as before, I have only some time in the evenings (and even less very soon). What's the exact plan ? One idea could be to have the tier0 package, and have KDECMakeSettings.cmake download/update ecm from git ? CMake has execute_process() for that, and it has ExternalProject_Add(), which is intended to pull in separate projects into a bigger project, e.g. using git. Or, this could be done as part of the build step of that tier0 package. Then installing this tier0 package would mean pulling a version of ecm e.g. from git, installing it somewhere, probably inside the tier0 install dir, and providing the module dir if KDECMakeSettings.cmake is used. Right now all components in KDECMakeSettings.cmake are optional and can be disabled individually, this could also be done that way for an automatically downloaded ecm. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On 2013-11-01, Mirko Boehm mi...@kde.org wrote: Anyone up for hacking this up next week? I am available starting Monday afternoon. Before you start hacking, please consider the following: http vs https? should http even be allowed? certificate handling? how to do ssl? a library? will cmake accept a dependency on a ssl library? which ones has a license that cmake will accept? /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs - src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- (Updated Nov. 1, 2013, 1:31 p.m.) Review request for KDE Frameworks and Plasma. Changes --- DummyJob no longer needed. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs (updated) - src/plasma/private/runnerjobs_p.h dfc2aca src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013, Mirko Boehm wrote: On 11/01/2013 01:53 PM, Sune Vuorela wrote: So far we chose the have it in cmake/ecm route. If we had what Mirko = refers=20 to, then that'd open the door to another solution. And it would open the first door towards alienating linux distributions. Of course, we could say and so what?. But that is our current primary way of getting our stuff to our users - so we shouldn't put obstacles in their way. Maven, ruby and stuff is all communities where there seem to be a strong tension with the linux distributions over issues like this. Let's not try to embrace that. Sune, with what I have suggested, there would be no difference for distributions regarding ECM. Now, they have to get ECM installed and tell CMake where to find it. Then, they will have to get the ECM repo installed, and tell CMake where to find it. For the offline case, I do not see a big difference. I don't want to downplay the concerns, but I think the problem is manageable. ...depending on if/how we want to do that: we could start simple: search for ecm in KDECMakeSettings.cmake using the normal find_package() command, and if not found, download in some way. There may be a switch to disable that downloading. This would, at least in the beginning, not really be a generic way for cmake to fetch find-modules, it would be basically a convenience so that KDE developers can do find_package(tier0-KF5) ... do stuff instead of find_package(ECM) find_package(tier0-KF5) If it turns out to work good, it may turn into something more generic later. This would still not at all force ECM or tier0-KF5 as a dependency on any user of KF5 libraries. It even would not force ECM as dependency to all KF5 libraries, they could still disable it if wanted. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/#review42771 --- Ship it! Looks good to me, approved. - Mirko Boehm On Nov. 1, 2013, 1:31 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- (Updated Nov. 1, 2013, 1:31 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs - src/plasma/private/runnerjobs_p.h dfc2aca src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113536: General cleanups of kguiaddons/plugins
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113536/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- A whole bunch of commits (listed below in reverse order, like git log). This is a preliminary to actually fixing up some of the plugins (like the EPS one). Remove the unhelpful ChangeLog Improve README file Mostly remove the list of plugins, since that is the sort of information that will not be kept in sync. Remove uppercase keys from imageformat json files QImageReader/Writer lowercases image formats before searching for plugins, so uppercase keys are useless. Add desktop file for WBMP plugin This is provided by the qtimageformats module Do not install desktop files for imageformat plugins that are not built If missing libraries etc. mean we do not build a plugin, we should not install the desktop file for it. Add imageconverter app to test imageformat plugins It is a command-line utility that converts images from one format to another using QImageReader and QImageWriter. Move kguiaddons/src/plugins to kguiaddons/src/plugins/imageformats This allows the plugins to be used prior to installation (for example, by tests) by adding kguiaddons/src/plugins to Qt's search path. Diffs - tier1/kguiaddons/src/CMakeLists.txt e1b17f4fcbda1052e21303f61f313058a9190da5 tier1/kguiaddons/src/plugins/AUTHORS tier1/kguiaddons/src/plugins/CMakeLists.txt 0536abeddb40220626be2ca80bf68c4a5cf79351 tier1/kguiaddons/src/plugins/ChangeLog 3d9f6dc1463d628db8a9f8fadab18475cd15160e tier1/kguiaddons/src/plugins/Mainpage.dox tier1/kguiaddons/src/plugins/README 20f3ef0019b571947d390cecdadcdd4745e4fe28 tier1/kguiaddons/src/plugins/bmp.desktop tier1/kguiaddons/src/plugins/config-kimgio.h.cmake tier1/kguiaddons/src/plugins/dds.cpp tier1/kguiaddons/src/plugins/dds.desktop tier1/kguiaddons/src/plugins/dds.h tier1/kguiaddons/src/plugins/dds.json 38b3d9adb13ab959d53190b218f083ed02f7d0eb tier1/kguiaddons/src/plugins/eps.h tier1/kguiaddons/src/plugins/eps.cpp tier1/kguiaddons/src/plugins/eps.desktop tier1/kguiaddons/src/plugins/eps.json 225c2895efecec14f09e1d5bd1f115aaee6eb0a0 tier1/kguiaddons/src/plugins/exr.cpp tier1/kguiaddons/src/plugins/exr.desktop tier1/kguiaddons/src/plugins/exr.h tier1/kguiaddons/src/plugins/exr.json 26fb4978de5d69ea4a8c10939f1b7ac026a63d0f tier1/kguiaddons/src/plugins/g3r.h tier1/kguiaddons/src/plugins/g3r.cpp tier1/kguiaddons/src/plugins/gif.desktop tier1/kguiaddons/src/plugins/gimp.h tier1/kguiaddons/src/plugins/hdr.cpp tier1/kguiaddons/src/plugins/hdr.desktop tier1/kguiaddons/src/plugins/hdr.h tier1/kguiaddons/src/plugins/ico.desktop tier1/kguiaddons/src/plugins/imageformats/README PRE-CREATION tier1/kguiaddons/src/plugins/imageformats/eps.json PRE-CREATION tier1/kguiaddons/src/plugins/imageformats/rgb.json PRE-CREATION tier1/kguiaddons/src/plugins/imageformats/wbmp.desktop PRE-CREATION tier1/kguiaddons/src/plugins/imageformats/xview.json PRE-CREATION tier1/kguiaddons/src/plugins/jp2.h tier1/kguiaddons/src/plugins/jp2.cpp tier1/kguiaddons/src/plugins/jp2.desktop tier1/kguiaddons/src/plugins/jp2.json 5a92b36c58e3852f71493b6fe5db8b271b9f8513 tier1/kguiaddons/src/plugins/jpeg.desktop tier1/kguiaddons/src/plugins/mng.desktop tier1/kguiaddons/src/plugins/pbm.desktop tier1/kguiaddons/src/plugins/pcx.h tier1/kguiaddons/src/plugins/pcx.cpp tier1/kguiaddons/src/plugins/pcx.desktop tier1/kguiaddons/src/plugins/pcx.json b3a7fc97fcb43eda91e90278af71b71b5f1066a6 tier1/kguiaddons/src/plugins/pgm.desktop tier1/kguiaddons/src/plugins/pic.cpp tier1/kguiaddons/src/plugins/pic.desktop tier1/kguiaddons/src/plugins/pic.h tier1/kguiaddons/src/plugins/pic.json 68f6f37ad08f3a0b3199240f5a135806a2b8ef46 tier1/kguiaddons/src/plugins/pic_read.cpp tier1/kguiaddons/src/plugins/pic_rw.h tier1/kguiaddons/src/plugins/pic_write.cpp tier1/kguiaddons/src/plugins/png.desktop tier1/kguiaddons/src/plugins/pnm.desktop tier1/kguiaddons/src/plugins/ppm.desktop tier1/kguiaddons/src/plugins/psd.cpp tier1/kguiaddons/src/plugins/psd.desktop tier1/kguiaddons/src/plugins/psd.h tier1/kguiaddons/src/plugins/psd.json da33c688c0a2a75cdbe24637ca8fd4ae1ffe807f tier1/kguiaddons/src/plugins/qimageio_plugin.desktop tier1/kguiaddons/src/plugins/ras.cpp tier1/kguiaddons/src/plugins/ras.desktop tier1/kguiaddons/src/plugins/ras.h tier1/kguiaddons/src/plugins/ras.json 7ba02f4b8ad446cedc730d2a721c042a835b864d tier1/kguiaddons/src/plugins/rgb.cpp tier1/kguiaddons/src/plugins/rgb.desktop tier1/kguiaddons/src/plugins/rgb.h tier1/kguiaddons/src/plugins/rgb.json 876ce9c6b56389599ed94d08bc4d130d208cdfd5
Re: Getting ecm files from the ECM package
On Friday, November 01, 2013 11:57:35 Kevin Ottens wrote: Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I think some distros disallow downloading stuff during build-time. I think for good reasons: - it makes builds harder to reproduce - it requires an internet connection (and a server to be reachable), which is not a given on all build farms - it makes checksums of source tarballs less useful - it introduce a vector for security problems (think compromising the server that serves the Find modules, code gets downloaded and executed from there - it feels icky Let's check first if this is an acceptable solution at all, before we start hacking. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013 17:04:12 Sebastian Kügler wrote: On Friday, November 01, 2013 11:57:35 Kevin Ottens wrote: Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I think some distros disallow downloading stuff during build-time. Then they just disable the feature during package creation, nothing gets downloaded. It's something you should be able to opt-out from anyway if you want to provide your own copy of the modules yourself (because you have them anyway for instance). In the same way, if enabled it should use the ones you got locally first for obvious reasons. 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: Getting ecm files from the ECM package
2013/11/1 Kevin Ottens er...@kde.org: Hello, On Friday 01 November 2013 11:23:14 Mirko Boehm wrote: On 11/01/2013 10:46 AM, Alexander Neundorf wrote: [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its standard library I agree that a separation of CMake and the find_modules make sense. But. My position indeed. I would agree at a tier 0 if it didn't make it miserable for third parties wanting to use a tier 1 library in the sense of oh by the way you also need that, and that, and that thing no one else use. Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I don't know how to even begin arguing against this, because if you don't see how wrong it is to download stuff during compilation, I don't know what arguments would help. I actively avoid any build system that automatically downloads dependencies. In fact, I avoid any tool that automatically downloads and installs software except for my distro's package manager and kdesrc-build. That means no easy_install, pip, rubygems, npm, maven, or whatever NIH package manager the $language community invented now. Maven is a disgusting monstrosity used by the Java crowd where backwards compatibility rarely exists, and the approach to make things not break is to make packages depend on exact versions of dependencies and download them automatically from who-knows-where. And then the same craziness gets copied or reinvented for other languages too. You don’t want a build tool which automatically downloads unresolved dependencies before cleaning out your build output directories. You don’t want a build tool which automatically downloads unresolved dependencies, PERIOD! Automatically downloading unresolved dependencies makes your build process nondeterministic! -- http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote: 2013/11/1 Kevin Ottens er...@kde.org: Hello, On Friday 01 November 2013 11:23:14 Mirko Boehm wrote: On 11/01/2013 10:46 AM, Alexander Neundorf wrote: [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its standard library I agree that a separation of CMake and the find_modules make sense. But. My position indeed. I would agree at a tier 0 if it didn't make it miserable for third parties wanting to use a tier 1 library in the sense of oh by the way you also need that, and that, and that thing no one else use. Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I don't know how to even begin arguing against this, because if you don't see how wrong it is to download stuff during compilation, I don't know what arguments would help. I actively avoid any build system that automatically downloads dependencies. In fact, I avoid any tool that automatically downloads and installs software except for my distro's package manager and kdesrc-build. That means no easy_install, pip, rubygems, npm, maven, or whatever NIH package manager the $language community invented now. +1 builds should NEVER download anything If it is needed it should be an EXPLICIT dependency, which I can fetch beforehand Maven is a disgusting monstrosity used by the Java crowd where backwards compatibility rarely exists, and the approach to make things not break is to make packages depend on exact versions of dependencies and download them automatically from who-knows-where. And then the same craziness gets copied or reinvented for other languages too. You don’t want a build tool which automatically downloads unresolved dependencies before cleaning out your build output directories. You don’t want a build tool which automatically downloads unresolved dependencies, PERIOD! Automatically downloading unresolved dependencies makes your build process nondeterministic! -- http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- (Updated Nov. 1, 2013, 6:10 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs - src/plasma/private/runnerjobs_p.h dfc2aca src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/#review42792 --- This review has been submitted with commit f114f7310dd4af72813262a969a05d3daee115a2 by Christoph Feck to branch master. - Commit Hook On Nov. 1, 2013, 1:31 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- (Updated Nov. 1, 2013, 1:31 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs - src/plasma/private/runnerjobs_p.h dfc2aca src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ 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 #882
See http://build.kde.org/job/plasma-framework_master_qt5/882/changes Changes: [christoph] Fix build with latest ThreadWeaver -- [...truncated 275 lines...] http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmaextracomponents/fallbackcomponent.cpp:0: Note: No relevant classes found. No output generated. Generating moc_storage_p.cpp Generating moc_storagethread_p.cpp Generating moc_storagetest.cpp [ 6%] Generating mouseeventlistener.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/mouseeventlistener.cpp:0: Note: No relevant classes found. No output generated. Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Built target storagetest_automoc Scanning dependencies of target platformcomponentsplugin_automoc Generating corebindingsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/corebindingsplugin.cpp:0: Note: No relevant classes found. No output generated. [ 7%] Automatic moc for target platformcomponentsplugin Generating moc_enums.cpp Generating moc_plasmacomponentsplugin.cpp Generating qmenu.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qmenu.cpp:0: Note: No relevant classes found. No output generated. Generating plasmaextracomponentsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmaextracomponents/plasmaextracomponentsplugin.cpp:0: Note: No relevant classes found. No output generated. Generating moc_modeltest.cpp Generating moc_columnproxymodel.cpp Generating moc_columnproxymodeltest.cpp [ 7%] Built target fullmodelaccesstest_automoc Generating moc_DeclarativeDragArea.cpp Generating moc_DeclarativeDragDropEvent.cpp Generating moc_DeclarativeDropArea.cpp Generating moc_DeclarativeMimeData.cpp Generating moc_draganddropplugin.cpp Scanning dependencies of target localebindingsplugin_automoc [ 7%] Built target draganddropplugin_automoc [ 8%] Automatic moc for target localebindingsplugin Scanning dependencies of target calendarplugin_automoc Generating qmenuitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qmenuitem.cpp:0: Note: No relevant classes found. No output generated. Generating qiconitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qiconitem.cpp:0: Note: No relevant classes found. No output generated. [ 8%] Automatic moc for target calendarplugin Generating moc_fallbackcomponent.cpp Generating moc_plasmaextracomponentsplugin.cpp [ 8%] Built target plasmaextracomponentsplugin_automoc Scanning dependencies of target plasmapkg_automoc [ 9%] Automatic moc for target plasmapkg Generating datamodel.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datamodel.cpp:0: Note: No relevant classes found. No output generated. Generating sortfiltermodeltest.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/tests/sortfiltermodeltest.cpp:0: Note: No relevant classes found. No output generated. Generating qrangemodel.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/qrangemodel.cpp:0: Note: No relevant classes found. No output generated. Generating platformextensionplugin.moc Generating moc_application.cpp Generating moc_application_p.cpp [ 9%] Built target platformcomponentsplugin_automoc Generating qimageitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qimageitem.cpp:0: Note: No relevant classes found. No output generated. Scanning dependencies of target kded_platformstatus_automoc Generating moc_plasmapkg.cpp Generating localebindingsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/locale/localebindingsplugin.cpp:0: Note: No relevant classes found. No output generated. [ 10%] Automatic moc for target kded_platformstatus [ 10%] Built target plasmapkg_automoc Scanning dependencies of target plasma_appletscript_declarative_automoc [ 10%] Automatic moc for target plasma_appletscript_declarative Generating units.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/plasmacomponents/units.cpp:0: Note: No relevant classes found. No output generated. Generating datasource.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/core/datasource.cpp:0: Note: No relevant classes found. No output generated. Generating platformstatus.moc QIODevice::read: device not open Generating qpixmapitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qpixmapitem.cpp:0: Note: No relevant
Re: Getting ecm files from the ECM package
On 11/01/2013 10:46 AM, Alexander Neundorf wrote: [1] Why not merge that into CMake ? For quicker releases, and even easier contributing. Also Bill once said that in hindsight he would have prefered if cmake would not ship any find-modules itself at all. So one could imagine that cmake would come without any find-modules in the future, and all find-modules would come from a separate package, e.g. ECM. This would make cmake the core tool, and ECM its standard library I agree that a separation of CMake and the find_modules make sense. But. Then it is time to think of a way to integrate cmake with the separate source of find_modules. Algorithmically, it would look like PROJECT(MyApplication) FIND_MODULES_REPOSITORY(http://ecm.kde.org;) FIND_PACKAGES(KF5 REQUIRED...) and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. I don't really feel comfortable with the idea of the build process hitting the Internet to download more code (CMake or otherwise) to execute as part of the build. Yes, this does mean I dislike the Maven concept too. :) It's hard to audit, hard to keep secure, and it shouldn't really be necessary as it's rare that you'd be just running CMake by yourself to build an individual git repo with all the splitting we've done. If you're using a build script that script should already be taking care of updating ECM just like any other build dependency. For example ECM is one of the first modules kdesrc-build builds in the default config, and likewise for the kf5 kdesrc-buildrc that is being maintained. I see what you're getting at though. It would be nice if CMake could automatically improve it's ability to find libraries and modules. But that shouldn't happen at build time, it's hard to version the code that ends up being used and it's also going to be very hard for our users who build from tarballs (not to mention our downstreams who are quite worried about security, for obvious reasons nowadays). This would also make a lot of things a lot easier. For example, nobody would need to separately install ECM, and updates to our ECM packages can be delivered globally by commits to that repo. Well, separate installation isn't that hard in the context of needing 17 different git repos just to do anything as it stands now. There's admittedly some hyperbole there, but not much! ;) Likewise, updating a central repo can work whether CMake downloads ECM or whether the existing build script or packaging script does it. It's still pulling from the same repo in the end. Please let me know if kdesrc-build is unsuitable as it stands now and I can try to fix it (or point to what's broken so others can). I'd hate for us to spend a lot of time implementing a new CMake feature to use instead of an existing 95% solution. Either way, even if kdesrc-build doesn't work, Michael Jansen's excellent build-tool is out there as well. Regards, - Michael Pyne 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: Getting ecm files from the ECM package
On Friday 01 November 2013, Treeve Jelbert wrote: On Friday 01 November 2013 15:46:30 Nicolás Alvarez wrote: ... Maven is a disgusting monstrosity used by the Java crowd where backwards compatibility rarely exists, and the approach to make things not break is to make packages depend on exact versions of dependencies and download them automatically from who-knows-where. And then the same craziness gets copied or reinvented for other languages too. You don’t want a build tool which automatically downloads unresolved dependencies before cleaning out your build output directories. You don’t want a build tool which automatically downloads unresolved dependencies, PERIOD! Automatically downloading unresolved dependencies makes your build process nondeterministic! -- http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? I understand all that, and I know that in some (a few...most) places this is a hard condition. I am also aware that in some (a few...most) other places getting always the latest from the internet is perfectly ok and prefered. Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files from extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/, with the optional ability (-DWITH_ECM) to download ECM and install ECM when building and installing kf5umbrella itself. If that option was enabled when installing kf5umbrella, kf5umbrella will load that embedded ECM when asked for ECM. In this quick hack attached here find_package(KF5Umbrella) unconditionally loads KDECMakeSettings.cmake. The version attached here does a find_package(ECM), except if this step is skipped by the using package via set(KDE_SKIP_ECM TRUE). If WITH_ECM was not enabled when installing kf5umbrella/, it searches the normal system ECM, otherwise it uses the embedded one. In case we decide to go this way (i.e. the my ideal view plus optional downloading), and we should hear Stephens opinion on that, I volunteer to maintain extra-cmake-modules, iff the three KDE*.cmake files are moved out of ECM, and I'll move it to github, to make contributing by others easier. Alex kf5umbrella-tier0.tar.gz Description: application/compressed-tar ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Friday 01 November 2013, Alexander Neundorf wrote: ... If that option was enabled when installing kf5umbrella, kf5umbrella will load that embedded ECM when asked for ECM. In this quick hack attached here find_package(KF5Umbrella) unconditionally loads KDECMakeSettings.cmake. The version attached here does a find_package(ECM), except if this step is skipped by the using package via set(KDE_SKIP_ECM TRUE). If WITH_ECM was not enabled when installing kf5umbrella/, it searches the normal system ECM, otherwise it uses the embedded one. Alternatively, each package could request some version of ECM and this version would be downloaded individually (e.g. by KDECMakeSettings.cmake) for each package, and would not be installed at all (or via a switch use the system provided one), but would be only available in the buildtree. This would have the downside that when chosing the download-option, when building all KF5 libs each of them might download their own copy of ECM. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Fri, November 1, 2013 20:06:43 Alexander Neundorf wrote: Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files from extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/, with the optional ability (-DWITH_ECM) to download ECM and install ECM when building and installing kf5umbrella itself. So this would remove everything KDE-specific from ECM into the separate kf5umbrella and leave ECM as a generic set of CMake addins? That could work, but then there would still need to be ECM releases for packaging purposes so that the optional ability to avoid downloading ECM would actually be a workable option. Regards, - Michael Pyne 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: Getting ecm files from the ECM package
On Friday 01 November 2013, Michael Pyne wrote: On Fri, November 1, 2013 20:06:43 Alexander Neundorf wrote: Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files from extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/, with the optional ability (-DWITH_ECM) to download ECM and install ECM when building and installing kf5umbrella itself. So this would remove everything KDE-specific from ECM into the separate kf5umbrella and leave ECM as a generic set of CMake addins? That could work, but then there would still need to be ECM releases for packaging purposes yes, of course. It could be done e.g. monthly. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Exceptions in KDE Frameworks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in ThreadWeaver, I would like to be able to catch exceptions thrown from the run() method of Jobs. You know we cannot trust the user :-) I can work around if exceptions are disabled in the compiler if I know about it. What I would like to be able to do is a) catch JobAborted and JobFailed exceptions thrown by the user, and set the job's status accordingly, b) catch other unhandled exceptions, print an error message and re-throw them. Unhandled exceptions in the worker thread basically mean the end of the program, as far as I am concerned, but I would like to be able to exit cleanly. Two questions: 1) Are we sure we want to disable exceptions in libraries released in 2014? 2) What is the _BLBAFASEL_EXCEPTIONS_ENABLED_ preprocessor variable that I can use to implemented the exception- and non-exception based code paths? Thanks, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJz1woACgkQYSSaITCTnKVaoQCeI9L48n2Cn8TA5X9nC1tLctzV XagAoIyUwA9sBOhFbkSWupsCA2P2YJHt =hAER -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 06:46 PM, Nicolás Alvarez wrote: and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I don't know how to even begin arguing against this, because if you don't see how wrong it is to download stuff during compilation, I don't know what arguments would help. I actively avoid any build system that automatically downloads dependencies. In fact, I avoid any tool that automatically downloads and installs software except for my distro's package manager and kdesrc-build. That means no easy_install, pip, rubygems, npm, maven, or whatever NIH package manager the $language community invented now. Maven is a disgusting monstrosity used by the Java crowd where backwards compatibility rarely exists, and the approach to make things not break is to make packages depend on exact versions of dependencies and download them automatically from who-knows-where. And then the same craziness gets copied or reinvented for other languages too. You don’t want a build tool which automatically downloads unresolved dependencies before cleaning out your build output directories. You don’t want a build tool which automatically downloads unresolved dependencies, PERIOD! Automatically downloading unresolved dependencies makes your build process nondeterministic! -- http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE build their packages? To me, build systems should not download anything sounds like a movie from the 80ies. I haven't heard much in terms of pro and con arguments in this discussio, just how dare you. I have been in extensive discussions about this topic, and both sides have good arguments. The truth is somewhere in the middle, because it depends on your situation. For example, from a developers point of view, what is the difference between me pulling the ECM repo and CMake doing it automatically? A brain? In my opinion, a central repository of community maintained find module packages has a chance of making a real difference. We have been debating the deployment problem of find modules for a long time, and obviously the solutions we currently have do not make everybody happy. Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ0IAkACgkQYSSaITCTnKUyIACeLd9CDT9WRqifYP9zEYv6YejG tXAAnRGswOSmcYwJzBZ1UTqOVfxQazOs =7ZOv -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
2013/11/1 Mirko Boehm mi...@kde.org: I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE build their packages? No I don't. I didn't say no distro does that. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On 2013-11-01, Alexander Neundorf neund...@kde.org wrote: Anyway, attached is a quick experiment, which adds the 3 KDE*.cmake files= from=20 extra-cmake-modules/ to kf5umbrella/, by that turning it into tier0/, wit= h the=20 optional ability (-DWITH_ECM) to download ECM and install ECM when buildi= ng=20 and installing kf5umbrella itself. gnuinstalldirs is in cmake. I'm sure that kdeinstalldirs can be in ecm without anyone think it looks weird. I'm not sure what that extra module buy us. find_package(KF5Umbrella) unconditionally loads KDECMakeSettings.cmake. no extra unconditional magic please. Our files should be understandable. I'm already lost 90% of the times I try to figure out how the cmake stuff is fit together. In case we decide to go this way (i.e. the my ideal view plus optional=20 downloading), and we should hear Stephens opinion on that, I volunteer to= =20 maintain extra-cmake-modules, iff the three KDE*.cmake files are moved ou= t of=20 ECM, and I'll move it to github, to make contributing by others easier. I think you mean to make contributing harder. Free software needs free tools! /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On 2013-11-01, Mirko Boehm mi...@kde.org wrote: To me, build systems should not download anything sounds like a movie from the 80ies. To me, build systems fetches code and executes it sounds like a bad horror movie. For example, from a developers point of view, what is the difference between me pulling the ECM repo and CMake doing it automatically? A brain? That you know it is going on. That you know your build system is also going to work tomorrow in the train. And note, it is not only pulling. It is also cloning. Fetching stuff from random places you haven't yet accepted is not good for anyones internet security. We should not push such things forward. In my opinion, a central repository of community maintained find module packages has a chance of making a real difference. Sure. And we have a central repository of community maintained find modules. That's not part of the discussion. If you want a tool that does all the magic for you, we have kdesrc-build. And build-tool. oh. and btw, you want to replace e-c-m with a 'fetch-ecm'-repository that people needs to fetch first? why not just ask people to fetch ecm in the first place? /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
On Fri, November 1, 2013 22:41:29 Mirko Boehm wrote: In my opinion, a central repository of community maintained find module packages has a chance of making a real difference. I'm not at all opposed to a centralized module of Find* cmake modules, in case I left that impression. But this central repository should be an actual listed dependency instead of an auto-magical figment of CMake's imagination. At the very least said magic should not be the only way to build with this proposed central repo. Regards, - Michael Pyne 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
Frameworks in api.kde.org
Hi guys, frameworks seem to be broken in api.kde.org I got to http://api.kde.org/frameworks/kdelibs-apidocs/ but then i wanted to recommend the awesome KConfig and ended in http://api.kde.org/frameworks/kdelibs-apidocs/kdecore/html/classKConfig.html Which is a sad 404. Any chance we can fix that? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113578: Remove KTextEditSpellInterface
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113578/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Remove KTextEditSpellInterface. Diffs - tier3/ktextwidgets/src/widgets/ktextedit.cpp b78096b tier3/ktextwidgets/src/widgets/ktextedit.h ff5ab8e Diff: http://git.reviewboard.kde.org/r/113578/diff/ Testing --- builds and tests pass. Thanks, Martin Tobias Holmedahl Sandsmark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113342: Add support for retrying to KIO (frameworks branch)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113342/ --- (Updated Nov. 1, 2013, 11:31 p.m.) Review request for KDE Frameworks, kdelibs and David Faure. Repository: kdelibs Description --- Add an explicit retry button to the kio skipdialog. Diffs - staging/kio/src/core/chmodjob.cpp 236386d staging/kio/src/core/copyjob.cpp 794efa1 staging/kio/src/core/jobuidelegateextension.h 689647f staging/kio/src/widgets/skipdialog.h a45f654 staging/kio/src/widgets/skipdialog.cpp d463ba1 Diff: http://git.reviewboard.kde.org/r/113342/diff/ Testing --- Thanks, Martin Tobias Holmedahl Sandsmark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Exceptions in KDE Frameworks
On Fri, November 1, 2013 17:30:02 Mirko Boehm wrote: Hi, in ThreadWeaver, I would like to be able to catch exceptions thrown from the run() method of Jobs. You know we cannot trust the user :-) I can work around if exceptions are disabled in the compiler if I know about it. What I would like to be able to do is a) catch JobAborted and JobFailed exceptions thrown by the user, and set the job's status accordingly, b) catch other unhandled exceptions, print an error message and re-throw them. Unhandled exceptions in the worker thread basically mean the end of the program, as far as I am concerned, but I would like to be able to exit cleanly. Two questions: 1) Are we sure we want to disable exceptions in libraries released in 2014? 2) What is the _BLBAFASEL_EXCEPTIONS_ENABLED_ preprocessor variable that I can use to implemented the exception- and non-exception based code paths? KSharedDataCache uses exceptions now. This is only in its own code so as not to bloat the rest of kdelibs for users who don't want exception support, but I'd say if it makes your code easier, to go for it. AFAIK the only reason to avoid exceptions is an increase in code size, which doesn't strike me as a strong problem in 2014. But on the other hand it might still be an issue for embedded platforms, which I'm sure we'd want to support. I don't know the defines for it though, sorry. Regards, - Michael Pyne 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: Getting ecm files from the ECM package
Mirko Boehm wrote: Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE build their packages? I can vouche for fedora/redhat that the buildsystem does not have internet access. -- rex ___ 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 #883
See http://build.kde.org/job/plasma-framework_master_qt5/883/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
