Re: OSX/CI: purpose fails to build on branch master
On Mon, Mar 2, 2015 at 8:55 PM, Marko Käning mk-li...@email.de wrote:
Hi Aleix,
after adding a few dependencies:
---
$ git diff
diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 7cf844f..2a303d4 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -1002,6 +1002,12 @@ playground/base/kio-mtp: frameworks/ki18n
playground/base/kio-mtp: frameworks/solid
playground/base/kio-mtp: frameworks/kio
+# Playground Libs
+playground/libs/purpose: frameworks/kcoreaddons
+playground/libs/purpose: frameworks/kconfig
+playground/libs/purpose: frameworks/ki18n
+playground/libs/purpose: frameworks/kdeclarative
+
# KAccounts
kdereview/kaccounts-integration: frameworks/kcmutils
kdereview/kaccounts-integration: frameworks/kio
diff --git a/logical-module-structure b/logical-module-structure
index c7f929e..284c54a 100644
--- a/logical-module-structure
+++ b/logical-module-structure
@@ -738,6 +738,9 @@
playground/libs/kpackage : {
kf5-qt5: master
},
+playground/libs/purpose : {
+kf5-qt5: master
+},
playground/base/qtcurve : {
latest-qt4: master,
kf5-qt5: “master”
---
I was able to start building purpose on OSX/CI...
...but then it failed later on:
---
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/ktp-sendfile/ktpsendfileplugin.cpp:65:28:
error: no matching constructor for initialization of 'const QJsonObject '
Q_EMIT output( {{ QStringLiteral(url), {} }});
^~~
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/dummy/dummyplugin.cpp:48:13:
error: no matching function for call to 'singleShot'
QTimer::singleShot(100, this, [this](){ setPercent(10); });
^~
---
Please find the whole build log attached.
Greets,
Marko
P.S.: I was trying to build kamoso. Stop me, please, if this still doesn’t
make sense (on OSX)!!!
I'm guessing the compiler you are using doesn't support yet some fancy
c++11 features?
I'm guessing you are still using Qt 5.3? QTimer::singleShot takes a
lambda on the 3rd argument for the first time in Qt 5.4.
Anyway, this purpose thing can be considered a proof of concept still,
so if you want we can discuss about it outside of kde-frameworks-devel
so we don't generate any noise.
Cheers!
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122764: Adding missing licenses
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122764/#review76935 --- Ship it! OK, sounds good. - Michael Pyne On Feb. 28, 2015, 7:38 p.m., Maximiliano Curia wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122764/ --- (Updated Feb. 28, 2015, 7:38 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- cmake/FindFAM.cmake needs to be distributed with a copy of COPYING-CMAKE-SCRIPTS And a number of files (I count 42 right now) are under the LGPL-2 (without the or any later version option), and thus it's recommended to distribute the complete license. This patch was done after the rejection of the Debian ftpmasters of kcoreaddons (https://lists.debian.org/debian-qt-kde/2015/02/msg00239.html). Diffs - COPYING-CMAKE-SCRIPTS PRE-CREATION COPYING.LGPL-2 PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122764/diff/ Testing --- Thanks, Maximiliano Curia ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
On Mon, March 2, 2015 21:22:32 Albert Astals Cid wrote: El Dilluns, 2 de març de 2015, a les 20:49:45, Martin Klapetek va escriure: Makes me think that maybe the review process does not work that well... Correct, the review process doesn't work well at all, and hasn't been for a long time, there's not enough people with enough different skills reviewing the apps/libs. In any event, I think the review process (even if it were working very well) would not cover scheduling concerns but rather code quality, use of proper infrastructure, stuff like that. But for scheduling, the default assumption would always be that the module being reviewed would simply land in the next routine release. The process needed to review a set of modules to be included in a *specific* release would be different. Since I'm a part of our failed review processes I can't tell you which route we tried to go by, but I would hope that collectively would handle things better for the question We want to release KFoo in 15.04 vs. We want to include KFoo in KDE Applications. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122733: Fix path traversal checks in KPackage
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122733/#review76933 --- Ship it! Very nice. :) - Sebastian Kügler On Feb. 26, 2015, 7:34 p.m., Alex Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122733/ --- (Updated Feb. 26, 2015, 7:34 p.m.) Review request for KDE Frameworks, Plasma and Marco Martin. Repository: kpackage Description --- They did not canonicalize the package base directory path so it would always fail when the package base path contained symlinks Diffs - src/kpackage/package.cpp eb4a09b987970e89f28587426b21d63731634087 src/kpackage/private/package_p.h e451412fa02c88113aa4c7bbca2dcda3432b2b02 Diff: https://git.reviewboard.kde.org/r/122733/diff/ Testing --- Files inside the package are now found although the install location contains a symlink Thanks, Alex Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
On Mon, March 2, 2015 20:15:20 Marko Käning wrote:
So, having those ktp-* entries in dependency-data-stable-kf5-qt5 shouldn’t
do any harm.
But I don’t know how kdesrc-build will handle this, though...
For missing entries kdesrc-build will infer master as the git branch to use.
It would be very confusing for a user to ask to build a module and still have
kdesrc-build ignore it because it doesn't have an entry in kde-build-metadata.
With that said, kdesrc-build *will* ignore modules that have a defined branch
of (i.e. empty) in logical-module-structure, so if a module simply should
not be built for a given branch-group my recommendation would be to define the
branch-group after all but set it to an empty value. E.g.
kde/kdenetwork/ktp*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9,
kf5-qt5: master,
stable-kf5-qt5:
},
I believe that Scarlett's new CI supports this as well, and the current
Jenkins CI also supports this.
Regards,
- Michael Pyne
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
Hi Michael,
On 03 Mar 2015, at 03:30 , Michael Pyne mp...@kde.org wrote:
On Mon, March 2, 2015 20:15:20 Marko Käning wrote:
So, having those ktp-* entries in dependency-data-stable-kf5-qt5 shouldn’t
do any harm.
But I don’t know how kdesrc-build will handle this, though...
For missing entries kdesrc-build will infer master as the git branch to
use.
It would be very confusing for a user to ask to build a module and still have
kdesrc-build ignore it because it doesn't have an entry in kde-build-metadata.
With that said, kdesrc-build *will* ignore modules that have a defined branch
of (i.e. empty) in logical-module-structure, so if a module simply should
not be built for a given branch-group my recommendation would be to define
the
branch-group after all but set it to an empty value. E.g.
kde/kdenetwork/ktp*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9,
kf5-qt5: master,
stable-kf5-qt5:
},
I believe that Scarlett's new CI supports this as well, and the current
Jenkins CI also supports this.
Scarlett’s CI also supports to treat *undefined* entries as _set to empty_,
just like my OSX/CI does.
So, in the light of your remarks the question is, whether all the
removed empty definitions in my RR [1] should actually be left the
way they are!?!?
Greets,
Marko
[1] https://git.reviewboard.kde.org/r/122672/
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122764: Adding missing licenses
On March 3, 2015, 2:21 a.m., Michael Pyne wrote: OK, sounds good. Thanks, I don't have commit access. Can you push this change? Thanks again. - Maximiliano --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122764/#review76935 --- On Feb. 28, 2015, 7:38 p.m., Maximiliano Curia wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122764/ --- (Updated Feb. 28, 2015, 7:38 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- cmake/FindFAM.cmake needs to be distributed with a copy of COPYING-CMAKE-SCRIPTS And a number of files (I count 42 right now) are under the LGPL-2 (without the or any later version option), and thus it's recommended to distribute the complete license. This patch was done after the rejection of the Debian ftpmasters of kcoreaddons (https://lists.debian.org/debian-qt-kde/2015/02/msg00239.html). Diffs - COPYING-CMAKE-SCRIPTS PRE-CREATION COPYING.LGPL-2 PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122764/diff/ Testing --- Thanks, Maximiliano Curia ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On Mar. 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On Mar. 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated Mar. 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On Mar. 2, 2015, 5:21 a.m., Jerome Leclanche wrote: Should we be using ::tr here instead of not translating at all? Jerome Leclanche wrote: Consensus on IRC six days ago was that dropping translation altogether was fine. I can add some ::tr but it's arguable whether some of those values should have been translated in the first place (eg. author names) Martin Gräßlin wrote: I think ::tr would be better to keep the functionality and support for the case that it shows up in UI again. (offtopic: there was a reason why names should be translated, though I don't remember it.) For example, names can be translitterated, or have inflections. For the future, please also ask i18n and don't just kill translations. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76855 --- On Mar. 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated Mar. 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On Mar. 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Sorry, there is also another change about the script used, check other tier1 frameworks - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On Mar. 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated Mar. 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122775: Only nativeWidth/heights need updating.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/ --- Review request for KDE Frameworks. Repository: kdeclarative Description --- PaintedWidth/Height are all relative to the items geometry so already in user pixels not device pixels. Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122775/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122775: Make QImageItem handle non default devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/ --- (Updated March 2, 2015, 2:50 p.m.) Review request for KDE Frameworks. Summary (updated) - Make QImageItem handle non default devicePixelRatios Repository: kdeclarative Description --- PaintedWidth/Height are all relative to the items geometry so already in user pixels not device pixels. Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122775/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122774: Fix logic error in qpixmap/image item
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/ --- Review request for KDE Frameworks. Repository: kdeclarative Description --- sourceRect is used to see if the destination rect changes since the previous update, this value is stored in m_paintedRect, m_image.rect() is constant Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122774/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122776: Add test for qimageitem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/ --- Review request for KDE Frameworks. Repository: kdeclarative Description --- Add test for qimageitem Diffs - tests/CMakeLists.txt a8abfaf tests/kdeclarativetest.cpp 70ea03f tests/qimageitemtest.qml PRE-CREATION tests/testimage.png PRE-CREATION tests/testim...@2x.png PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122776/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
Hi, I think CI still needs something like this: --- $ git diff diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5 index 3731ec6..6005971 100644 --- a/dependency-data-kf5-qt5 +++ b/dependency-data-kf5-qt5 @@ -241,6 +241,11 @@ frameworks/plasma-framework: frameworks/kwindowsystem frameworks/plasma-framework: frameworks/kxmlgui frameworks/plasma-framework: frameworks/ktexteditor frameworks/kxmlrpcclient: frameworks/kio +frameworks/kpeople: frameworks/kcoreaddons +frameworks/kpeople: frameworks/kwidgetsaddons +frameworks/kpeople: frameworks/kservice +frameworks/kpeople: frameworks/ki18n +frameworks/kpeople: frameworks/kitemviews # Frameworks, tier4 frameworks/frameworkintegration: frameworks/ki18n @@ -1056,12 +1061,5 @@ kde/kdegames/palapeli: kde/kdegames/libkdegames kde/kdegames/picmi: kde/kdegames/libkdegames extragear/games/knights: kde/kdegames/libkdegames -# Playground Libs -playground/network/kpeople: frameworks/kcoreaddons -playground/network/kpeople: frameworks/kwidgetsaddons -playground/network/kpeople: frameworks/kservice -playground/network/kpeople: frameworks/ki18n -playground/network/kpeople: frameworks/kitemviews - # A standalone application, no need to install KF5 extragear/pim/trojita: -frameworks/kf5umbrella diff --git a/dependency-data-stable-kf5-qt5 b/dependency-data-stable-kf5-qt5 index 912255e..d5ed49b 100644 --- a/dependency-data-stable-kf5-qt5 +++ b/dependency-data-stable-kf5-qt5 @@ -236,6 +236,11 @@ frameworks/plasma-framework: frameworks/kwidgetsaddons frameworks/plasma-framework: frameworks/kwindowsystem frameworks/plasma-framework: frameworks/kxmlgui frameworks/plasma-framework: frameworks/ktexteditor +frameworks/kpeople: frameworks/kcoreaddons +frameworks/kpeople: frameworks/kwidgetsaddons +frameworks/kpeople: frameworks/kservice +frameworks/kpeople: frameworks/ki18n +frameworks/kpeople: frameworks/kitemviews # Frameworks, tier4 frameworks/frameworkintegration: frameworks/ki18n --- Greets, Marko___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122770: Support KWindowSystem::icon with NETWinInfo on all platforms
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122770/ --- Review request for KDE Frameworks. Repository: kwindowsystem Description --- If we compile with X11 support we want this method to use the X11 implementation on all platforms and not just on platform xcb. The NETWinInfo is already so X11 specific that the platform doesn't matter. To solve this the method it delegates to in KWindowSystemPrivateX11 is made static. It only operates through the NETWinInfo and doesn't need anything else from KWindowSystemPrivateX11. Diffs - src/kwindowsystem.h 21b254b246753d6ee7805864e28284dfa169855e src/kwindowsystem.cpp 97dd6072a77f864b1e08287e8546cc29c24474c6 src/kwindowsystem_p_x11.h a507922ba632eb54e9121a1420d83c26d3676c66 Diff: https://git.reviewboard.kde.org/r/122770/diff/ Testing --- kwin_wayland (Martin dev branch) shows icons for X11 applications again. 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 122680: kglobalaccel: Remove the runtime's KAboutData
On Mar. 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Luigi Toscano wrote: Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. wrt why I'm asking: the Messages.sh, maybe the top-level one and few cmake calls to be changed to have translations working. Plase add i18n group. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On Mar. 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated Mar. 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On mar. 2, 2015, 8:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Luigi Toscano wrote: Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. Luigi Toscano wrote: wrt why I'm asking: the Messages.sh, maybe the top-level one and few cmake calls to be changed to have translations working. Plase add i18n group. Hrvoje Senjan wrote: i'd like to mention that translations for the daemon aren't working anyway with 5.7.0 tar, as they aren't wrapped with ki18n macro, but with ECMPoQmTools @Hrvoje, the daemon is using i18n just fine in 5.7.0, ecmpoqmtools is for the library which uses .po. @Jerome, yes this change is incomplete, you either need to remove the Messages.sh in the daemon and add the ecm loading of the existing kglobalaccel5_qt qm to the daemon or create two different catalogs, i'd say having just one probably makes sense. You won't need -DTRANSLATION_DOMAIN anymore since that's for ki18n - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On mar. 2, 2015, 9 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated mar. 2, 2015, 9 a.m.) Review request for KDE Frameworks, Localization and Translation (l10n), Martin Gräßlin, and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On March 2, 2015, 8:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. - Jerome --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On March 2, 2015, 8:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 8:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
On Mon, Mar 2, 2015 at 9:15 AM, Marko Käning mk-li...@email.de wrote: Hi, I think CI still needs something like this: --- $ git diff diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5 index 3731ec6..6005971 100644 --- a/dependency-data-kf5-qt5 +++ b/dependency-data-kf5-qt5 @@ -241,6 +241,11 @@ frameworks/plasma-framework: frameworks/kwindowsystem frameworks/plasma-framework: frameworks/kxmlgui frameworks/plasma-framework: frameworks/ktexteditor frameworks/kxmlrpcclient: frameworks/kio +frameworks/kpeople: frameworks/kcoreaddons +frameworks/kpeople: frameworks/kwidgetsaddons +frameworks/kpeople: frameworks/kservice +frameworks/kpeople: frameworks/ki18n +frameworks/kpeople: frameworks/kitemviews # Frameworks, tier4 frameworks/frameworkintegration: frameworks/ki18n @@ -1056,12 +1061,5 @@ kde/kdegames/palapeli: kde/kdegames/libkdegames kde/kdegames/picmi: kde/kdegames/libkdegames extragear/games/knights: kde/kdegames/libkdegames -# Playground Libs -playground/network/kpeople: frameworks/kcoreaddons -playground/network/kpeople: frameworks/kwidgetsaddons -playground/network/kpeople: frameworks/kservice -playground/network/kpeople: frameworks/ki18n -playground/network/kpeople: frameworks/kitemviews - # A standalone application, no need to install KF5 extragear/pim/trojita: -frameworks/kf5umbrella diff --git a/dependency-data-stable-kf5-qt5 b/dependency-data-stable-kf5-qt5 index 912255e..d5ed49b 100644 --- a/dependency-data-stable-kf5-qt5 +++ b/dependency-data-stable-kf5-qt5 @@ -236,6 +236,11 @@ frameworks/plasma-framework: frameworks/kwidgetsaddons frameworks/plasma-framework: frameworks/kwindowsystem frameworks/plasma-framework: frameworks/kxmlgui frameworks/plasma-framework: frameworks/ktexteditor +frameworks/kpeople: frameworks/kcoreaddons +frameworks/kpeople: frameworks/kwidgetsaddons +frameworks/kpeople: frameworks/kservice +frameworks/kpeople: frameworks/ki18n +frameworks/kpeople: frameworks/kitemviews # Frameworks, tier4 frameworks/frameworkintegration: frameworks/ki18n --- Greets, Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel True! Just pushed the change reflecting the move to dependency-data. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On March 2, 2015, 5:21 a.m., Jerome Leclanche wrote: Should we be using ::tr here instead of not translating at all? Jerome Leclanche wrote: Consensus on IRC six days ago was that dropping translation altogether was fine. I can add some ::tr but it's arguable whether some of those values should have been translated in the first place (eg. author names) Martin Gräßlin wrote: I think ::tr would be better to keep the functionality and support for the case that it shows up in UI again. (offtopic: there was a reason why names should be translated, though I don't remember it.) Luigi Toscano wrote: For example, names can be translitterated, or have inflections. For the future, please also ask i18n and don't just kill translations. I think that adding the translations with argument support for the case that it shows up in UI again. is not a good one - this creates more work for everyone (Jerome, i18n teams etc) with 0 outcome as the translations are nowhere to be seen (it's a daemon). I think that it should be added rather when the need arises, if ever... *shrug* - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76855 --- On March 2, 2015, 10 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 10 a.m.) Review request for KDE Frameworks, Localization and Translation (l10n), Martin Gräßlin, and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On March 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Luigi Toscano wrote: Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. Luigi Toscano wrote: wrt why I'm asking: the Messages.sh, maybe the top-level one and few cmake calls to be changed to have translations working. Plase add i18n group. Hrvoje Senjan wrote: i'd like to mention that translations for the daemon aren't working anyway with 5.7.0 tar, as they aren't wrapped with ki18n macro, but with ECMPoQmTools Albert Astals Cid wrote: @Hrvoje, the daemon is using i18n just fine in 5.7.0, ecmpoqmtools is for the library which uses .po. @Jerome, yes this change is incomplete, you either need to remove the Messages.sh in the daemon and add the ecm loading of the existing kglobalaccel5_qt qm to the daemon or create two different catalogs, i'd say having just one probably makes sense. You won't need -DTRANSLATION_DOMAIN anymore since that's for ki18n afaics, ki18n only knowns about mo files, while all translations in kglobalaccel 5.7 are installed as qm files.. it is also possible i missunderstood something ;-) - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On March 2, 2015, 10 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 10 a.m.) Review request for KDE Frameworks, Localization and Translation (l10n), Martin Gräßlin, and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On Mar. 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On Mar. 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated Mar. 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76873 --- +1 - David Edmundson On Feb. 25, 2015, 5:40 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/ --- (Updated Feb. 25, 2015, 5:40 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- this adds a new class called KCModuleQml it loads a KPackage with the same plugin name as the kcm, then loads its mainscript qml file from it and puts it in a QQuickView used as main widget of the KCM. It supports two ways of loading the qml: one is in the showevent of the KCM qwidget, this is compatible with current Systemsettings and kcmshell. the other way is with the mainUi accessor/qproperty. This will make possible for a pure QML version of systemsettings (accessing directly mainUi without showing qwidgets) Diffs - CMakeLists.txt f3aaf18 src/CMakeLists.txt 10862c6 src/kcmoduleqml.h PRE-CREATION src/kcmoduleqml.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122706/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On March 2, 2015, 9:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Luigi Toscano wrote: Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. Luigi Toscano wrote: wrt why I'm asking: the Messages.sh, maybe the top-level one and few cmake calls to be changed to have translations working. Plase add i18n group. i'd like to mention that translations for the daemon aren't working anyway with 5.7.0 tar, as they aren't wrapped with ki18n macro, but with ECMPoQmTools - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On March 2, 2015, 10 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 10 a.m.) Review request for KDE Frameworks, Localization and Translation (l10n), Martin Gräßlin, and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122774: Fix logic error in qpixmap/image item
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/#review76906 --- Ship it! Oops, copy-paste error on my part... thanks for spotting! - Luca Beltrame On Mar. 2, 2015, 2:43 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/ --- (Updated Mar. 2, 2015, 2:43 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- sourceRect is used to see if the destination rect changes since the previous update, this value is stored in m_paintedRect, m_image.rect() is constant Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122774/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122775: Make QImageItem handle non default devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/#review76905 --- Ship it! Inviala! - Luca Beltrame On Mar. 2, 2015, 2:50 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/ --- (Updated Mar. 2, 2015, 2:50 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- PaintedWidth/Height are all relative to the items geometry so already in user pixels not device pixels. Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122775/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122776: Add test for qimageitem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/#review76892 --- Ship it! How hard would it be to get an autotest? :D - Aleix Pol Gonzalez On March 2, 2015, 3:49 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/ --- (Updated March 2, 2015, 3:49 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- Add test for qimageitem Diffs - tests/CMakeLists.txt a8abfaf tests/kdeclarativetest.cpp 70ea03f tests/qimageitemtest.qml PRE-CREATION tests/testimage.png PRE-CREATION tests/testim...@2x.png PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122776/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122775: Make QImageItem handle non default devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/#review76893 --- Ship it! Ship It! - Aleix Pol Gonzalez On March 2, 2015, 3:50 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/ --- (Updated March 2, 2015, 3:50 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- PaintedWidth/Height are all relative to the items geometry so already in user pixels not device pixels. Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122775/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122776: Add test for qimageitem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/#review76904 --- +1 from me, given I touched this code recently. - Luca Beltrame On Mar. 2, 2015, 2:49 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/ --- (Updated Mar. 2, 2015, 2:49 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- Add test for qimageitem Diffs - tests/CMakeLists.txt a8abfaf tests/kdeclarativetest.cpp 70ea03f tests/qimageitemtest.qml PRE-CREATION tests/testimage.png PRE-CREATION tests/testim...@2x.png PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122776/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122774: Fix logic error in qpixmap/image item
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/#review76895 --- Ship it! Ship It! - Aleix Pol Gonzalez On March 2, 2015, 3:43 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/ --- (Updated March 2, 2015, 3:43 p.m.) Review request for KDE Frameworks. Repository: kdeclarative Description --- sourceRect is used to see if the destination rect changes since the previous update, this value is stored in m_paintedRect, m_image.rect() is constant Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122774/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122775: Make QImageItem handle non default devicePixelRatios
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122775/ --- (Updated March 2, 2015, 4:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdeclarative Description --- PaintedWidth/Height are all relative to the items geometry so already in user pixels not device pixels. Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122775/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122776: Add test for qimageitem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122776/ --- (Updated March 2, 2015, 4:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdeclarative Description --- Add test for qimageitem Diffs - tests/CMakeLists.txt a8abfaf tests/kdeclarativetest.cpp 70ea03f tests/qimageitemtest.qml PRE-CREATION tests/testimage.png PRE-CREATION tests/testim...@2x.png PRE-CREATION Diff: https://git.reviewboard.kde.org/r/122776/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122779: Make KFileItemDelegate handle non default devicePixelRatio in animations
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122779/ --- Review request for KDE Frameworks. Repository: kio Description --- KIO::CachedRendering creates new pixmaps that hold transitional states in animation, these pixmap sizes need to be in device pixels. Diffs - src/widgets/delegateanimationhandler.cpp 16035ca src/widgets/delegateanimationhandler_p.h 292364f src/widgets/kfileitemdelegate.cpp 90bce37 Diff: https://git.reviewboard.kde.org/r/122779/diff/ Testing --- Ran systemsettings with Qt::AA_UseHighDpiPixmaps and QT_DEVICE_PIXEL_RATIO=2 hovering over the main view no longer makes the icon blocky. Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122774: Fix logic error in qpixmap/image item
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122774/ --- (Updated March 2, 2015, 4:34 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdeclarative Description --- sourceRect is used to see if the destination rect changes since the previous update, this value is stored in m_paintedRect, m_image.rect() is constant Diffs - src/qmlcontrols/kquickcontrolsaddons/qimageitem.cpp ed735b5 src/qmlcontrols/kquickcontrolsaddons/qpixmapitem.cpp 8c06146 Diff: https://git.reviewboard.kde.org/r/122774/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122741: Prefer exposing lists to QML with QJsonArray
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122741/#review76914 --- Ship it! Ship It! - Eike Hein On Feb. 27, 2015, 3:14 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122741/ --- (Updated Feb. 27, 2015, 3:14 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- QVariantList are treated as objects with integer indexes for some reasons and leads to weird scenarios. Diffs - src/qmlcontrols/draganddrop/DeclarativeMimeData.h 4a0723b src/qmlcontrols/draganddrop/DeclarativeMimeData.cpp 0db74f9 Diff: https://git.reviewboard.kde.org/r/122741/diff/ Testing --- QuickShare plasmoid can use now DeclarativeMimeData. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
On Monday 02 of March 2015 19:08:57 Marko Käning wrote: We need to remember that the stable-kf5-qt5 branch group needs to be kept in sync whenever updating kf5-qt5… I committed the still missing info for it in [1]. This should really be solved somehow in a more clear way, if I'm not misunderstanding all the process: there is no stable version of ktp right now for kf5. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
Hi, On 02 Mar 2015, at 19:14 , Luigi Toscano luigi.tosc...@tiscali.it wrote: This should really be solved somehow in a more clear way, if I'm not misunderstanding all the process: there is no stable version of ktp right now for kf5. yes, I guess so. If there is no stable version for it, it shouldn’t appear in this file! Greets, Marko ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
We need to remember that the stable-kf5-qt5 branch group needs to be kept in sync whenever updating kf5-qt5… I committed the still missing info for it in [1]. Greets, Marko [1] http://commits.kde.org/kde-build-metadata/1aa3609df9b3b513c4fd555d38cb3d047f4e3c03 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
Well, Luigi, this is what the logical deps say:
---
extragear/network/telepathy/*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9
},
kde/kdenetwork/ktp*: {
stable-qt4: kde-telepathy-0.9,
latest-qt4: kde-telepathy-0.9,
kf5-qt5: master
},
---
which means that kde-telepathy-0.9” is set as the latest stable for Qt4 only.
As the port group “stable-kf5-qt5” isn’t set to a value, it is not considered in
OSX/CI and Scarlett’s new version of Linux/CI.
So, having those ktp-* entries in dependency-data-stable-kf5-qt5 shouldn’t do
any harm.
But I don’t know how kdesrc-build will handle this, though...
Greets,
Marko
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
On Mon, Mar 2, 2015 at 8:16 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 2 de març de 2015, a les 01:47:00, Martin Klapetek va escriure: I would just like to point out that the review period of KPeople is over and all the associated moves are in order, are they not? What exactly is enormously rushed when the review period is over and moves are rightfully requested? Perhaps that should have been said in either of the please review this proposal emails before, not after. KDE Telepathy also already has a dependency on KPeople since ever, so there's no new dependency added. It's just being moved from kdereview to frameworks. Is that a dependency freeze violation? I read it is not allowed to add new dependencies in the release schedule page. That is not what is happening. The only rush is to get KPeople tarball released a bit sooner so that it can be there for KDE Applications Beta 1. That is all. And that tarball could just as well be made from kdereview. We have some rules, one of them is that when we release a tarball, it must be able to be compiled against other released tarballs. I hope that's not hard to agree on. So we need the KPeople tarball before KDE Applications 15.04 Beta 1 is out. Now KPeople wants to be a framework and thus is not on the same relase schedule as KDE Applications 15.04. So to achieve the tarballs have to compile against released tarballs KPeople should have been part of the past release, not of Frameworks release that is after KDE Applications 15.04 Beta 1 is released. Thus KPeople was late and we had to rush it a bit. Yes, but the only thing rushed is the release of KPeople tarball about 8 days sooner. Everything else is pretty much in order, so there's definitely not an enormous rush to things and not at all a freeze violation. (and yes I'm a bit annoyed by all this crap I'm getting for this only now and not a month before when was the right time) I'm sorry you're getting annoyed by people trying to make sure we collectively follow the few rules we have given ourselves. No, I'm annoyed by the fact that all I hear is this is rush rush rush rush mess mess mess and only _after_ all the moves have had happened. That's why there is the review period. And I started it since beginning of February. Nobody in the review periods asked the right questions, nobody really objected or disagreed to anything and suddenly it's all rush and mess while it's just one single tarball in question and already with a solution. Makes me think that maybe the review process does not work that well... If you don't agree with the rules you're more than welcome to propose improvements or modifications, maybe that way we will get more people caring and following them. I never said anything about not agreeing with the rules (and it's really not about the rules). Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
On mar. 2, 2015, 8:06 a.m., Martin Gräßlin wrote: Ship It! Luigi Toscano wrote: Please fix the extracted pot so that it is called file_qt.pot. (personally speaking, I would strongly suggest lxde to use ki18n, but that's another discussion) Luigi Toscano wrote: Sorry, there is also another change about the script used, check other tier1 frameworks Jerome Leclanche wrote: I don't understand what you're asking of me - in the last diff, I'm not touching the pot file at all. Luigi Toscano wrote: Sorry again, it' s a bit.more complicated as there is already such _qt.pot file (the main one). So probably it should be extended to extract also runtime translations and the appropriate changes to translations domain applied here. Please cc i18n, I can't do a complete check now. Luigi Toscano wrote: wrt why I'm asking: the Messages.sh, maybe the top-level one and few cmake calls to be changed to have translations working. Plase add i18n group. Hrvoje Senjan wrote: i'd like to mention that translations for the daemon aren't working anyway with 5.7.0 tar, as they aren't wrapped with ki18n macro, but with ECMPoQmTools Albert Astals Cid wrote: @Hrvoje, the daemon is using i18n just fine in 5.7.0, ecmpoqmtools is for the library which uses .po. @Jerome, yes this change is incomplete, you either need to remove the Messages.sh in the daemon and add the ecm loading of the existing kglobalaccel5_qt qm to the daemon or create two different catalogs, i'd say having just one probably makes sense. You won't need -DTRANSLATION_DOMAIN anymore since that's for ki18n Hrvoje Senjan wrote: afaics, ki18n only knowns about mo files, while all translations in kglobalaccel 5.7 are installed as qm files.. it is also possible i missunderstood something ;-) You're right, the cmake code is wrong and is installing kglobalaccel5.po wrongly as kglobalaccel5.qm I guess noone expected .qm and non .qm files to coexist in a single tarball. - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- On mar. 2, 2015, 9 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated mar. 2, 2015, 9 a.m.) Review request for KDE Frameworks, Localization and Translation (l10n), Martin Gräßlin, and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
El Dilluns, 2 de març de 2015, a les 01:47:00, Martin Klapetek va escriure: I would just like to point out that the review period of KPeople is over and all the associated moves are in order, are they not? What exactly is enormously rushed when the review period is over and moves are rightfully requested? Perhaps that should have been said in either of the please review this proposal emails before, not after. KDE Telepathy also already has a dependency on KPeople since ever, so there's no new dependency added. It's just being moved from kdereview to frameworks. Is that a dependency freeze violation? I read it is not allowed to add new dependencies in the release schedule page. That is not what is happening. The only rush is to get KPeople tarball released a bit sooner so that it can be there for KDE Applications Beta 1. That is all. And that tarball could just as well be made from kdereview. We have some rules, one of them is that when we release a tarball, it must be able to be compiled against other released tarballs. I hope that's not hard to agree on. So we need the KPeople tarball before KDE Applications 15.04 Beta 1 is out. Now KPeople wants to be a framework and thus is not on the same relase schedule as KDE Applications 15.04. So to achieve the tarballs have to compile against released tarballs KPeople should have been part of the past release, not of Frameworks release that is after KDE Applications 15.04 Beta 1 is released. Thus KPeople was late and we had to rush it a bit. (and yes I'm a bit annoyed by all this crap I'm getting for this only now and not a month before when was the right time) I'm sorry you're getting annoyed by people trying to make sure we collectively follow the few rules we have given ourselves. If you don't agree with the rules you're more than welcome to propose improvements or modifications, maybe that way we will get more people caring and following them. Best Regards, Albert Well thanks everyone anyway, you've done enormously good jobs. I owe you one. Cheers ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KPeople part of KDE Frameworks
El Dilluns, 2 de març de 2015, a les 20:49:45, Martin Klapetek va escriure: On Mon, Mar 2, 2015 at 8:16 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 2 de març de 2015, a les 01:47:00, Martin Klapetek va escriure: I would just like to point out that the review period of KPeople is over and all the associated moves are in order, are they not? What exactly is enormously rushed when the review period is over and moves are rightfully requested? Perhaps that should have been said in either of the please review this proposal emails before, not after. KDE Telepathy also already has a dependency on KPeople since ever, so there's no new dependency added. It's just being moved from kdereview to frameworks. Is that a dependency freeze violation? I read it is not allowed to add new dependencies in the release schedule page. That is not what is happening. The only rush is to get KPeople tarball released a bit sooner so that it can be there for KDE Applications Beta 1. That is all. And that tarball could just as well be made from kdereview. We have some rules, one of them is that when we release a tarball, it must be able to be compiled against other released tarballs. I hope that's not hard to agree on. So we need the KPeople tarball before KDE Applications 15.04 Beta 1 is out. Now KPeople wants to be a framework and thus is not on the same relase schedule as KDE Applications 15.04. So to achieve the tarballs have to compile against released tarballs KPeople should have been part of the past release, not of Frameworks release that is after KDE Applications 15.04 Beta 1 is released. Thus KPeople was late and we had to rush it a bit. Yes, but the only thing rushed is the release of KPeople tarball about 8 days sooner. Everything else is pretty much in order, so there's definitely not an enormous rush to things and not at all a freeze violation. (and yes I'm a bit annoyed by all this crap I'm getting for this only now and not a month before when was the right time) I'm sorry you're getting annoyed by people trying to make sure we collectively follow the few rules we have given ourselves. No, I'm annoyed by the fact that all I hear is this is rush rush rush rush mess mess mess and only _after_ all the moves have had happened. That's why there is the review period. And I started it since beginning of February. Nobody in the review periods asked the right questions, nobody really objected or disagreed to anything and suddenly it's all rush and mess while it's just one single tarball in question and already with a solution. Makes me think that maybe the review process does not work that well... Correct, the review process doesn't work well at all, and hasn't been for a long time, there's not enough people with enough different skills reviewing the apps/libs. Albert If you don't agree with the rules you're more than welcome to propose improvements or modifications, maybe that way we will get more people caring and following them. I never said anything about not agreeing with the rules (and it's really not about the rules). Cheers ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
OSX/CI: purpose fails to build on branch master
Hi Aleix,
after adding a few dependencies:
---
$ git diff
diff --git a/dependency-data-kf5-qt5 b/dependency-data-kf5-qt5
index 7cf844f..2a303d4 100644
--- a/dependency-data-kf5-qt5
+++ b/dependency-data-kf5-qt5
@@ -1002,6 +1002,12 @@ playground/base/kio-mtp: frameworks/ki18n
playground/base/kio-mtp: frameworks/solid
playground/base/kio-mtp: frameworks/kio
+# Playground Libs
+playground/libs/purpose: frameworks/kcoreaddons
+playground/libs/purpose: frameworks/kconfig
+playground/libs/purpose: frameworks/ki18n
+playground/libs/purpose: frameworks/kdeclarative
+
# KAccounts
kdereview/kaccounts-integration: frameworks/kcmutils
kdereview/kaccounts-integration: frameworks/kio
diff --git a/logical-module-structure b/logical-module-structure
index c7f929e..284c54a 100644
--- a/logical-module-structure
+++ b/logical-module-structure
@@ -738,6 +738,9 @@
playground/libs/kpackage : {
kf5-qt5: master
},
+playground/libs/purpose : {
+kf5-qt5: master
+},
playground/base/qtcurve : {
latest-qt4: master,
kf5-qt5: “master”
---
I was able to start building purpose on OSX/CI...
...but then it failed later on:
---
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/ktp-sendfile/ktpsendfileplugin.cpp:65:28:
error: no matching constructor for initialization of 'const QJsonObject '
Q_EMIT output( {{ QStringLiteral(url), {} }});
^~~
/Users/marko/WC/KDECI-builds/kf5-qt5/purpose/src/plugins/dummy/dummyplugin.cpp:48:13:
error: no matching function for call to 'singleShot'
QTimer::singleShot(100, this, [this](){ setPercent(10); });
^~
---
Please find the whole build log attached.
Greets,
Marko
P.S.: I was trying to build kamoso. Stop me, please, if this still doesn’t make
sense (on OSX)!!!
purpose.log.gz
Description: GNU Zip compressed data
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 8:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Changes --- Brought back Messages.sh Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs (updated) - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122680: kglobalaccel: Remove the runtime's KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76863 --- Ship it! Ship It! - Martin Gräßlin On March 2, 2015, 9:02 a.m., Jerome Leclanche wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/ --- (Updated March 2, 2015, 9:02 a.m.) Review request for KDE Frameworks, Martin Gräßlin and Martin Klapetek. Repository: kglobalaccel Description --- Remove the runtime's KAboutData The about data was unexposed, but created a dependency on KCoreAddons (for KAboutData) and in turn on KI18n for the translations of the aboutData. This removes both dependencies as well as the string extraction scripts. -- Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would like to, however it currently has too many dependencies. See https://github.com/lxde/lxqt/issues/507 for related discussion. I'm unsure myself if the about data is actually exposed somewhere I completely missed, but it doesn't look that way. Diffs - CMakeLists.txt 68ad795 src/runtime/CMakeLists.txt e639fa5 src/runtime/globalshortcutsregistry.cpp 3e4d720 src/runtime/kglobalacceld.cpp 4e7cb9d src/runtime/main.cpp fdf4d62 Diff: https://git.reviewboard.kde.org/r/122680/diff/ Testing --- Compiles and runs. No further testing done. Thanks, Jerome Leclanche ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
