Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app
On Nov. 12, 2013, 10:49 p.m., Albert Astals Cid wrote:
About the .colors translations, we have this
./kdeui/colors/kcolordialog.cpp:104:{ 40.colors,
I18N_NOOP2(palette name, Forty Colors) },
./kdeui/colors/kcolordialog.cpp:105:{ Oxygen.colors,
I18N_NOOP2(palette name, Oxygen Colors) },
./kdeui/colors/kcolordialog.cpp:106:{ Rainbow.colors,
I18N_NOOP2(palette name, Rainbow Colors) },
./kdeui/colors/kcolordialog.cpp:107:{ Royal.colors,
I18N_NOOP2(palette name, Royal Colors) },
./kdeui/colors/kcolordialog.cpp:108:{ Web.colors,
I18N_NOOP2(palette name, Web Colors) },
Not sure if this is the only place that it's used or not. Maybe we need a
more central class that handles for you the search for *.colors and then
gives you both an internal name and an user visible name?
Martin Gräßlin wrote:
That doesn't look like a useable solution. Kcolordialog lives in
kde4support while the .colors are in kde-workspace. I think the translations
would need to go with the .colors files directly.
Hm... But what do the .colors files which are, as far as I know palettes, have
to do with color themes for apps?
- Boudewijn
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43557
---
On Nov. 12, 2013, 8:48 a.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/
---
(Updated Nov. 12, 2013, 8:48 a.m.)
Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and
Boudewijn Rempt.
Repository: kdelibs
Description
---
This class is inspired by functionality offered by e.g. Krita and
Digikam to allow the user to select a different color scheme for the
application.
This manager simplifies this task and also ensures that the required
property on QApplication is set, so that a QStyle can pass the scheme
to the window manager/compositor for the windows of the application.
@boud and @cgilles: please have a look whether this approach is sufficient
for your usecases in digkam and Krita.
Diffs
-
tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8
tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION
tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION
tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION
tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32
tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/113685/diff/
Testing
---
see demo application
Thanks,
Martin Gräßlin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Optional QtGui dependency for KDBusAddons?
On 13/11/13 05:38, Martin Gräßlin wrote: On Tuesday 12 November 2013 23:42:36 Alex Merry wrote: The latter is my personal preference (and I don't see any real issue with KDBusAddons optionally using something from Qt Essentials), but what are other people's thoughts? Could you explain why KDBusService has to care about the startupnotification at all? What would be the negative result if KDBusService doesn't handle it? Because I would say let's ignore it, transit to DBus and call it a day. Well, it's important for any application that specifies in its desktop file that it deals with startup notifications. Suppose you start a second instance of a Unique application. The DE running it doesn't necessarily know that it's the second instance or that it's unique, so it does the startup notification thing. *Someone* should remove it; the Qt xcb plugin won't because the temporary second instance never shows a window and the main instance doesn't get the startup notification id. Alternatively, if the app implements D-Bus Activation, the client can pass the desktop startup notification ID via the D-Bus call. The application still has to remove it. The other option, I guess, would be to put this in the API of KDBusService: allow the application to set the startup notification ID in the constructor, and send it out with the signals. Or just ignore it and have no support for startup notifications in Unique applications. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app
On Nov. 12, 2013, 10:49 p.m., Albert Astals Cid wrote:
About the .colors translations, we have this
./kdeui/colors/kcolordialog.cpp:104:{ 40.colors,
I18N_NOOP2(palette name, Forty Colors) },
./kdeui/colors/kcolordialog.cpp:105:{ Oxygen.colors,
I18N_NOOP2(palette name, Oxygen Colors) },
./kdeui/colors/kcolordialog.cpp:106:{ Rainbow.colors,
I18N_NOOP2(palette name, Rainbow Colors) },
./kdeui/colors/kcolordialog.cpp:107:{ Royal.colors,
I18N_NOOP2(palette name, Royal Colors) },
./kdeui/colors/kcolordialog.cpp:108:{ Web.colors,
I18N_NOOP2(palette name, Web Colors) },
Not sure if this is the only place that it's used or not. Maybe we need a
more central class that handles for you the search for *.colors and then
gives you both an internal name and an user visible name?
Martin Gräßlin wrote:
That doesn't look like a useable solution. Kcolordialog lives in
kde4support while the .colors are in kde-workspace. I think the translations
would need to go with the .colors files directly.
Boudewijn Rempt wrote:
Hm... But what do the .colors files which are, as far as I know palettes,
have to do with color themes for apps?
You are right, those are two different beasts. The palettes are only shown in
the color picker dialog, while the color themes are those that affect
application colors.
- Christoph
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43557
---
On Nov. 12, 2013, 8:48 a.m., Martin Gräßlin wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/
---
(Updated Nov. 12, 2013, 8:48 a.m.)
Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and
Boudewijn Rempt.
Repository: kdelibs
Description
---
This class is inspired by functionality offered by e.g. Krita and
Digikam to allow the user to select a different color scheme for the
application.
This manager simplifies this task and also ensures that the required
property on QApplication is set, so that a QStyle can pass the scheme
to the window manager/compositor for the windows of the application.
@boud and @cgilles: please have a look whether this approach is sufficient
for your usecases in digkam and Krita.
Diffs
-
tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8
tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION
tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION
tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION
tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32
tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/113685/diff/
Testing
---
see demo application
Thanks,
Martin Gräßlin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113821: Don't install kpagedialog_p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/#review43572 --- Ship it! I don't spot anything wrong. - Vishesh Handa On Nov. 12, 2013, 6:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 12, 2013, 6:46 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113821: Don't install kpagedialog_p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/#review43573 --- tier4/kcmutils/src/kcmultidialog.cpp http://git.reviewboard.kde.org/r/113821/#comment31313 I don't think this is right. If we copy a KCMultiDialog instance, we wouldn't copy the KPageDialog d variable of the parent object, but instead create a new one. I think this would be a behavioural change. - David Edmundson On Nov. 12, 2013, 6:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 12, 2013, 6:46 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ 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 #902
See http://build.kde.org/job/plasma-framework_master_qt5/902/changes Changes: [bhush94] Make plasma-framework build without tests -- [...truncated 254 lines...] [ 7%] Automatic moc for target platformcomponentsplugin Generating moc_modeltest.cpp Generating moc_columnproxymodel.cpp Generating moc_columnproxymodeltest.cpp [ 7%] Built target fullmodelaccesstest_automoc 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. Scanning dependencies of target localebindingsplugin_automoc [ 8%] 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 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 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. Automatic moc for target localebindingsplugin 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. 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 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. Generating moc_DeclarativeDragArea.cpp Generating moc_DeclarativeDragDropEvent.cpp Generating moc_DeclarativeDropArea.cpp Generating moc_DeclarativeMimeData.cpp Generating moc_draganddropplugin.cpp Generating moc_fallbackcomponent.cpp Generating moc_plasmaextracomponentsplugin.cpp [ 8%] [ 8%] Built target draganddropplugin_automoc Built target plasmaextracomponentsplugin_automoc Scanning dependencies of target calendarplugin_automoc [ 8%] Automatic moc for target calendarplugin Scanning dependencies of target plasmapkg_automoc 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. [ 9%] Automatic moc for target plasmapkg 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 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 platformextensionplugin.moc Generating moc_application.cpp Generating moc_application_p.cpp [ 9%] Generating qpixmapitem.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qpixmapitem.cpp:0: Note: No relevant classes found. No output generated. Built target platformcomponentsplugin_automoc Generating moc_plasmapkg.cpp [ 9%] Scanning dependencies of target kded_platformstatus_automoc Built target plasmapkg_automoc [ 10%] 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. Scanning dependencies of target plasma_appletscript_declarative_automoc Automatic moc for target kded_platformstatus [ 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 moc_calendarsystem.cpp Generating moc_locale_p.cpp Generating moc_localebindingsplugin.cpp [ 10%] Generating qtextracomponentsplugin.moc http://build.kde.org/job/plasma-framework_master_qt5/ws/src/declarativeimports/qtextracomponents/qtextracomponentsplugin.cpp:0: Note: No relevant classes found. No output generated. Built target localebindingsplugin_automoc Generating platformstatus.moc QIODevice::read: device not open 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. Scanning dependencies of target PlasmaQuick_automoc [ 11%] Automatic moc for target PlasmaQuick Generating moc_platformstatus.cpp [ 11%] Built target kded_platformstatus_automoc
Review Request 113834: Use FindOpenEXR.cmake from ECM
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113834/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Use FindOpenEXR.cmake from ECM That version sets the package DESCRIPTION and URL, so we should not. Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 6f02b71 tier4/kde4support/cmake/modules/CMakeLists.txt 6e7443c tier4/kde4support/cmake/modules/FindOpenEXR.cmake 93b05dd Diff: http://git.reviewboard.kde.org/r/113834/diff/ Testing --- Builds. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113821: Don't install kpagedialog_p.h
On Nov. 13, 2013, 11:53 a.m., David Edmundson wrote: tier4/kcmutils/src/kcmultidialog.cpp, line 262 http://git.reviewboard.kde.org/r/113821/diff/1/?file=213192#file213192line262 I don't think this is right. If we copy a KCMultiDialog instance, we wouldn't copy the KPageDialog d variable of the parent object, but instead create a new one. I think this would be a behavioural change. Well, if I'm not mistaken, it's the same that KPageDialog was doing already: KPageDialog::KPageDialog(KPageDialogPrivate dd, KPageWidget *widget, QWidget *parent, Qt::WindowFlags flags) : QDialog(parent, flags), d_ptr(dd) - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/#review43573 --- On Nov. 12, 2013, 6:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 12, 2013, 6:46 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ 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 #903
See http://build.kde.org/job/plasma-framework_master_qt5/903/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
On Nov. 12, 2013, 6:11 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 18 http://git.reviewboard.kde.org/r/113506/diff/5/?file=211419#file211419line18 I don't think we want that, superbuild shouldn't be used after the splitting but the kde build script. We will need it anyway and it will have all the needed information anyway. I did this to make it as simple as possible to use superbuild: no need to run cmake again, just use the already available targets. When superbuild is removed it can go away with it so I don't think it is a problem. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43533 --- On Nov. 7, 2013, 3:42 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 7, 2013, 3:42 p.m.) Review request for KDE Frameworks, Alexander Neundorf and Stephen Kelly. Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 13, 2013, 2:07 p.m.) Review request for Build System, KDE Frameworks, Alexander Neundorf, and Stephen Kelly. Changes --- Add buildsystem group to the groups Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113821: Don't install kpagedialog_p.h
On Nov. 13, 2013, 11:53 a.m., David Edmundson wrote: tier4/kcmutils/src/kcmultidialog.cpp, line 262 http://git.reviewboard.kde.org/r/113821/diff/1/?file=213192#file213192line262 I don't think this is right. If we copy a KCMultiDialog instance, we wouldn't copy the KPageDialog d variable of the parent object, but instead create a new one. I think this would be a behavioural change. Aleix Pol Gonzalez wrote: Well, if I'm not mistaken, it's the same that KPageDialog was doing already: KPageDialog::KPageDialog(KPageDialogPrivate dd, KPageWidget *widget, QWidget *parent, Qt::WindowFlags flags) : QDialog(parent, flags), d_ptr(dd) Previously your d pointer inherited from KPageDialog's d pointer. There was one instance of the private object, which KPageDialog copied. Now you have two instances of private objects and two d pointers. One in KMultiDialog, one in the superclass, KPageDialog. You copy the KMultiDialogPrivate object, but the private class in KPageDialog is not copied, as we never call the copy constructor in the superclass. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/#review43573 --- On Nov. 12, 2013, 6:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 12, 2013, 6:46 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 112874: Allow disabling of QCA plugins during build.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112874/ --- (Updated Nov. 13, 2013, 1:17 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Ivan Romanov. Repository: qca Description --- Add the ability to disable plugins, e.g. do not build the openssl plugins although OpenSSL was found in the system. This is a requirement that arose during packaging latest head for Gentoo. Diffs - CMakeLists.txt bdb77b4 INSTALL cf847a0 plugins/CMakeLists.txt 6e8a7a2 plugins/qca-botan/CMakeLists.txt 1b9607c plugins/qca-cyrus-sasl/CMakeLists.txt b36cbcf plugins/qca-gcrypt/CMakeLists.txt f5c73bd plugins/qca-gnupg/CMakeLists.txt 7f46abf plugins/qca-nss/CMakeLists.txt 805567d plugins/qca-ossl/CMakeLists.txt 6b5c69c plugins/qca-pkcs11/CMakeLists.txt b220926 plugins/qca-wincrypto/CMakeLists.txt c0ab378 Diff: http://git.reviewboard.kde.org/r/112874/diff/ Testing --- Compiled, installed and used on Gentoo (with Qt5). Thanks, Uwe L. Korn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdelibs/frameworks] /: Move cmake legacy to KDE4Support
On Tuesday 12 November 2013 20:36:21 Kevin Ottens wrote: Git commit f073b4561730ef50b4968b92b30cbcc32bccdc7e by Kevin Ottens. Committed on 12/11/2013 at 17:09. Pushed by ervin into branch 'frameworks'. Move cmake legacy to KDE4Support All the old CMake is now provided by KDE4Support as a porting aid. As a result, the top level CMakeLists.txt is as simple as possible. Nice, but I rather miss the dependencies summary. Another issue: tier4/kde4support/cmake/modules-tests/OpenEXR/CMakeLists.txt [from: cmake/modules-tests/OpenEXR/CMakeLists.txt - 100% similarity] R +0-0 OpenEXR is needed by tier1/kguiaddons/src/plugins/imageformats, it now omits building EXR support. Christoph Feck (kdepepo) KDE Quality Team ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43586 --- tier1/kdbusaddons/src/CMakeLists.txt http://git.reviewboard.kde.org/r/113830/#comment31321 Maybe this should be called org.kde.KDBusService.xml instead. It's an implementation detail of KDBusService. Application makes one think of KApplication/QApplication... tier1/kdbusaddons/src/kdbusservice.h http://git.reviewboard.kde.org/r/113830/#comment31322 When is this emitted, then? Only if the dbus-based app launcher calls Activate? Maybe launching the app with no cmdline arguments should call Activate instead of CommandLine, to keep things simple for apps that don't take cmdline args? Launching the app with no args really does mean activate. For apps that do handle cmdline args, they'll need to implement both anyway, whichever solution we choose, in order to follow the spec. So actually that's another reason for calling Activate if no args: otherwise app developers won't see the point in implementing activateRequested, since in their tests it will never be called, only the gnome app launcher (and one day the kde app launcher, presumably) calls that. Overall, I'm not sure what's the best solution, I'm open to suggestions. tier1/kdbusaddons/src/kdbusservice.h http://git.reviewboard.kde.org/r/113830/#comment31319 the the - the tier1/kdbusaddons/src/kdbusservice.cpp http://git.reviewboard.kde.org/r/113830/#comment31320 Hmm, the problem with a signal is that we can't get a return value, to return something on errors (e.g. invalid argument) rather than 0 It seems to me that we need an interface (in the C++ sense) that an object in the app would inherit from, with a virtual method int handleCommandLine(...). The app would set the instance of that interface in the KDBusService. Or just deriving from KDBusService, but I think a separate interface is cleaner - at least, too many years of virtuals in QApplication itself have shown various problems (too much of a monolithic design, for some apps). - David Faure On Nov. 13, 2013, 12:39 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 12:39 a.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/src/org.kde.Application.xml PRE-CREATION tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e24ca99da68222be9f728239b1fb0786f72 tier1/kdbusaddons/src/kdbusservice.cpp b773c80b30c6ee39d6d8b4d8c962b83dbd87f7d4 tier1/kdbusaddons/src/kdbusservice.h bf79e227209510246d0ec5ff1d5277e6083c4a1a tier1/kdbusaddons/src/CMakeLists.txt 0509015afd2d24d34f85a7d6fd786092820814bf tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e834bddc177539f5eedb51a77a276d7899 Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 1:52 p.m.) Review request for KDE Frameworks and David Faure. Changes --- Fix the API docs and the naming of the D-Bus interface. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs (updated) - tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
On Nov. 12, 2013, 5:11 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 18 http://git.reviewboard.kde.org/r/113506/diff/5/?file=211419#file211419line18 I don't think we want that, superbuild shouldn't be used after the splitting but the kde build script. We will need it anyway and it will have all the needed information anyway. Aurélien Gâteau wrote: I did this to make it as simple as possible to use superbuild: no need to run cmake again, just use the already available targets. When superbuild is removed it can go away with it so I don't think it is a problem. I have 2 kdelibs build directories: one with monolithic and one with superbuild, I don't feel like this is a problem to me. - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43533 --- On Nov. 13, 2013, 1:07 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 13, 2013, 1:07 p.m.) Review request for Build System, KDE Frameworks, Alexander Neundorf, and Stephen Kelly. Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/CMakeLists.txt, line 17 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213290#file213290line17 Maybe this should be called org.kde.KDBusService.xml instead. It's an implementation detail of KDBusService. Application makes one think of KApplication/QApplication... On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/kdbusservice.cpp, line 185 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213292#file213292line185 Hmm, the problem with a signal is that we can't get a return value, to return something on errors (e.g. invalid argument) rather than 0 It seems to me that we need an interface (in the C++ sense) that an object in the app would inherit from, with a virtual method int handleCommandLine(...). The app would set the instance of that interface in the KDBusService. Or just deriving from KDBusService, but I think a separate interface is cleaner - at least, too many years of virtuals in QApplication itself have shown various problems (too much of a monolithic design, for some apps). The other possibility I thought of was a setExitValue (or some similar name) method in KDBusService that the slot could call if it wanted to. Which is more ugly, but possibly easier on the application implentations. On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/kdbusservice.h, line 172 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213291#file213291line172 When is this emitted, then? Only if the dbus-based app launcher calls Activate? Maybe launching the app with no cmdline arguments should call Activate instead of CommandLine, to keep things simple for apps that don't take cmdline args? Launching the app with no args really does mean activate. For apps that do handle cmdline args, they'll need to implement both anyway, whichever solution we choose, in order to follow the spec. So actually that's another reason for calling Activate if no args: otherwise app developers won't see the point in implementing activateRequested, since in their tests it will never be called, only the gnome app launcher (and one day the kde app launcher, presumably) calls that. Overall, I'm not sure what's the best solution, I'm open to suggestions. I see your point, but at the same time, it makes less logical sense that way. Besides which, the activation stuff requires setting stuff in the desktop file anyway, so the application developer has to at least put *some* thought into it. Perhaps a flag? Say, DiscardCommandLineArguments or something, that basically says I don't deal with command-line arguments, so use activateRequested instead of applicationExecuted? - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43586 --- On Nov. 13, 2013, 1:52 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 1:52 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdelibs/frameworks] /: Move cmake legacy to KDE4Support
On 13/11/13 13:20, Christoph Feck wrote: On Tuesday 12 November 2013 20:36:21 Kevin Ottens wrote: tier4/kde4support/cmake/modules-tests/OpenEXR/CMakeLists.txt [from: cmake/modules-tests/OpenEXR/CMakeLists.txt - 100% similarity] R +0-0 OpenEXR is needed by tier1/kguiaddons/src/plugins/imageformats, it now omits building EXR support. I've got a couple of RRs fixing that: Add to ECM: https://git.reviewboard.kde.org/r/113828/ Remove from kdelibs: https://git.reviewboard.kde.org/r/113834/ Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/kdbusservice.h, line 172 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213291#file213291line172 When is this emitted, then? Only if the dbus-based app launcher calls Activate? Maybe launching the app with no cmdline arguments should call Activate instead of CommandLine, to keep things simple for apps that don't take cmdline args? Launching the app with no args really does mean activate. For apps that do handle cmdline args, they'll need to implement both anyway, whichever solution we choose, in order to follow the spec. So actually that's another reason for calling Activate if no args: otherwise app developers won't see the point in implementing activateRequested, since in their tests it will never be called, only the gnome app launcher (and one day the kde app launcher, presumably) calls that. Overall, I'm not sure what's the best solution, I'm open to suggestions. Alex Merry wrote: I see your point, but at the same time, it makes less logical sense that way. Besides which, the activation stuff requires setting stuff in the desktop file anyway, so the application developer has to at least put *some* thought into it. Perhaps a flag? Say, DiscardCommandLineArguments or something, that basically says I don't deal with command-line arguments, so use activateRequested instead of applicationExecuted? Another option is to just merge the activateRequested() and applicationStarted(QStringList) signals into a single activateRequested(QStringList) signal that is passed an empty list if it is triggered by the D-Bus Activate call. This still leaves the fact that it will have to deal with the command-line equivalents of the Open and ActivateAction D-Bus calls, so I feel it is a conceptually inferior option, even if it typically allows slightly less application code. - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43586 --- On Nov. 13, 2013, 1:52 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 1:52 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
On Nov. 12, 2013, 6:11 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 18 http://git.reviewboard.kde.org/r/113506/diff/5/?file=211419#file211419line18 I don't think we want that, superbuild shouldn't be used after the splitting but the kde build script. We will need it anyway and it will have all the needed information anyway. Aurélien Gâteau wrote: I did this to make it as simple as possible to use superbuild: no need to run cmake again, just use the already available targets. When superbuild is removed it can go away with it so I don't think it is a problem. Aleix Pol Gonzalez wrote: I have 2 kdelibs build directories: one with monolithic and one with superbuild, I don't feel like this is a problem to me. Sure it is not, but you made a conscious effort to set it up. Furthermore, not requiring a separate build dir makes like easier for build.kde.org maintainers: they just need to add another target to the make call. - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43533 --- On Nov. 13, 2013, 2:07 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 13, 2013, 2:07 p.m.) Review request for Build System, KDE Frameworks, Alexander Neundorf, and Stephen Kelly. Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113506: Add a sb_all target and sb_$framework targets to make it easier to build frameworks standalone
On Nov. 12, 2013, 5:11 p.m., Aleix Pol Gonzalez wrote: CMakeLists.txt, line 18 http://git.reviewboard.kde.org/r/113506/diff/5/?file=211419#file211419line18 I don't think we want that, superbuild shouldn't be used after the splitting but the kde build script. We will need it anyway and it will have all the needed information anyway. Aurélien Gâteau wrote: I did this to make it as simple as possible to use superbuild: no need to run cmake again, just use the already available targets. When superbuild is removed it can go away with it so I don't think it is a problem. Aleix Pol Gonzalez wrote: I have 2 kdelibs build directories: one with monolithic and one with superbuild, I don't feel like this is a problem to me. Aurélien Gâteau wrote: Sure it is not, but you made a conscious effort to set it up. Furthermore, not requiring a separate build dir makes like easier for build.kde.org maintainers: they just need to add another target to the make call. Well, I'd say that we probably want to have a separate install for both in bko. I have no idea of how hard this is to set up in jenkins, if the goal is to make it possible for build.kde.org to test it, I won't oppose. - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/#review43533 --- On Nov. 13, 2013, 1:07 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113506/ --- (Updated Nov. 13, 2013, 1:07 p.m.) Review request for Build System, KDE Frameworks, Alexander Neundorf, and Stephen Kelly. Repository: kdelibs Description --- This patch rework superbuild to integrate it more closely with kdelibs build system: one no longer needs to run cmake path/to/kdelibs/superbuild separately. Instead targets are created for all frameworks declared in superbuild/CMakeLists.txt. For example to build and install ki18n standalone, one can run `make sb_ki18n`. It also adds a special sb_all target, which builds and install all standalone frameworks. Diffs - CMakeLists.txt 879fed4 superbuild/CMakeLists.txt cbe9630 superbuild/README 7a4e52e superbuild/SuperBuild.cmake 33ed151 Diff: http://git.reviewboard.kde.org/r/113506/diff/ Testing --- kdelibs still builds standalone, all sb_* targets work as expected. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kdelibs_frameworks_qt5 #1661
See http://build.kde.org/job/kdelibs_frameworks_qt5/1661/changes Changes: [aleixpol] Move KIO to tier3 -- [...truncated 198 lines...] -- Looking for include file valgrind/memcheck.h -- Looking for include file valgrind/memcheck.h - not found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Looking for include file sys/time.h -- Looking for include file sys/time.h - found -- Looking for include file errno.h -- Looking for include file errno.h - found -- Looking for include file strings.h -- Looking for include file strings.h - found -- Looking for include file crtdbg.h -- Looking for include file crtdbg.h - not found -- Performing Test HAVE_TM_GMTOFF -- Performing Test HAVE_TM_GMTOFF - Success -- Looking for _finite -- Looking for _finite - not found -- Looking for finite -- Looking for finite - found -- Looking for posix_memalign -- Looking for posix_memalign - found -- Looking for gettimeofday -- Looking for gettimeofday - found -- Looking for isnan -- Looking for isnan - found -- Looking for isinf -- Looking for isinf - found -- Performing Test __KDE_HAVE_GCC_VISIBILITY -- Performing Test __KDE_HAVE_GCC_VISIBILITY - Success -- Looking for PCRE_CONFIG_UTF8 -- Looking for PCRE_CONFIG_UTF8 - found -- Looking for PCRE_CONFIG_STACKRECURSE -- Looking for PCRE_CONFIG_STACKRECURSE - found -- No backend for KAuth was explicitly specified: probing system to find the best one available -- Could NOT find PolkitQt-1 (missing: PolkitQt-1_CONFIG) (Required is at least version 0.99.0) -- Could NOT find PolkitQt (missing: POLKITQT_GUI_LIBRARY POLKITQT_CORE_LIBRARY POLKITQT_INCLUDE_DIR) (Required is at least version 0.9.3) -- Building Fake KAuth backend WARNING: No valid KAuth backends will be built. The library will not work properly unless compiled with a working backend -- Looking for strlcpy -- Looking for strlcpy - not found -- Checking prototype strlcpy for HAVE_STRLCPY_PROTO - False -- Looking for include file string.h -- Looking for include file string.h - found -- DBusMenuQt5_INCLUDE_DIR=/srv/jenkins/install/linux/x86_64/g++/qt5/shared/include/dbusmenu-qt5 DBusMenuQt5_LIBRARY=/srv/jenkins/install/linux/x86_64/g++/qt5/shared/lib64/libdbusmenu-qt5.so DBusMenuQt5_VERSION= -- NOW DBusMenuQt5_VERSION=0.9.2 -- Found DBusMenuQt5: /srv/jenkins/install/linux/x86_64/g++/qt5/shared/lib64/libdbusmenu-qt5.so (found version 0.9.2) -- Found LibXslt: /usr/lib64/libxslt.so (found version 1.1.28) -- Found LibXml2: /usr/lib64/libxml2.so (found version 2.9.0) -- Found DocBookXML: /usr/share/xml/docbook/schema/dtd/4.2 -- Found DocBookXSL: /usr/share/xml/docbook/stylesheet/nwalsh/current -- Looking for include file stdio.h -- Looking for include file stdio.h - found -- Looking for include file stdlib.h -- Looking for include file stdlib.h - found -- Looking for include file sys/stat.h -- Looking for include file sys/stat.h - found -- Found Avahi: /usr/include CMake Warning (dev) at tier3/kdewidgets/src/CMakeLists.txt:29 (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 makekdewidgets. Use the target name directly with add_custom_command, or use the generator expression $TARGET_FILE, as appropriate. This warning is for project developers. Use -Wno-dev to suppress it. -- Looking for mmap -- Looking for mmap - found -- Looking for posix_madvise -- Looking for posix_madvise - not found -- Looking for __progname -- Looking for __progname - found -- Looking for __progname_full -- Looking for __progname_full - found -- Looking for include file sys/pstat.h -- Looking for include file sys/pstat.h - not found -- Looking for include file sys/select.h -- Looking for include file sys/select.h - found -- Looking for include file sys/exec.h -- Looking for include file sys/exec.h - not found -- Looking for pstat -- Looking for pstat - not found -- Looking for setproctitle -- Looking for setproctitle - not found -- Looking for connect in socket -- Looking for connect in socket - not found -- Using setuid root kdeinit wrapper in order to protect it from bad Linux OOM-killer -- Looking for backtrace -- Looking for backtrace - found -- Performing Test HAVE_STRUCT_SOCKADDR_SA_LEN -- Performing Test HAVE_STRUCT_SOCKADDR_SA_LEN - Failed -- Looking for include file attr/libattr.h -- Looking for include file attr/libattr.h - found -- Looking for include file sys/xattr.h -- Looking for include file sys/xattr.h - found -- Looking for include file sys/acl.h -- Looking for include file sys/acl.h - found -- Looking for include file acl/libacl.h -- Looking for include file acl/libacl.h - found -- Found ACL support: /usr/lib64/libacl.so;/usr/lib64/libattr.so -- Looking for include file sys/mntent.h -- Looking for
Re: Review Request 113821: Don't install kpagedialog_p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/#review43603 --- This review has been submitted with commit fc714169fb713bb74246c0be6ec5a25d99245bc1 by Aleix Pol to branch frameworks. - Commit Hook On Nov. 12, 2013, 6:46 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 12, 2013, 6:46 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113821: Don't install kpagedialog_p.h
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113821/ --- (Updated Nov. 13, 2013, 3:43 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- This makes sure that KWidgetsAddons doesn't expose any private dependencies. The only user of that file was KCMultiDialogPrivate. This patch refactors the code so that it's used separately. Diffs - tier1/kwidgetsaddons/src/CMakeLists.txt 76679a4 tier4/kcmutils/src/kcmultidialog.h 3518736 tier4/kcmutils/src/kcmultidialog.cpp 9d2ccbb tier4/kcmutils/src/kcmultidialog_p.h ad5dd98 Diff: http://git.reviewboard.kde.org/r/113821/diff/ Testing --- Everything builds, couldn't test since I didn't see any test. Tests still pass though. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/kdbusservice.h, line 172 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213291#file213291line172 When is this emitted, then? Only if the dbus-based app launcher calls Activate? Maybe launching the app with no cmdline arguments should call Activate instead of CommandLine, to keep things simple for apps that don't take cmdline args? Launching the app with no args really does mean activate. For apps that do handle cmdline args, they'll need to implement both anyway, whichever solution we choose, in order to follow the spec. So actually that's another reason for calling Activate if no args: otherwise app developers won't see the point in implementing activateRequested, since in their tests it will never be called, only the gnome app launcher (and one day the kde app launcher, presumably) calls that. Overall, I'm not sure what's the best solution, I'm open to suggestions. Alex Merry wrote: I see your point, but at the same time, it makes less logical sense that way. Besides which, the activation stuff requires setting stuff in the desktop file anyway, so the application developer has to at least put *some* thought into it. Perhaps a flag? Say, DiscardCommandLineArguments or something, that basically says I don't deal with command-line arguments, so use activateRequested instead of applicationExecuted? Alex Merry wrote: Another option is to just merge the activateRequested() and applicationStarted(QStringList) signals into a single activateRequested(QStringList) signal that is passed an empty list if it is triggered by the D-Bus Activate call. This still leaves the fact that it will have to deal with the command-line equivalents of the Open and ActivateAction D-Bus calls, so I feel it is a conceptually inferior option, even if it typically allows slightly less application code. Alex Merry wrote: Also, connect(service, SIGNAL(applicationStarted(QStringList)), service, SIGNAL(activateRequested())) is a single line of code. I like the idea of activateRequested(QStringList). It's also closer to our current kde4 code (MyUniqueApplication::newInstance(), which then calls KCmdLineArgs::parsedArgs() to parse the args). It makes me wonder why the spec doesn't just have that, then... well I because it was written with gui app launchers in mind, the command-line case is an additional feature. Apps have to deal with the command-line equivalent of Open in any case - which is usually passing urls on the command line, I don't see how merging two signals changes that. Same for actions (e.g. kmail --compose). All of this is exactly what newInstance() currently deals with, and what apps would have to do in their slotActivateRequested(). On Nov. 13, 2013, 1:33 p.m., David Faure wrote: tier1/kdbusaddons/src/kdbusservice.cpp, line 185 http://git.reviewboard.kde.org/r/113830/diff/1/?file=213292#file213292line185 Hmm, the problem with a signal is that we can't get a return value, to return something on errors (e.g. invalid argument) rather than 0 It seems to me that we need an interface (in the C++ sense) that an object in the app would inherit from, with a virtual method int handleCommandLine(...). The app would set the instance of that interface in the KDBusService. Or just deriving from KDBusService, but I think a separate interface is cleaner - at least, too many years of virtuals in QApplication itself have shown various problems (too much of a monolithic design, for some apps). Alex Merry wrote: The other possibility I thought of was a setExitValue (or some similar name) method in KDBusService that the slot could call if it wanted to. Which is more ugly, but possibly easier on the application implentations. True. This might be good enough. - David --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43586 --- On Nov. 13, 2013, 1:52 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 1:52 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80
Re: [kdelibs/frameworks] /: Move cmake legacy to KDE4Support
On Wednesday 13 November 2013 14:20:45 Christoph Feck wrote: On Tuesday 12 November 2013 20:36:21 Kevin Ottens wrote: Git commit f073b4561730ef50b4968b92b30cbcc32bccdc7e by Kevin Ottens. Committed on 12/11/2013 at 17:09. Pushed by ervin into branch 'frameworks'. Move cmake legacy to KDE4Support All the old CMake is now provided by KDE4Support as a porting aid. As a result, the top level CMakeLists.txt is as simple as possible. Nice, but I rather miss the dependencies summary. Another issue: OK, I'll reintroduce that soon. tier4/kde4support/cmake/modules-tests/OpenEXR/CMakeLists.txt [from: cmake/modules-tests/OpenEXR/CMakeLists.txt - 100% similarity] R +0-0 OpenEXR is needed by tier1/kguiaddons/src/plugins/imageformats, it now omits building EXR support. Good catch. Let's try to get Alex patch in as soon as possible. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/#review43607 --- tier3/kconfigwidgets/src/kcolorschememanager.h http://git.reviewboard.kde.org/r/113685/#comment31353 Missing @since 5.0 tier3/kconfigwidgets/src/kcolorschememanager.h http://git.reviewboard.kde.org/r/113685/#comment31352 remove space after Qt:: tier3/kconfigwidgets/src/kcolorschememanager.cpp http://git.reviewboard.kde.org/r/113685/#comment31354 this is still a C++11 initializer list, which isn't in the wiki page of allowed C++11 constructs in KF5, is it? tier3/kconfigwidgets/tests/kcolorschemedemo.cpp http://git.reviewboard.kde.org/r/113685/#comment31355 stray semicolon - David Faure On Nov. 12, 2013, 8:48 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/ --- (Updated Nov. 12, 2013, 8:48 a.m.) Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and Boudewijn Rempt. Repository: kdelibs Description --- This class is inspired by functionality offered by e.g. Krita and Digikam to allow the user to select a different color scheme for the application. This manager simplifies this task and also ensures that the required property on QApplication is set, so that a QStyle can pass the scheme to the window manager/compositor for the windows of the application. @boud and @cgilles: please have a look whether this approach is sufficient for your usecases in digkam and Krita. Diffs - tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113685/diff/ Testing --- see demo application Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 5:09 p.m.) Review request for KDE Frameworks and David Faure. Changes --- Merge the applicationExecuted and activateRequested signals; add setExitValue(int) method. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs (updated) - tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43616 --- Why is it tier3? It doesn't seem to depend on anything, no? - Aleix Pol Gonzalez On Nov. 13, 2013, 5:16 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 5:16 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113845: Remove unnecessary dependencies in kauth
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- There is no reference to QtConcurrent, or QtTest outside of autotests, so there's no need to search for it (QtTest is still pulled in autotests/). Diffs - tier2/kauth/CMakeLists.txt 86462232d0ffb4d8e1f42600da627e0e26e308af Diff: http://git.reviewboard.kde.org/r/113845/diff/ Testing --- Builds and passes tests with QtConcurrent not installed. Non-test components build without having QtTest installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43618 --- Of course, if we wanted to support Ryan's use cases (like text editor use by git), thing's get a little more complicated. He basically suggests the route of standardising application arguments, AFAICS, but even without that, I think he's right about wanting to pass the current working directory, and possibly also the environment. - Alex Merry On Nov. 13, 2013, 5:09 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 5:09 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
On Nov. 13, 2013, 10:22 a.m., Aleix Pol Gonzalez wrote: Why is it tier3? It doesn't seem to depend on anything, no? No it doesn't depend on anything, but is specific to kde platform. I put it into tier3 because that's what I was told in the meeting, maybe another tier makes more sense though. - Jeremy --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43616 --- On Nov. 13, 2013, 10:16 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 10:16 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml tier3/CMakeLists.txt c801fd299d95f64d28676f80e86e2c86f9b39024 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app
On Nov. 13, 2013, 5:41 p.m., David Faure wrote: tier3/kconfigwidgets/src/kcolorschememanager.cpp, line 93 http://git.reviewboard.kde.org/r/113685/diff/2/?file=212585#file212585line93 this is still a C++11 initializer list, which isn't in the wiki page of allowed C++11 constructs in KF5, is it? according to Wikipedia this is valid C++03 code. See https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists - Martin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/#review43607 --- On Nov. 12, 2013, 9:48 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/ --- (Updated Nov. 12, 2013, 9:48 a.m.) Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and Boudewijn Rempt. Repository: kdelibs Description --- This class is inspired by functionality offered by e.g. Krita and Digikam to allow the user to select a different color scheme for the application. This manager simplifies this task and also ensures that the required property on QApplication is set, so that a QStyle can pass the scheme to the window manager/compositor for the windows of the application. @boud and @cgilles: please have a look whether this approach is sufficient for your usecases in digkam and Krita. Diffs - tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113685/diff/ Testing --- see demo application Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113847: Remove unnecessary dependency in dnssd
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- I cannot find any reference to QtWidgets, so there's no point trying to find it. Diffs - tier2/dnssd/CMakeLists.txt 13497d199be73c0d6ce3038005543837311f46e5 Diff: http://git.reviewboard.kde.org/r/113847/diff/ Testing --- Builds with QtWidgets not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 11:01 a.m.) Review request for KDE Frameworks. Changes --- Updated to move to staging since the final tier isn't decided yet. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs (updated) - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43621 --- Ship it! Ship It! - Aleix Pol Gonzalez On Nov. 13, 2013, 6:01 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 6:01 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 6:57 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113844: Move kspeech interface to tier3
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/#review43622 --- This review has been submitted with commit c18ffcc197a6106f2f1136cac4bcd32a63b6ca17 by Jeremy Whiting to branch frameworks. - Commit Hook On Nov. 13, 2013, 6:01 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113844/ --- (Updated Nov. 13, 2013, 6:01 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- It builds and installs. Will make it conform to framework structure with src/ and whatnot after this is shipped. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kspeech/CMakeLists.txt interfaces/kspeech/Mainpage.dox interfaces/kspeech/dbustexttospeech.desktop interfaces/kspeech/kspeech.h interfaces/kspeech/org.kde.KSpeech.xml staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 Diff: http://git.reviewboard.kde.org/r/113844/diff/ Testing --- Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113798: KDBusService: pass the desktop startup ID when calling Activate
On Nov. 11, 2013, 5:45 p.m., David Faure wrote: Thanks for implementing that. Indeed the TODO didn't mean adding a method to QApplication, but it was about the member that was there in qt4, and that is now in QXcbConnection. The optional dependency on QtGui breaks the rules for tier1 addons, though. Maybe we need to move KDBusService up to... the KService framework maybe? (Note that there are more todos about startupId stuff, in KDBusService::Activate etc. This would probably be easier to implement in a higher framework too. Alex Merry wrote: Oh? I can't find a rule on the wiki that precludes it. Regardless, the other TODOs would be a lot easier from tier2 or above, where we could use KStartupInfo from KWindowSystem. KService probably does make the most sense out of what we have, although it's still a bit mismatched (I wouldn't expect to need KService if my application didn't use plugins). Is there maybe a use for a framework that provides things to help make apps behave well in free desktop environments? I would still prefer having KDBusService stay there... What about doing the xcb connection dance in our platform theme plugin instead? And then attaching a dynamic property on the qapp instance? This way we can channel the startup id, and from KDBusService POV it only needs to know about QCoreApplication. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113798/#review43449 --- On Nov. 11, 2013, 4:37 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113798/ --- (Updated Nov. 11, 2013, 4:37 p.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- KDBusService: pass the desktop startup ID when calling Activate We use a bit of private API to ask the xcb platform plugin for it directly. The TODO in the original code suggested getting a method in QApplication (or one of its ancestors) to get the startup id, but I think that's very unlikely to be accepted. There's still the hooks to make use of the value on the other side to sort out, though. Diffs - tier1/kdbusaddons/CMakeLists.txt 78cc44333574355ff8504481fcb9c88cfc90daf5 tier1/kdbusaddons/src/CMakeLists.txt 0509015afd2d24d34f85a7d6fd786092820814bf tier1/kdbusaddons/src/config-kdbusaddons.h.cmake PRE-CREATION tier1/kdbusaddons/src/kdbusservice.cpp b773c80b30c6ee39d6d8b4d8c962b83dbd87f7d4 Diff: http://git.reviewboard.kde.org/r/113798/diff/ Testing --- Builds, tests pass. A quick-hack modification of the autotest, along with some hacked-in debug statements, show the value is getting passed properly. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113792: Fix Build of KDNSSD with DNSSD Backend
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/#review43628 --- Ship it! Ship It! - Kevin Ottens On Nov. 11, 2013, 1:32 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/ --- (Updated Nov. 11, 2013, 1:32 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjusting the code to changes in Qt5. The nature of the changes makes me wonder if this code is maintained at all or if the DNSSD backend should be dropped. Diffs - tier2/dnssd/src/mdnsd-servicebrowser.cpp 37449db tier2/dnssd/src/mdnsd-publicservice.cpp 5da6f97 tier2/dnssd/src/mdnsd-domainbrowser.cpp 21c359e tier2/dnssd/src/CMakeLists.txt c71ade2 tier2/dnssd/CMakeLists.txt 13497d1 Diff: http://git.reviewboard.kde.org/r/113792/diff/ Testing --- 1. Configure KDNSSD with -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 2. Build Builds successfully. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113683: Fix kdeclarative standalone build
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113683/#review43629 --- Ship it! Ship It! - Kevin Ottens On Nov. 12, 2013, 7:52 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113683/ --- (Updated Nov. 12, 2013, 7:52 p.m.) Review request for KDE Frameworks, Aleix Pol Gonzalez and Aurélien Gâteau. Repository: kdelibs Description --- Make kdeclarative build standalone. Do I need to add the dependencies of all dependencies as well now? Diffs - superbuild/CMakeLists.txt 56e17dd42a8cc2b2c8a0015c7c5ec74902e0bd3e tier3/kdeclarative/CMakeLists.txt 1f23914a0ba65982c7b597e92fe9c9e920e2abe6 Diff: http://git.reviewboard.kde.org/r/113683/diff/ Testing --- Builds. 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 113825: Move kmediaplayer to staging (and fix its CMake files)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113825/#review43630 --- Ship it! Ship It! - Kevin Ottens On Nov. 12, 2013, 10:09 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113825/ --- (Updated Nov. 12, 2013, 10:09 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Move kmediaplayer to staging (and fix its CMake files) This moves kmediaplayer to staging as its own frameworks, rearranges its directory structure and fixes its CMake files. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kmediaplayer/CMakeLists.txt 0f087c7f026cfd123251cbac9ecf40d12318a907 interfaces/kmediaplayer/Mainpage.dox interfaces/kmediaplayer/kfileaudiopreview/CMakeLists.txt 56ef84d2cac87f9f762c6470ff136c87cf39ed25 interfaces/kmediaplayer/kfileaudiopreview/Messages.sh interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.h interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.h interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols_p.h interfaces/kmediaplayer/kmediaplayer.desktop interfaces/kmediaplayer/kmediaplayeradaptor.cpp interfaces/kmediaplayer/kmediaplayeradaptor_p.h interfaces/kmediaplayer/kmediaplayerengine.desktop interfaces/kmediaplayer/org.kde.KMediaPlayer.xml interfaces/kmediaplayer/player.h 64275e127d9e9580de7ab7c6675ab8d8b83fe651 interfaces/kmediaplayer/player.cpp 531d96847c847b5ca970141c37afc936705bda8c interfaces/kmediaplayer/view.h interfaces/kmediaplayer/view.cpp 0f3cbd53f600d4d75b278d2183e4214372ab85cd staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 staging/kmediaplayer/CMakeLists.txt PRE-CREATION staging/kmediaplayer/KMediaPlayerConfig.cmake.in PRE-CREATION staging/kmediaplayer/src/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kfileaudiopreview/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kmediaplayer/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113825/diff/ Testing --- Builds, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113827: CMake: refer to target directly instead of getting LOCATION property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113827/#review43631 --- Ship it! Ship It! - Kevin Ottens On Nov. 12, 2013, 10:29 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113827/ --- (Updated Nov. 12, 2013, 10:29 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- CMake: refer to target directly instead of getting LOCATION property This silences an annoying CMake warning. Diffs - tier3/kdewidgets/src/CMakeLists.txt b376db89543aa4097045beabe9596eee0800e825 Diff: http://git.reviewboard.kde.org/r/113827/diff/ Testing --- Re-running cmake no longer has the warning. After removing kdewidgets.cpp from the build directory and running make, it is regenerated correctly. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113834: Use FindOpenEXR.cmake from ECM
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113834/#review43632 --- Ship it! Once 113828 is in of course - Kevin Ottens On Nov. 13, 2013, 12:33 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113834/ --- (Updated Nov. 13, 2013, 12:33 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Use FindOpenEXR.cmake from ECM That version sets the package DESCRIPTION and URL, so we should not. Diffs - tier1/kguiaddons/src/plugins/imageformats/CMakeLists.txt 6f02b71 tier4/kde4support/cmake/modules/CMakeLists.txt 6e7443c tier4/kde4support/cmake/modules/FindOpenEXR.cmake 93b05dd Diff: http://git.reviewboard.kde.org/r/113834/diff/ Testing --- Builds. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113845: Remove unnecessary dependencies in kauth
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/#review43633 --- Ship it! Ship It! - Kevin Ottens On Nov. 13, 2013, 5:33 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113845/ --- (Updated Nov. 13, 2013, 5:33 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- There is no reference to QtConcurrent, or QtTest outside of autotests, so there's no need to search for it (QtTest is still pulled in autotests/). Diffs - tier2/kauth/CMakeLists.txt 86462232d0ffb4d8e1f42600da627e0e26e308af Diff: http://git.reviewboard.kde.org/r/113845/diff/ Testing --- Builds and passes tests with QtConcurrent not installed. Non-test components build without having QtTest installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113830: Allow unique apps to access command-line arguments of later invocations
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/#review43634 --- tier1/kdbusaddons/src/kdbusservice.h http://git.reviewboard.kde.org/r/113830/#comment31363 to be emitted - Kevin Ottens On Nov. 13, 2013, 5:09 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113830/ --- (Updated Nov. 13, 2013, 5:09 p.m.) Review request for KDE Frameworks and David Faure. Repository: kdelibs Description --- Allow unique apps to access command-line arguments of later invocations Diffs - tier1/kdbusaddons/src/CMakeLists.txt 0509015 tier1/kdbusaddons/src/kdbusservice.h bf79e22 tier1/kdbusaddons/src/kdbusservice.cpp b773c80 tier1/kdbusaddons/src/org.freedesktop.Application.xml 16934e2 tier1/kdbusaddons/src/org.kde.KDBusService.xml PRE-CREATION tier1/kdbusaddons/autotests/kdbusservicetest.cpp 5eecb5e Diff: http://git.reviewboard.kde.org/r/113830/diff/ Testing --- Builds, test passes. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app
On Nov. 13, 2013, 4:41 p.m., David Faure wrote: tier3/kconfigwidgets/src/kcolorschememanager.cpp, line 93 http://git.reviewboard.kde.org/r/113685/diff/2/?file=212585#file212585line93 this is still a C++11 initializer list, which isn't in the wiki page of allowed C++11 constructs in KF5, is it? Martin Gräßlin wrote: according to Wikipedia this is valid C++03 code. See https://en.wikipedia.org/wiki/C%2B%2B11#Initializer_lists Yep, it's a good old struct so that's fine. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/#review43607 --- On Nov. 12, 2013, 8:48 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/ --- (Updated Nov. 12, 2013, 8:48 a.m.) Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and Boudewijn Rempt. Repository: kdelibs Description --- This class is inspired by functionality offered by e.g. Krita and Digikam to allow the user to select a different color scheme for the application. This manager simplifies this task and also ensures that the required property on QApplication is set, so that a QStyle can pass the scheme to the window manager/compositor for the windows of the application. @boud and @cgilles: please have a look whether this approach is sufficient for your usecases in digkam and Krita. Diffs - tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113685/diff/ Testing --- see demo application Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113847: Remove unnecessary dependency in dnssd
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/#review43636 --- Ship it! Ship It! - Kevin Ottens On Nov. 13, 2013, 5:53 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113847/ --- (Updated Nov. 13, 2013, 5:53 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- I cannot find any reference to QtWidgets, so there's no point trying to find it. Diffs - tier2/dnssd/CMakeLists.txt 13497d199be73c0d6ce3038005543837311f46e5 Diff: http://git.reviewboard.kde.org/r/113847/diff/ Testing --- Builds with QtWidgets not installed. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113792: Fix Build of KDNSSD with DNSSD Backend
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/#review43639 --- This review has been submitted with commit f79e0f903e0d3aee44c23c1d64b297fb6d31 by David E. Narvaez to branch frameworks. - Commit Hook On Nov. 11, 2013, 1:32 a.m., David Narváez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/ --- (Updated Nov. 11, 2013, 1:32 a.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Adjusting the code to changes in Qt5. The nature of the changes makes me wonder if this code is maintained at all or if the DNSSD backend should be dropped. Diffs - tier2/dnssd/src/mdnsd-servicebrowser.cpp 37449db tier2/dnssd/src/mdnsd-publicservice.cpp 5da6f97 tier2/dnssd/src/mdnsd-domainbrowser.cpp 21c359e tier2/dnssd/src/CMakeLists.txt c71ade2 tier2/dnssd/CMakeLists.txt 13497d1 Diff: http://git.reviewboard.kde.org/r/113792/diff/ Testing --- 1. Configure KDNSSD with -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 2. Build Builds successfully. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113792: Fix Build of KDNSSD with DNSSD Backend
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113792/ --- (Updated Nov. 13, 2013, 10:26 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Adjusting the code to changes in Qt5. The nature of the changes makes me wonder if this code is maintained at all or if the DNSSD backend should be dropped. Diffs - tier2/dnssd/src/mdnsd-servicebrowser.cpp 37449db tier2/dnssd/src/mdnsd-publicservice.cpp 5da6f97 tier2/dnssd/src/mdnsd-domainbrowser.cpp 21c359e tier2/dnssd/src/CMakeLists.txt c71ade2 tier2/dnssd/CMakeLists.txt 13497d1 Diff: http://git.reviewboard.kde.org/r/113792/diff/ Testing --- 1. Configure KDNSSD with -DCMAKE_DISABLE_FIND_PACKAGE_Avahi=1 2. Build Builds successfully. Thanks, David Narváez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113825: Move kmediaplayer to staging (and fix its CMake files)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113825/ --- (Updated Nov. 14, 2013, 12:05 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Move kmediaplayer to staging (and fix its CMake files) This moves kmediaplayer to staging as its own frameworks, rearranges its directory structure and fixes its CMake files. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kmediaplayer/CMakeLists.txt 0f087c7f026cfd123251cbac9ecf40d12318a907 interfaces/kmediaplayer/Mainpage.dox interfaces/kmediaplayer/kfileaudiopreview/CMakeLists.txt 56ef84d2cac87f9f762c6470ff136c87cf39ed25 interfaces/kmediaplayer/kfileaudiopreview/Messages.sh interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.h interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.h interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols_p.h interfaces/kmediaplayer/kmediaplayer.desktop interfaces/kmediaplayer/kmediaplayeradaptor.cpp interfaces/kmediaplayer/kmediaplayeradaptor_p.h interfaces/kmediaplayer/kmediaplayerengine.desktop interfaces/kmediaplayer/org.kde.KMediaPlayer.xml interfaces/kmediaplayer/player.h 64275e127d9e9580de7ab7c6675ab8d8b83fe651 interfaces/kmediaplayer/player.cpp 531d96847c847b5ca970141c37afc936705bda8c interfaces/kmediaplayer/view.h interfaces/kmediaplayer/view.cpp 0f3cbd53f600d4d75b278d2183e4214372ab85cd staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 staging/kmediaplayer/CMakeLists.txt PRE-CREATION staging/kmediaplayer/KMediaPlayerConfig.cmake.in PRE-CREATION staging/kmediaplayer/src/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kfileaudiopreview/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kmediaplayer/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113825/diff/ Testing --- Builds, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113827: CMake: refer to target directly instead of getting LOCATION property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113827/#review43643 --- This review has been submitted with commit c28742fbfebb98582b9c1cc68b0c5914ad3180d4 by Alex Merry to branch frameworks. - Commit Hook On Nov. 12, 2013, 10:29 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113827/ --- (Updated Nov. 12, 2013, 10:29 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- CMake: refer to target directly instead of getting LOCATION property This silences an annoying CMake warning. Diffs - tier3/kdewidgets/src/CMakeLists.txt b376db89543aa4097045beabe9596eee0800e825 Diff: http://git.reviewboard.kde.org/r/113827/diff/ Testing --- Re-running cmake no longer has the warning. After removing kdewidgets.cpp from the build directory and running make, it is regenerated correctly. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113825: Move kmediaplayer to staging (and fix its CMake files)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113825/#review43642 --- This review has been submitted with commit f3a33e60d5c58e12dc841fb938c38ef535f6e496 by Alex Merry to branch frameworks. - Commit Hook On Nov. 12, 2013, 10:09 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113825/ --- (Updated Nov. 12, 2013, 10:09 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Move kmediaplayer to staging (and fix its CMake files) This moves kmediaplayer to staging as its own frameworks, rearranges its directory structure and fixes its CMake files. Diffs - interfaces/CMakeLists.txt 9fa4e1b23e4671dae25518c9d8d3fe1369f9b1a6 interfaces/kmediaplayer/CMakeLists.txt 0f087c7f026cfd123251cbac9ecf40d12318a907 interfaces/kmediaplayer/Mainpage.dox interfaces/kmediaplayer/kfileaudiopreview/CMakeLists.txt 56ef84d2cac87f9f762c6470ff136c87cf39ed25 interfaces/kmediaplayer/kfileaudiopreview/Messages.sh interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.h interfaces/kmediaplayer/kfileaudiopreview/kfileaudiopreview.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.h interfaces/kmediaplayer/kfileaudiopreview/mediacontrols.cpp interfaces/kmediaplayer/kfileaudiopreview/mediacontrols_p.h interfaces/kmediaplayer/kmediaplayer.desktop interfaces/kmediaplayer/kmediaplayeradaptor.cpp interfaces/kmediaplayer/kmediaplayeradaptor_p.h interfaces/kmediaplayer/kmediaplayerengine.desktop interfaces/kmediaplayer/org.kde.KMediaPlayer.xml interfaces/kmediaplayer/player.h 64275e127d9e9580de7ab7c6675ab8d8b83fe651 interfaces/kmediaplayer/player.cpp 531d96847c847b5ca970141c37afc936705bda8c interfaces/kmediaplayer/view.h interfaces/kmediaplayer/view.cpp 0f3cbd53f600d4d75b278d2183e4214372ab85cd staging/CMakeLists.txt c77fa19ad700c6e9af68434d7c6fdc304fceeba6 staging/kmediaplayer/CMakeLists.txt PRE-CREATION staging/kmediaplayer/KMediaPlayerConfig.cmake.in PRE-CREATION staging/kmediaplayer/src/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kfileaudiopreview/CMakeLists.txt PRE-CREATION staging/kmediaplayer/src/kmediaplayer/CMakeLists.txt PRE-CREATION Diff: http://git.reviewboard.kde.org/r/113825/diff/ Testing --- Builds, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113827: CMake: refer to target directly instead of getting LOCATION property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113827/ --- (Updated Nov. 14, 2013, 12:05 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- CMake: refer to target directly instead of getting LOCATION property This silences an annoying CMake warning. Diffs - tier3/kdewidgets/src/CMakeLists.txt b376db89543aa4097045beabe9596eee0800e825 Diff: http://git.reviewboard.kde.org/r/113827/diff/ Testing --- Re-running cmake no longer has the warning. After removing kdewidgets.cpp from the build directory and running make, it is regenerated correctly. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113798: KDBusService: pass the desktop startup ID when calling Activate
On Nov. 11, 2013, 5:45 p.m., David Faure wrote: Thanks for implementing that. Indeed the TODO didn't mean adding a method to QApplication, but it was about the member that was there in qt4, and that is now in QXcbConnection. The optional dependency on QtGui breaks the rules for tier1 addons, though. Maybe we need to move KDBusService up to... the KService framework maybe? (Note that there are more todos about startupId stuff, in KDBusService::Activate etc. This would probably be easier to implement in a higher framework too. Alex Merry wrote: Oh? I can't find a rule on the wiki that precludes it. Regardless, the other TODOs would be a lot easier from tier2 or above, where we could use KStartupInfo from KWindowSystem. KService probably does make the most sense out of what we have, although it's still a bit mismatched (I wouldn't expect to need KService if my application didn't use plugins). Is there maybe a use for a framework that provides things to help make apps behave well in free desktop environments? Kevin Ottens wrote: I would still prefer having KDBusService stay there... What about doing the xcb connection dance in our platform theme plugin instead? And then attaching a dynamic property on the qapp instance? This way we can channel the startup id, and from KDBusService POV it only needs to know about QCoreApplication. How about this for an idea: platform_data is an inherently platformy thing (as its name suggests). Perhaps KDBusService could have a (global-static-ish) way of registering a platform interface that contained virtual methods QVariantMap platformData() const; void activated(QVariantMap platform_data); (as a minimum; more fine-grained hooks could also be provided) that the platform plugin could implement and register. The constructor would use the first method to get the necessary data (such as sn id) at one end, and the second to use it in the main instance (and when called via D-Bus). - Alex --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113798/#review43449 --- On Nov. 11, 2013, 4:37 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113798/ --- (Updated Nov. 11, 2013, 4:37 p.m.) Review request for KDE Frameworks, David Faure and Kevin Ottens. Repository: kdelibs Description --- KDBusService: pass the desktop startup ID when calling Activate We use a bit of private API to ask the xcb platform plugin for it directly. The TODO in the original code suggested getting a method in QApplication (or one of its ancestors) to get the startup id, but I think that's very unlikely to be accepted. There's still the hooks to make use of the value on the other side to sort out, though. Diffs - tier1/kdbusaddons/CMakeLists.txt 78cc44333574355ff8504481fcb9c88cfc90daf5 tier1/kdbusaddons/src/CMakeLists.txt 0509015afd2d24d34f85a7d6fd786092820814bf tier1/kdbusaddons/src/config-kdbusaddons.h.cmake PRE-CREATION tier1/kdbusaddons/src/kdbusservice.cpp b773c80b30c6ee39d6d8b4d8c962b83dbd87f7d4 Diff: http://git.reviewboard.kde.org/r/113798/diff/ Testing --- Builds, tests pass. A quick-hack modification of the autotest, along with some hacked-in debug statements, show the value is getting passed properly. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113260: Port KTimeZoned to Qt5/KF5
On Nov. 12, 2013, 10:39 a.m., Commit Hook wrote: This review has been submitted with commit 53e8e439af2483c86b21ad4d53ffe4da622e8c44 by Martin Klapetek to branch frameworks. Locally, I get this error: AUTOMOC: error: process for /local/build/kf5/runtime/ktimezoned/ktimezoned.moc failed: /local/git/KDE/base/kde-runtime-frameworks/ktimezoned/ktimezoned.cpp:35: Error: Plugin Metadata file ktimezoned.json does not exist. Declaration will be ignored moc failed... make[2]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc] Error 1 make[2]: Target `ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/build' not remade because of errors. make[1]: *** [ktimezoned/CMakeFiles/kded_ktimezoned_automoc.dir/all] Error 2 Any idea? - Christoph --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/#review43507 --- On Nov. 12, 2013, 10:39 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113260/ --- (Updated Nov. 12, 2013, 10:39 a.m.) Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt. Repository: kde-runtime Description --- Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out that all the stuff KTZD was doing was added in QTimeZone, that includes reading correct system files/env variables to obtain the timezone and returning the proper system zone (KTZD did all this by itself). It also doesn't need to parse the timezone files itself or watch for their changes as QTimeZone objects are not stored. So now it's just a thin module watching /etc/timezone (used by Debian-based distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian in conjunction with /etc/timezone) for changes and if it detects a change, it checks if the new timezone is really different and if it is, it sends out a DBus signal timeZoneChange. I changed it from configChanged as I think timeZoneChanged makes way more sense. I didn't touch the Windows part as I have no way to test, would be nice if someone could help with that. EDIT: I removed the other two DBus signals which were not used and I'm unsure KTZD is the correct place for that now anyway. The only usage in KSystemTimeZone can be replaced by own KDirWatch instance. Diffs - CMakeLists.txt a5ec93d ktimezoned/CMakeLists.txt bafc85e ktimezoned/ktimezoned.h ff21807 ktimezoned/ktimezoned.cpp f380c09 ktimezoned/ktimezoned_win.h 26e21cc ktimezoned/ktimezoned_win.cpp cadfe3a ktimezoned/ktimezonedbase.h ca00aca ktimezoned/org.kde.KTimeZoned.xml daaa0b7 Diff: http://git.reviewboard.kde.org/r/113260/diff/ Testing --- Tested by changing the timezone in different ways, change was detected and signalled out. 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 113685: New KColorSchemeManager to support changing color scheme in app
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113685/ --- (Updated Nov. 14, 2013, 6:50 a.m.) Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and Boudewijn Rempt. Changes --- fixed the issues Repository: kdelibs Description --- This class is inspired by functionality offered by e.g. Krita and Digikam to allow the user to select a different color scheme for the application. This manager simplifies this task and also ensures that the required property on QApplication is set, so that a QStyle can pass the scheme to the window manager/compositor for the windows of the application. @boud and @cgilles: please have a look whether this approach is sufficient for your usecases in digkam and Krita. Diffs (updated) - tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 Diff: http://git.reviewboard.kde.org/r/113685/diff/ Testing --- see demo application Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
