Re: Review Request 120058: Move imagethumbnailer away from KDE4Support
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120058/#review65944 --- Ship it! Ship It! - David Faure On Sept. 5, 2014, 4:56 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120058/ --- (Updated Sept. 5, 2014, 4:56 p.m.) Review request for KDE Frameworks. Repository: kio-extras Description --- Remove unused includes and we don't need KDE4Support anymore. I alse replaced some tabs with spaces. Diffs - thumbnail/CMakeLists.txt bd40c0e thumbnail/imagecreator.h d06c9fa thumbnail/imagecreator.cpp dd5ffe2 Diff: https://git.reviewboard.kde.org/r/120058/diff/ Testing --- Removed my thumbnail cache and created new thumbnails. Works both from dolphin and from plasma. Thanks, Maarten De Meyer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119798: Generating PkgConfig files from ECM
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119798/
---
(Updated Sept. 7, 2014, 7:57 a.m.)
Review request for Build System, KDE Frameworks and Harald Sitter.
Repository: extra-cmake-modules
Description
---
So we decided we wanted those .pc files, so I created a small script that
generates one, I haven't used pc in the past, so feedback is welcome.
Diffs (updated)
-
modules/ECMGeneratePkgConfigFile.cmake PRE-CREATION
tests/CMakeLists.txt 65de038
tests/ECMGeneratePkgConfigFile/CMakeLists.txt PRE-CREATION
tests/ECMGeneratePkgConfigFile/KF5CoreAddons.pc PRE-CREATION
tests/ECMGeneratePkgConfigFile/run_test.cmake.config PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/119798/diff/
Testing
---
I added it in KCoreAddons, this is the patch:
diff --git src/lib/CMakeLists.txt src/lib/CMakeLists.txt
index 26eb5a1..3a07d1c 100644
--- src/lib/CMakeLists.txt
+++ src/lib/CMakeLists.txt
@@ -188,4 +188,6 @@ install(FILES
include(ECMGeneratePriFile)
ecm_generate_pri_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons DEPS core
FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR
${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons)
+ecm_generate_pkgconfig_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons DEPS
Qt5Core INCLUDE_INSTALL_DIR ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons INSTALL)
install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
This is the result, on my system:
Name: KF5CoreAddons
Version: 5.1.0
Libs: -L/home/kde-devel/kde5/lib64 -l/home/kde-devel/kde5/lib64
Cflags: -I/home/kde-devel/kde5/include/KF5/KCoreAddons
Requires: Qt5Core
Thanks,
Aleix Pol Gonzalez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: There's no proper replacement for KIcon
El Dijous, 4 de setembre de 2014, a les 14:04:04, Kevin Ottens va escriure: On Thursday 04 September 2014 11:36:38 Martin Klapetek wrote: On Wed, Sep 3, 2014 at 10:10 PM, Eike Hein h...@kde.org wrote: On 09/03/2014 10:07 PM, Nicolás Alvarez wrote: So if I'm not in a Plasma session I get no icons? If you're not in a Plasma session you don't get the Plasma platform plugin. Other platform plugins can drive this as they prefer. Isn't that the task of the given platform plugin? Eg. if I run my app in Gnome, there should be a Gnome plugin which provides its own icon plugin and loads Gnome icons (well in an ideal world, anyway) and thus making the app actually look more integrated...in other words, shouldn't this problem be moved there? Spot on. And such a plugin is in fact shipped with Qt, but for some reason isn't loaded in Albert's case. That awfully sounds like a bug to me, hence why my line of argument is that it should be investigated and fixed. My setup investigation: * Plasma 4 logged in with tsdgeos * konsole logged in to kdeunstable via su - kdeunstable * I'm using the QGenericUnixTheme QPT (aka PlatformTheme) * QGenericUnixTheme uses XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to decide in which desktop environment you are * Since none of those environment variables are defined in my kdeunstable user it falls back to the UNKNOWN desktop environment * Then it goes to QGenericUnixTheme::themeNames and since it's not a known desktop it will default to QGenericUnixTheme as QPT instead of to QKdeTheme or QGnomeTheme for icon theme handling * Then QGenericUnixTheme::themeHint does not implement QPlatformTheme::SystemIconThemeName and QPlatformTheme::SystemIconFallbackThemeName defaults to hicolor * And hicolor is not a proper theme, just a fallback theme, so it is not designed to hold icons for the majority of icons. One could say the bug is in QGenericUnixTheme::themeHint that should actually provide a meaningul icon theme instead of hicolor as default. The problem is that there is not (or I could not find it) a xdg-way to set/get the current icon theme so it's hard not to default to something different than hicolor, one possibility would be making QGenericUnixTheme::themeHint default to say the first icon theme in xdgIconThemePaths, but that's obviously not that great either. So as I see it, there's three options: * Do nothing, and expect that people have to set one of XDG_CURRENT_DESKTOP, KDE_FULL_SESSION, GNOME_DESKTOP_SESSION_ID or DESKTOP_SESSION environment variables to get icons * Do the change/hack to QGenericUnixTheme::themeHint return any of the themes in xdgIconThemePaths that is not hicolor * Talk to the xdg-people to include a way to get the current icon theme and use that in QGenericUnixTheme::themeHint Cheers, Albert P.S: Sorry it took that much to answer, akademy+travel kept me busy. Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119977: Mark setProgramIconName() as deprecated, it did not do anything
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119977/#review65948 --- Ship it! Yes, this is indeed the best solution. Let people use the QGuiApplication method instead, that's the Qt way, and in the rare case we need the icon name, we can use QIcon::name(). (could be empty, of course, but in KDE apps it won't be, we load our icons from the icon theme). - David Faure On Aug. 28, 2014, 4:39 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119977/ --- (Updated Aug. 28, 2014, 4:39 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Mark setProgramIconName() as deprecated, it did not do anything since kcoreaddons no longer uses QtGui so it can not set the icon. BUG: 337938 Diffs - src/lib/kaboutdata.h 2d8bd5645150a57739e94f9f71b112b20ec0e01f src/lib/kaboutdata.cpp 5ad81de814c123f50b17bb542331459e15649f4b Diff: https://git.reviewboard.kde.org/r/119977/diff/ Testing --- compiled a program made with kapptemplate 4.14.1 which uses this function, successfully gives a warning during compile Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- (Updated Sept. 7, 2014, 8:44 a.m.) Review request for KDE Frameworks and David Faure. Changes --- Missed the showMenu action. Perhaps the same should be done for the setShortcuts call in the AutomaticAction constructor, but now at least kate/kwrite stdactions are really clean of warnings it seems. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs (updated) - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/#review65958 --- Ship it! src/kstandardaction.cpp https://git.reviewboard.kde.org/r/120088/#comment46063 Well, avoiding a warning is not the actual reason :) The actual reason is to allow the configure shortcuts to find out what the default shortcut is, even if the user configured another shortcut. src/kstandardaction.cpp https://git.reviewboard.kde.org/r/120088/#comment46064 s/the// - David Faure On Sept. 7, 2014, 8:44 a.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- (Updated Sept. 7, 2014, 8:44 a.m.) Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Interesting issue with KAboutData and icons
On Monday 18 August 2014 10:08:53 Harald Sitter wrote: On Mon, Aug 18, 2014 at 9:41 AM, David Faure fa...@kde.org wrote: On Monday 04 August 2014 22:01:15 Michael Pyne wrote: Hi all, I received a bug (https://bugs.kde.org/show_bug.cgi?id=337938) reported against KAboutData in KCoreAddons, that setting the window icon doesn't actually set the window icon. In fact, KAboutData doesn't even try to, except for setting a property to the string name of the icon in question. Well, that dynamic property call is supposed to catch this static property from QGuiApplication, provided that qApp is not just a QCoreApplication: Q_PROPERTY(QIcon windowIcon READ windowIcon WRITE setWindowIcon) I made this stuff work in qtbase f42bd772f8110dba13d209d81d8eed002185, which is in Qt 5.3.0. So it's known that it won't work with older versions of Qt. I didn't test it via KAboutData though. The code in KAboutData expects 'applicationIconName' as property name, which does not exist. Furthermore in kcoreaddons we couldn't construct a QIcon so the 'windowIcon' property couldn't be used either. Indeed, my reply was nonsense. This is fixed now: ignore KAboutData when it comes to the icon, and call QGuiApplication::setWincow(QIcon::fromTheme(...)). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 119977: Mark setProgramIconName() as deprecated, it did not do anything
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119977/ --- (Updated Sept. 7, 2014, 9:21 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Mark setProgramIconName() as deprecated, it did not do anything since kcoreaddons no longer uses QtGui so it can not set the icon. BUG: 337938 Diffs - src/lib/kaboutdata.h 2d8bd5645150a57739e94f9f71b112b20ec0e01f src/lib/kaboutdata.cpp 5ad81de814c123f50b17bb542331459e15649f4b Diff: https://git.reviewboard.kde.org/r/119977/diff/ Testing --- compiled a program made with kapptemplate 4.14.1 which uses this function, successfully gives a warning during compile Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120078: workaround QTBUG-40584
On Sept. 6, 2014, 12:46 nachm., Lukáš Tinkl wrote: [ 22%] Building CXX object src/CMakeFiles/KF5XmlGui.dir/kmainwindow.cpp.o /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.cpp: In member function ‘virtual void KMainWindow::applyMainWindowSettings(const KConfigGroup)’: /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.cpp:616:30: error: invalid use of incomplete type ‘class QWindow’ resize(windowHandle()-size()); ^ In file included from /usr/include/qt5/QtWidgets/qwidget.h:45:0, from /usr/include/qt5/QtWidgets/qmainwindow.h:45, from /usr/include/qt5/QtWidgets/QMainWindow:1, from /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.h:34, from /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.cpp:27: /usr/include/qt5/QtGui/qwindowdefs.h:56:7: error: forward declaration of ‘class QWindow’ class QWindow; ^ In file included from /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.cpp:890:0: /home/ltinkl/git/plasma-next-setup-script/kxmlgui/build/src/moc_kmainwindow.cpp: In static member function ‘static void KMainWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: /home/ltinkl/git/plasma-next-setup-script/kxmlgui/build/src/moc_kmainwindow.cpp:110:42: warning: ‘virtual void KMainWindow::showAboutApplication()’ is deprecated (declared at /home/ltinkl/git/plasma-next-setup-script/kxmlgui/src/kmainwindow.h:604) [-Wdeprecated-declarations] case 5: _t-showAboutApplication(); break; ^ make[2]: *** [src/CMakeFiles/KF5XmlGui.dir/kmainwindow.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/KF5XmlGui.dir/all] Error 2 make: *** [all] Error 2 Thomas Lübking wrote: gah... blast. you can't trust anybody anymore ;-) sorry for the trouble. Hrvoje Senjan wrote: ah, forgot to mention in the report that it needs a QWindow include I could simply at least have tried to compile the patch myself, before opening a review request =) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120078/#review65899 --- On Sept. 7, 2014, 11:02 vorm., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120078/ --- (Updated Sept. 7, 2014, 11:02 vorm.) Review request for KDE Frameworks and kdelibs. Bugs: 337353 https://bugs.kde.org/show_bug.cgi?id=337353 Repository: kxmlgui Description --- This a) ensures there's windowaHandle() to restore the size for b) works around a pending Qt bug by explicitly coyping the restored QWindow size to the QWidget size also see https://git.reviewboard.kde.org/r/119594/ Diffs - src/kmainwindow.cpp e273a76 Diff: https://git.reviewboard.kde.org/r/120078/diff/ Testing --- Hrvoje, see bug - not tested myself. Thanks, Thomas Lübking ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120088: Fix the warning about setDefaultShortcut for stdactions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120088/ --- (Updated Sept. 7, 2014, 11:33 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kconfigwidgets Description --- Fix the 'Shortcut for action XXX YYY set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead' for StdActions Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120088/diff/ Testing --- Standard actions use lead to that warning, as the internally use just setShortcuts (as they can't use KActionCollection). KWrite now starts up with close to zero warnings (and none for standard actions, I think). Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Diffs - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing --- Tested with Kate, removed the super verbose Added File... output for any opened file. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- (Updated Sept. 7, 2014, 1:29 p.m.) Review request for KDE Frameworks and David Faure. Summary (updated) - Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods Repository: kcoreaddons Description (updated) --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Guard available methods with same trick, will allow use in non-debug build of that output. Diffs (updated) - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing (updated) --- Tested with Kate, removed the super verbose Added File... output for any opened file. Available methods are gone in output, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120092: Turn KFormat into Q_GADGET and expose DurationFormat
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120092/ --- (Updated Sept. 7, 2014, 1:49 p.m.) Review request for KDE Frameworks and Plasma. Repository: kcoreaddons Description --- Thanks to the awesome David, I discovered Q_GADGET and it allows us to expose the Duration stuff in KDeclarative without needing to turn it into a QObject Diffs - src/lib/util/kformat.h 7a6a418 src/lib/util/kformat.cpp d62240e Diff: https://git.reviewboard.kde.org/r/120092/diff/ Testing --- Works. Thanks, Kai Uwe Broulik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kate uses invalid category
On Saturday, September 06, 2014 02:54:04 PM Marko Käning wrote: When building kate I suddenly see tons of these warnings popping up: Rename to *-apps-*.png. Can you try again? Thanks, Dominik CMake Warning at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:176 (message): Icon kate.png uses invalid category app, setting to 'actions' Call Stack (most recent call first): /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:124 (_ECM_ADD_ICON_INSTALL_RULE) /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:207 (_ecm_install_icons_v1) kate/icons/CMakeLists.txt:2 (ecm_install_icons) CMake Warning at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:176 (message): Icon kate.svgz uses invalid category app, setting to 'actions' Call Stack (most recent call first): /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:159 (_ECM_ADD_ICON_INSTALL_RULE) /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modu les/inst/share/ECM/modules/ECMInstallIcons.cmake:207 (_ecm_install_icons_v1) kate/icons/CMakeLists.txt:2 (ecm_install_icons) ___ 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 120096: replace static arrays with dynamic size with QVector
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120096/ --- Review request for KDE Frameworks and kdewin. Repository: karchive Description --- on windows static arrays can only be initialized with a const Diffs - src/k7zip.cpp 2db043520ebff6bf7661e8ac993d107f4bd6a5e7 Diff: https://git.reviewboard.kde.org/r/120096/diff/ Testing --- windows Thanks, Patrick Spendrin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: OSX/CI: kate uses invalid category
On 07 Sep 2014, at 13:34 , Dominik Haumann dhaum...@kde.org wrote: On Saturday, September 06, 2014 02:54:04 PM Marko Käning wrote: When building kate I suddenly see tons of these warnings popping up: Rename to *-apps-*.png. Can you try again? There is only one left: --- 17:27:59 Icon debug-kategdb.png uses invalid category action, setting to ‘actions' --- Also there are messages like these: --- 7:27:59 -- Found KF5: success (found version 5.2.0) found components: Parts TextEditor XmlGui Notifications 17:27:59 CMake Warning (dev) at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kdesupport/extra-cmake-modules/inst/share/ECM/modules/ECMInstallIcons.cmake:206 (message): 17:27:59 ecm_install_icons() with no ICONS argument is deprecated --- Greets, Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120096: replace static arrays with dynamic size with QVector
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120096/#review66006 --- I would suggest to use QVarLengthArray instead. - Christoph Feck On Sept. 7, 2014, 3:20 p.m., Patrick Spendrin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120096/ --- (Updated Sept. 7, 2014, 3:20 p.m.) Review request for KDE Frameworks and kdewin. Repository: karchive Description --- on windows static arrays can only be initialized with a const Diffs - src/k7zip.cpp 2db043520ebff6bf7661e8ac993d107f4bd6a5e7 Diff: https://git.reviewboard.kde.org/r/120096/diff/ Testing --- windows Thanks, Patrick Spendrin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120025: Have KStandardAction::create(...) call KActionCollection::setDefaultShortcuts()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120025/ --- (Updated Sept. 7, 2014, 6 nachm.) Status -- This change has been discarded. Review request for KDE Frameworks. Bugs: 338222 https://bugs.kde.org/show_bug.cgi?id=338222 Repository: kconfigwidgets Description --- As e.g. reported in https://bugs.kde.org/show_bug.cgi?id=338222 (False positive critical warnings for KStandardActions) currently KXMLGUIFactoryPrivate::saveDefaultActionProperties complains about lots of actions that have been created properly via KStandardActions with a KActionCollection as parent. Just grep the log of your favourite XMLGUI-based KF5-ported program to see yourself. I have not yet completely grasped the concept of the default shortcuts and why they are set only explicitely via KActionCollection::setDefaultShortcuts. But to me it makes some sense to have this automatically called for all standardactions which are created directly with a KActionCollection as parent. I decided not to change KActionCollection::addAction because I had even less idea what all might be affected by that. So this is what this patch does: * add a call to KActionCollection::setDefaultShortcuts if there is a standard shortcut (via QMetaObject::invokeMethod, like done for KActionCollection::addAction) * also move code which only should be done in case of a created action into one, same branch Needs https://git.reviewboard.kde.org/r/120024/ to make KActionCollection::setDefaultShortcuts() invokable. Diffs - src/kstandardaction.cpp a18527b Diff: https://git.reviewboard.kde.org/r/120025/diff/ Testing --- Thanks, Friedrich W. H. Kossebau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120024: Prevent some false positive critical warnings for KStandardActions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120024/ --- (Updated Sept. 7, 2014, 6:03 nachm.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kxmlgui Description --- In combination with https://git.reviewboard.kde.org/r/120025/, please read that one first. This part of the patch does: * make KActionCollection::setDefaultShortcuts() invokable per QMetaObject::invokeMethod, so KStandardAction::create(...) can access it * make sure that setDefaultShortcuts is also called for KStandardActions created in the non-default-name addAction variant * add a new constructor to KHelpMenu to allow passing an KActionCollection in, so all standardactions can be created from the beginning as items in the actioncollection, including setup with setDefaultShortcuts Follow-up for KHelpMenu in KParts is https://git.reviewboard.kde.org/r/120026/ Diffs - src/kactioncollection.h 5dbc3c2 src/kactioncollection.cpp 6c7af0f src/khelpmenu.h df820f2 src/khelpmenu.cpp 53397cc src/kxmlguifactory.cpp c4ad97b src/kxmlguiwindow.cpp bd89279 Diff: https://git.reviewboard.kde.org/r/120024/diff/ Testing --- With this and the other patches, I can see no more of those warnings for standard actions, both KWrite and Okteta. Also all unit tests still work. Thanks, Friedrich W. H. Kossebau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120026: Pass KActionCollection to KHelpMenu for KParts::MainWindow
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120026/ --- (Updated Sept. 7, 2014, 6:03 nachm.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: kparts Description --- See https://git.reviewboard.kde.org/r/120024/, to be committed after that one. Diffs - src/mainwindow.cpp 7e2ad9c Diff: https://git.reviewboard.kde.org/r/120026/diff/ Testing --- Thanks, Friedrich W. H. Kossebau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120093: Guard too verbose 'KDirWatchPrivate::addEntry: Added File...' message + use same method to output available methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/#review66015 --- Ship it! Ideally this should use qCDebug though (with a call to setFilterRules category.debug=false). - David Faure On Sept. 7, 2014, 1:29 p.m., Christoph Cullmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120093/ --- (Updated Sept. 7, 2014, 1:29 p.m.) Review request for KDE Frameworks and David Faure. Repository: kcoreaddons Description --- Guard the 'KDirWatchPrivate::addEntry: Added File...' with same guard as the removeEntry output. Guard available methods with same trick, will allow use in non-debug build of that output. Diffs - src/lib/io/kdirwatch.cpp 7abb32a Diff: https://git.reviewboard.kde.org/r/120093/diff/ Testing --- Tested with Kate, removed the super verbose Added File... output for any opened file. Available methods are gone in output, too. Thanks, Christoph Cullmann ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120016: Read mimeapps.list from XDG_CONFIG_HOME and XDG_CONFIG_DIRS
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120016/ --- (Updated Sept. 7, 2014, 10:11 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kservice Description --- Read the mimeapps.list from XDG_CONFIG_HOME and XDG_CONFIG_DIRS too, according to mime-apps-spec 1.0 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#file This improves interoperability with applications using current glib/gio which now saves user mimeapps.list in XDG_CONFIG_HOME. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - src/kbuildsycoca/kmimeassociations.cpp efc16f4 Diff: https://git.reviewboard.kde.org/r/120016/diff/ Testing --- tested with kservice 5.1.0 (Mageia Cauldron) Thanks, Luc Menut ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120018: KIO: Open user mimeapps.list from XDG_CONFIG_HOME
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120018/ --- (Updated Sept. 7, 2014, 10:11 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kio Description --- Open the user mimeapps.list from XDG_CONFIG_HOME, according to mime-apps-spec 1.0 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#file This improves interoperability with applications using current glib/gio which now saves user mimeapps.list in XDG_CONFIG_HOME. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - src/widgets/kopenwithdialog.cpp 4c56fc1246004919abde65ab32b8dd57397b3f7b Diff: https://git.reviewboard.kde.org/r/120018/diff/ Testing --- tested with kio 5.1.0 (Mageia Cauldron) Thanks, Luc Menut ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120017: kde-cli-tools: Open user mimeapps.list from XDG_CONFIG_HOME
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120017/ --- (Updated Sept. 7, 2014, 10:45 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kde-cli-tools Description --- Open the user mimeapps.list from XDG_CONFIG_HOME, according to mime-apps-spec 1.0 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#file This improves interoperability with applications using current glib/gio which now saves user mimeapps.list in XDG_CONFIG_HOME. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - keditfiletype/mimetypedata.cpp 65af59c6f840a6a059ccf461b27794e1a36bd4ef Diff: https://git.reviewboard.kde.org/r/120017/diff/ Testing --- tested with kde-cli-tools 5.0.1 (Mageia Cauldron) Thanks, Luc Menut ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: SIC in KIO master
On Sunday 31 August 2014 19:01:01 Harald Sitter wrote: That being said, IMHO it would be perfectly reasonable to deprecate the signal OK I did that now, after reverting. I guess you're right, holding our SC/BC promise even in (IMHO) theoretical cases is more important than a bit of clean up which can wait for KF6. If we need to change CopyInfo in any way, we'll have to switch to some internal copy in kio and keep that one as the public and deprecated one. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kconfigwidgets_master_qt5 #82
See http://build.kde.org/job/kconfigwidgets_master_qt5/82/ -- Started by remote host 2a01:4f8:160:9363::9 with note: Triggered by commit Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/kconfigwidgets_master_qt5/ws/ Running Prebuild steps [kconfigwidgets_master_qt5] $ /bin/sh -xe /tmp/hudson3010788801527713989.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources fatal: unable to connect to anongit.kde.org: anongit.kde.org[0: 31.216.41.69]: errno=Connection timed out anongit.kde.org[1: 5.39.11.196]: errno=Connection timed out == Cleaning Source Tree HEAD is now at 3709da9 fix edit shortcuts of standard actions Removing build/ Removing dotdata/ Removing local-inst/ Success build forhudson.tasks.Shell@61852957 git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url git://anongit.kde.org/kconfigwidgets # timeout=10 Fetching upstream changes from git://anongit.kde.org/kconfigwidgets git --version # timeout=10 git fetch --tags --progress git://anongit.kde.org/kconfigwidgets +refs/heads/*:refs/remotes/origin/* FATAL: Failed to fetch from git://anongit.kde.org/kconfigwidgets hudson.plugins.git.GitException: Failed to fetch from git://anongit.kde.org/kconfigwidgets at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:627) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:865) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:890) at hudson.model.AbstractProject.checkout(AbstractProject.java:1253) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1740) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command git fetch --tags --progress git://anongit.kde.org/kconfigwidgets +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: fatal: unable to connect to anongit.kde.org: anongit.kde.org[0: 31.216.41.69]: errno=Connection timed out anongit.kde.org[1: 5.39.11.196]: errno=Connection timed out at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1407) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1195) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:266) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons fails to build properly on OSX/CI (was OSX/CI: kauth fails to build )
On Wednesday 20 August 2014 22:44:20 Marko Käning wrote: I had to revert back to and rebuild the older cmake version now [3], in order to be at least partially able to build things. [2] cmake revision: 7000a06b06ef3c5d15418b3afb4f0525fa1f688c from June 3rd [3] cmake revision: 0ee116b7eb1e65d7e7ae6c13628c57eec038b53d Did you report this to the cmake guys? It seems other people (e.g. David Gil Oliva, cc'ed) are hitting the same issue, so it's not fixed yet. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons fails to build properly on OSX/CI (was OSX/CI: kauth fails to build )
On Sep 8, 2014 11:15 AM, David Faure fa...@kde.org wrote: On Wednesday 20 August 2014 22:44:20 Marko Käning wrote: I had to revert back to and rebuild the older cmake version now [3], in order to be at least partially able to build things. [2] cmake revision: 7000a06b06ef3c5d15418b3afb4f0525fa1f688c from June 3rd [3] cmake revision: 0ee116b7eb1e65d7e7ae6c13628c57eec038b53d Did you report this to the cmake guys? It seems other people (e.g. David Gil Oliva, cc'ed) are hitting the same issue, so it's not fixed yet. If I recall correctly, these sorts of problems were why the CI system previously used to track the dev branch of CMake. Perhaps we need to evaluate a return to such a setup? Regressions in cmake will be particularly painful if they make it into a final release. Thanks, Ben -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ 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
Jenkins build is back to normal : kconfigwidgets_master_qt5 #83
See http://build.kde.org/job/kconfigwidgets_master_qt5/83/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120012: kde-cli-tools: Save the default application into the group [Default Applications]
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120012/ --- (Updated Sept. 7, 2014, 11:58 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kde-cli-tools Description --- Save the default application for a given mimetype by writing into the group [Default Applications] in the file mimeapps.list, according to mime-apps-spec 1.0 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#default Currently, the default application saved by KDE (first application in [Added Assocations] ) is not respected by applications using glib/gio (which follow mime-apps-spec 1.0) if there is a default application at a lower level (eg $XDG_DATA_DIRS/applications/mimeapps.list), because the most-preferred .desktop from [Added Assocations] for a given mimetype is used to determine the default application only if there is no entry in [Default Applications] for this mimetype at all levels. mime-apps-spec 1.0#default ... In the absence of such an entry, the next mimeapps.list is checked. Once all levels have been checked, if no entry could be found, the implementations should pick the most-preferred .desktop files associated with the mimetype, taking into account added and removed associations as per the next section. eg. if we have - ~/.local/share/applications/mimeapps.list (with no group [Default Applications] ) [Added Assocations] mimetype1=foo1.desktop;foo2.desktop;foo3.desktop - /usr/share/applications/mimeapps.list (from distrib preferences) [Default Applications] mimetype1=foo3.desktop;foo4.desktop;foo1.desktop;foo2.desktop; according to mime-apps-spec 1.0, the default application used for mimetype1 will be foo3.desktop instead of foo1.desktop expected by a KDE user. The proposed patch fixes this. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - keditfiletype/mimetypedata.h 5b00c07 keditfiletype/mimetypedata.cpp 65af59c Diff: https://git.reviewboard.kde.org/r/120012/diff/ Testing --- tested with kde-cli-tools 5.0.1 (Mageia Cauldron) Thanks, Luc Menut ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: kwindowsystem_master_qt5 » All,LINBUILDER #93
See http://build.kde.org/job/kwindowsystem_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120015: KIO: Save the default application into the group [Default Applications]
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120015/ --- (Updated Sept. 7, 2014, 11:59 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kio Description --- Similar change for KIO as Review Request #120012 Save the default application for a given mimetype by writing into the group [Default Applications] in the file mimeapps.list, according to mime-apps-spec 1.0 . http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#default Currently, the default application saved by KDE (first application in [Added Assocations] ) is not respected by applications using glib/gio (which follow mime-apps-spec 1.0) if there is a default application at a lower level (eg $XDG_DATA_DIRS/applications/mimeapps.list), because the most-preferred .desktop from [Added Assocations] for a given mimetype is used to determine the default application only if there is no entry in [Default Applications] for this mimetype at all levels. mime-apps-spec 1.0#default ... In the absence of such an entry, the next mimeapps.list is checked. Once all levels have been checked, if no entry could be found, the implementations should pick the most-preferred .desktop files associated with the mimetype, taking into account added and removed associations as per the next section. eg. if we have - ~/.local/share/applications/mimeapps.list (with no group [Default Applications] ) [Added Assocations] mimetype1=foo1.desktop;foo2.desktop;foo3.desktop - /usr/share/applications/mimeapps.list (from distrib preferences) [Default Applications] mimetype1=foo3.desktop;foo4.desktop;foo1.desktop;foo2.desktop; according to mime-apps-spec 1.0, the default application used for mimetype1 will be foo3.desktop instead of foo1.desktop expected by a KDE user. The proposed patch fixes this. regards, Luc Menut - Mageia PS: I don't have write access to kde git, so could you commit the change if the patch looks fine. Thanks. Diffs - src/widgets/kopenwithdialog.cpp 4c56fc1 Diff: https://git.reviewboard.kde.org/r/120015/diff/ Testing --- tested with kio 5.1.0 (Mageia Cauldron) Thanks, Luc Menut ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kcoreaddons fails to build properly on OSX/CI (was OSX/CI: kauth fails to build )
Hi David, due to me working nonstop over the weekend - on bringing a Jenkins-based OSX/CI slave system to life [1] - I’ve not yet informed you guys that I by now have successfully retried building a newer cmake version (a1eb90c85d80acf9617ccac73a45b6753188947d) as well [2]. Turns out that I was able to build all KF5 frameworks [3] and apps [4] successfully with it. For now I'll leave on my OSX/CI systems cmake pinned at that version. Ben’s suggestion makes sense to me, one shouldn’t distribute a newer cmake if it is not ensured that all depending stuff can be build without trouble. Greets, Marko P.S.: Apart from that I am in discussion with Ben about whether my new OSX/CI/Jenkins system can be integrated on build.kde.org’s Jenkins master as a valid slave for OSX. [1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status#Jenkinsintegration [2] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status#Installationofcmake [3] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status/KF5 [4] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status/ProjectsBeyondKF5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
