Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 99 - Fixed!

2015-10-27 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/99/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 27 Oct 2015 07:41:07 +
Build duration: 4 min 8 sec

CHANGE SET
Revision 0f816ab3fada9f57e836da78470003dd24d26a27 by David Faure: 
(KBuildSycoca: always save, even if no change in .desktop file was)
  change: edit src/sycoca/kbuildsycoca.cpp
  change: edit autotests/ksycocatest.cpp
  change: edit src/sycoca/ksycoca.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5635/8183 
(69%)CONDITIONAL 2922/4369 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1459/1550 
(94%)CONDITIONAL 882/1596 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1802/3088 
(58%)CONDITIONAL 754/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2169/2946 
(74%)CONDITIONAL 1201/1538 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 99 - Fixed!

2015-10-27 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/99/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 27 Oct 2015 07:41:07 +
Build duration: 4 min 8 sec

CHANGE SET
Revision 0f816ab3fada9f57e836da78470003dd24d26a27 by David Faure: 
(KBuildSycoca: always save, even if no change in .desktop file was)
  change: edit src/sycoca/kbuildsycoca.cpp
  change: edit autotests/ksycocatest.cpp
  change: edit src/sycoca/ksycoca.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
10 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5635/8183 
(69%)CONDITIONAL 2922/4369 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1459/1550 
(94%)CONDITIONAL 882/1596 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1802/3088 
(58%)CONDITIONAL 754/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2169/2946 
(74%)CONDITIONAL 1201/1538 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125691: KOpenWithDialog: Fix creating desktop file with empty mimetype

2015-10-27 Thread David Rosca 


> On Oct. 27, 2015, 8 a.m., David Faure wrote:
> > src/widgets/kopenwithdialog.cpp, line 970
> > 
> >
> > This else should be removed, then.
> > 
> > There's no reason to only set m_pService when mimetype is empty. It's 
> > your use case, but why not set it consistently for all use cases, mimetype 
> > or no mimetype set?

Yes, it's for quicklaunch.

Because m_pService is created in addToMimeAppsList(menuId). Indeed it looks 
weird, so maybe just if !m_pService (but in that case the assert in 
addToMimeAppsList already failed when mimeType is set).


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125691/#review87487
---


On Oct. 18, 2015, 4:09 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125691/
> ---
> 
> (Updated Oct. 18, 2015, 4:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> If qMimeType is empty, addToMimeAppsList shouldn't be called.
> 
> 
> Diffs
> -
> 
>   src/widgets/kopenwithdialog.cpp c60a193 
> 
> Diff: https://git.reviewboard.kde.org/r/125691/diff/
> 
> 
> Testing
> ---
> 
> opening new KOpenWithDialog() without mimeType and typing eg "dolphin" to 
> exec line now correctly returns valid KService.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125819: Use KDE_INSTALL_FULL_DBUSINTERFACEDIR to install dbus interfaces

2015-10-27 Thread Heiko Becker 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125819/
---

(Updated Okt. 27, 2015, 8:41 vorm.)


Review request for KDE Frameworks.


Changes
---

A slightly different approach without the _FULL_ variable


Repository: kwallet


Description
---

Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- It's helpful on a multiarch layout where the prefix is /usr/${host}
  but arch-independent files should still be installed to /usr/share.


Diffs (updated)
-

  src/api/KWallet/KF5WalletConfig.cmake.in 
82a18aa342d7e4abcde3fadec0b0dc802a2ef4ef 
  src/api/KWallet/CMakeLists.txt 539b034d20a0e10ef7471bcc515b7b3885d617d6 

Diff: https://git.reviewboard.kde.org/r/125819/diff/


Testing
---

Successfully installed it with 
-DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and 
-DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share


Thanks,

Heiko Becker

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125803: KBuildSycoca: always save, even if no change in .desktop file was noticed.

2015-10-27 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125803/
---

(Updated Oct. 27, 2015, 7:40 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Albert Astals Cid.


Changes
---

Submitted with commit 0f816ab3fada9f57e836da78470003dd24d26a27 by David Faure 
to branch master.


Repository: kservice


Description
---

This fixes the case where a directory is "touched", so when KSycoca
compares directory timestamps it decides to rebuild, but then KBuildSycoca
doesn't find any real change and doesn't save. This can then happen
all over again at the next timestamp check.

CCBUG: 353203


Diffs
-

  autotests/ksycocatest.cpp f0df0b2a0fa4cb8e1bbba641db99e576a0399b4b 
  src/sycoca/kbuildsycoca.cpp 1deae14b8546d87b2f8d94510ae0d7077f377fb0 
  src/sycoca/ksycoca.cpp a692bc87ca1ca4bc1885e9ace3454470a0205ac4 

Diff: https://git.reviewboard.kde.org/r/125803/diff/


Testing
---

ksycocatest was failing on CI, I changed XDG_CONFIG_DIRS in the unittest and 
then I could replicate the problem.
ksycocatest passes again with this fix.


Thanks,

David Faure

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125691: KOpenWithDialog: Fix creating desktop file with empty mimetype

2015-10-27 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125691/#review87487
---


Ah OK. When creating a KOpenWithDialog without a mimetype argument, and then 
calling KOpenWithDialog::setSaveNewApplications(true), it's not because you 
want to remember a mimetype association, but because you want a .desktop file 
to be created (I suppose this is about 
http://lxr.kde.org/source/kde/workspace/kdeplasma-addons/applets/quicklaunch/plugin/quicklaunch_p.cpp
 ?).
Now I understand the use case ;)


src/widgets/kopenwithdialog.cpp (line 970)


This else should be removed, then.

There's no reason to only set m_pService when mimetype is empty. It's your 
use case, but why not set it consistently for all use cases, mimetype or no 
mimetype set?


- David Faure


On Oct. 18, 2015, 4:09 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125691/
> ---
> 
> (Updated Oct. 18, 2015, 4:09 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> If qMimeType is empty, addToMimeAppsList shouldn't be called.
> 
> 
> Diffs
> -
> 
>   src/widgets/kopenwithdialog.cpp c60a193 
> 
> Diff: https://git.reviewboard.kde.org/r/125691/diff/
> 
> 
> Testing
> ---
> 
> opening new KOpenWithDialog() without mimeType and typing eg "dolphin" to 
> exec line now correctly returns valid KService.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125797: protocoltojson application

2015-10-27 Thread Alex Richardson 


> On Oct. 26, 2015, 5:27 p.m., Alex Richardson wrote:
> > The protocoltojson program will have to read the plugin metadata.json file 
> > to insert the "KDE-KIO-Protocols" to that json file as it is not possible 
> > to embed more than one JSON file into a Qt plugin.
> > 
> > I am not sure whether we need a CMake macro, to me this is a conversion 
> > that should be done once and then we store the JSON file in the repository 
> > so that we don't increase the build time.
> 
> Christoph Cullmann wrote:
> Actually ioslaves have atm no other json stored, this would be the only 
> meta data added to them, I think no ioslave is at all a qt plugin and to stay 
> compatible, I would only add a dummy class there with this json embedded to 
> have the meta data available. But perhaps I am mistaken.
> For the one time conversion: I am not sure that the .protocol files will 
> be deprecated, I thought to do it like ATM for the .desktop files for the 
> plugins for which we kept the .desktop files, too.
> 
> David Faure wrote:
> IIRC we kept .desktop files because there was no other way to translate 
> them, back then.
> 
> But that's not an issue anymore, and not an issue for .protocol files 
> anyway.
> 
> So when converting an ioslave to json, rather than just change its 
> cmakelists, we could also just convert the .protocol to json, either with a 
> one-time conversion tool (now that you wrote it...) or by hand, reading some 
> documentation on the format.
> Seems simpler than more cmake magic.
> 
> KIO will need to keep being able to parse .protocol files anyway, for 
> compat reasons, that's unrelated.
> 
> Christoph Cullmann wrote:
> Ok ;) That makes its easier, no cmake foo needed, cool.
> For the second issue: I am right, or? There is no other meta data we need 
> inside the io slave?
> 
> Christoph Cullmann wrote:
> My idea would be to add some:
> 
> /**
>  * Pseudo plugin class to embedd meta data
>  */
> class KIOPluginForMetaData : public QObject
> {
> Q_OBJECT
> Q_PLUGIN_METADATA(IID "org.kde.kio.slave.http" FILE "http.json")
> };
> 
> to each slave that then uses the meta data json as above.
> 
> Moc will then embedd that like needed and no more stuff is needed to have 
> the protocols meta data in the .so files, at least that seems to work for me.

Ah I thought there was already some JSON embedded. This makes it much simpler.
I don't think any of the default KPluginMetaData values are useful for 
KIOSlaves (e.g. Icon can be different for each protocol) so only having these 
JSON keys should be fine.
We can always add KPlugin { foo: "" } later if we need it.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125797/#review87444
---


On Oct. 26, 2015, 5:03 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125797/
> ---
> 
> (Updated Oct. 26, 2015, 5:03 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Application to convert multiple .protocol files into on json map.
> If this is acceptable my next steps would be:
> 
> 1) use this, to generate json files and embedded them in io slaves
> 2) extend the protocol factory to search in the embedded files
> 
> That would make the protocol factory parts of: 
> https://git.reviewboard.kde.org/r/125778/ not needed.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt f65ad8e 
>   src/protocoltojson/CMakeLists.txt PRE-CREATION 
>   src/protocoltojson/main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125797/diff/
> 
> 
> Testing
> ---
> 
> Feed in http slave files: 
> 
> ./protocoltojson -o http.json 
> /local/cullmann/kf5/src/frameworks/kio/src/ioslaves/http/*.protocol
> 
> We get mapping:
> 
> {
> "http": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "output": "filesystem",
> "protocol": "http",
> "reading": true,
> "writing": true
> },
> "https": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "config": "http",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
>

Re: Review Request 125797: protocoltojson application

2015-10-27 Thread Christoph Cullmann 


> On Oct. 26, 2015, 5:27 p.m., Alex Richardson wrote:
> > The protocoltojson program will have to read the plugin metadata.json file 
> > to insert the "KDE-KIO-Protocols" to that json file as it is not possible 
> > to embed more than one JSON file into a Qt plugin.
> > 
> > I am not sure whether we need a CMake macro, to me this is a conversion 
> > that should be done once and then we store the JSON file in the repository 
> > so that we don't increase the build time.
> 
> Christoph Cullmann wrote:
> Actually ioslaves have atm no other json stored, this would be the only 
> meta data added to them, I think no ioslave is at all a qt plugin and to stay 
> compatible, I would only add a dummy class there with this json embedded to 
> have the meta data available. But perhaps I am mistaken.
> For the one time conversion: I am not sure that the .protocol files will 
> be deprecated, I thought to do it like ATM for the .desktop files for the 
> plugins for which we kept the .desktop files, too.
> 
> David Faure wrote:
> IIRC we kept .desktop files because there was no other way to translate 
> them, back then.
> 
> But that's not an issue anymore, and not an issue for .protocol files 
> anyway.
> 
> So when converting an ioslave to json, rather than just change its 
> cmakelists, we could also just convert the .protocol to json, either with a 
> one-time conversion tool (now that you wrote it...) or by hand, reading some 
> documentation on the format.
> Seems simpler than more cmake magic.
> 
> KIO will need to keep being able to parse .protocol files anyway, for 
> compat reasons, that's unrelated.
> 
> Christoph Cullmann wrote:
> Ok ;) That makes its easier, no cmake foo needed, cool.
> For the second issue: I am right, or? There is no other meta data we need 
> inside the io slave?
> 
> Christoph Cullmann wrote:
> My idea would be to add some:
> 
> /**
>  * Pseudo plugin class to embedd meta data
>  */
> class KIOPluginForMetaData : public QObject
> {
> Q_OBJECT
> Q_PLUGIN_METADATA(IID "org.kde.kio.slave.http" FILE "http.json")
> };
> 
> to each slave that then uses the meta data json as above.
> 
> Moc will then embedd that like needed and no more stuff is needed to have 
> the protocols meta data in the .so files, at least that seems to work for me.
> 
> Alex Richardson wrote:
> Ah I thought there was already some JSON embedded. This makes it much 
> simpler.
> I don't think any of the default KPluginMetaData values are useful for 
> KIOSlaves (e.g. Icon can be different for each protocol) so only having these 
> JSON keys should be fine.
> We can always add KPlugin { foo: "" } later if we need it.

I would keep the 

{
"KDE-KIO-Protocols": {
"http": {


}

namespace, later than like you said we could have some "KPlugin" in addition 
and I don't need to sort such stuff out then during the collection of the 
protocols.

Is that otherwise fine? If yes, I would like to commit this and then continue 
in a new review request the embedding of this in one example slave, http, and 
the extension of the protocolinfo/factory to read this in addition to the 
.protocol files.


- Christoph


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125797/#review87444
---


On Oct. 26, 2015, 5:03 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125797/
> ---
> 
> (Updated Oct. 26, 2015, 5:03 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Application to convert multiple .protocol files into on json map.
> If this is acceptable my next steps would be:
> 
> 1) use this, to generate json files and embedded them in io slaves
> 2) extend the protocol factory to search in the embedded files
> 
> That would make the protocol factory parts of: 
> https://git.reviewboard.kde.org/r/125778/ not needed.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt f65ad8e 
>   src/protocoltojson/CMakeLists.txt PRE-CREATION 
>   src/protocoltojson/main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125797/diff/
> 
> 
> Testing
> ---
> 
> Feed in http slave files: 
> 
> ./protocoltojson -o http.json 
> /local/cullmann/kf5/src/frameworks/kio/src/ioslaves/http/*.protocol
> 
> We get mapping:
> 
> {
> "http": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
>

Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 123 - Still Unstable!

2015-10-27 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/123/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Tue, 27 Oct 2015 11:07:23 +
Build duration: 3 min 21 sec

CHANGE SET
Revision 73712057b254b709569ee5a4eaea6478daafe90e by Marco Martin: (remove 
conflicting files)
  change: delete src/desktoptheme/breeze/widgets/timer.svgz
  change: delete src/desktoptheme/breeze/widgets/notes.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3915/10047 
(39%)CONDITIONAL 1916/3034 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 542/565 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 356/2004 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1591/3640 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 945/1746 
(54%)CONDITIONAL 394/600 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/194 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 481/1785 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 114 - Still Unstable!

2015-10-27 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/114/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Tue, 27 Oct 2015 11:07:23 +
Build duration: 3 min 7 sec

CHANGE SET
Revision 73712057b254b709569ee5a4eaea6478daafe90e by Marco Martin: (remove 
conflicting files)
  change: delete src/desktoptheme/breeze/widgets/notes.svgz
  change: delete src/desktoptheme/breeze/widgets/timer.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.dialognativetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 63/104 (61%)CLASSES 63/104 (61%)LINE 3912/10009 
(39%)CONDITIONAL 1919/3036 (63%)

By packages
  
autotests
FILES 20/20 (100%)CLASSES 20/20 (100%)LINE 543/564 
(96%)CONDITIONAL 338/606 (56%)
src.declarativeimports.core
FILES 7/20 (35%)CLASSES 7/20 (35%)LINE 355/2003 
(18%)CONDITIONAL 148/228 (65%)
src.plasma
FILES 14/21 (67%)CLASSES 14/21 (67%)LINE 1588/3635 
(44%)CONDITIONAL 776/1192 (65%)
src.plasma.private
FILES 18/26 (69%)CLASSES 18/26 (69%)LINE 946/1739 
(54%)CONDITIONAL 397/602 (66%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/184 (0%)CONDITIONAL 0/0 
(100%)
src.plasmaquick
FILES 4/11 (36%)CLASSES 4/11 (36%)LINE 480/1771 
(27%)CONDITIONAL 260/408 (64%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125797: protocoltojson application

2015-10-27 Thread Alex Richardson 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125797/#review87527
---

Ship it!


- Alex Richardson


On Oct. 26, 2015, 5:03 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125797/
> ---
> 
> (Updated Oct. 26, 2015, 5:03 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Application to convert multiple .protocol files into on json map.
> If this is acceptable my next steps would be:
> 
> 1) use this, to generate json files and embedded them in io slaves
> 2) extend the protocol factory to search in the embedded files
> 
> That would make the protocol factory parts of: 
> https://git.reviewboard.kde.org/r/125778/ not needed.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt f65ad8e 
>   src/protocoltojson/CMakeLists.txt PRE-CREATION 
>   src/protocoltojson/main.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125797/diff/
> 
> 
> Testing
> ---
> 
> Feed in http slave files: 
> 
> ./protocoltojson -o http.json 
> /local/cullmann/kf5/src/frameworks/kio/src/ioslaves/http/*.protocol
> 
> We get mapping:
> 
> {
> "http": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "output": "filesystem",
> "protocol": "http",
> "reading": true,
> "writing": true
> },
> "https": {
> "Class": ":internet",
> "Icon": "text-html",
> "X-DocPath": "kioslave5/http/index.html",
> "config": "http",
> "defaultMimetype": "application/octet-stream",
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "output": "filesystem",
> "protocol": "https",
> "reading": true,
> "writing": true
> },
> "webdav": {
> "Class": ":internet",
> "Icon": "folder-remote",
> "X-DocPath": "kioslave5/webdav/index.html",
> "defaultMimetype": "application/octet-stream",
> "deleteRecursive": true,
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "listing": [
> "Name",
> "Type",
> "Size",
> "Date",
> "AccessDate",
> "Access"
> ],
> "makedir": true,
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "moving": true,
> "output": "filesystem",
> "protocol": "webdav",
> "reading": true,
> "writing": true
> },
> "webdavs": {
> "Class": ":internet",
> "Icon": "folder-remote",
> "X-DocPath": "kioslave5/webdav/index.html",
> "config": "webdav",
> "defaultMimetype": "application/octet-stream",
> "deleteRecursive": true,
> "deleting": true,
> "determineMimetypeFromExtension": false,
> "exec": "kf5/kio/http",
> "input": "none",
> "listing": [
> "Name",
> "Type",
> "Size",
> "Date",
> "AccessDate",
> "Access"
> ],
> "makedir": true,
> "maxInstances": 20,
> "maxInstancesPerHost": 5,
> "moving": true,
> "output": "filesystem",
> "protocol": "webdavs",
> "reading": true,
> "writing": true
> }
> }
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125797: protocoltojson application

2015-10-27 Thread Christoph Cullmann 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125797/
---

(Updated Oct. 27, 2015, 4:54 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Alex Richardson and David Faure.


Changes
---

Submitted with commit d15083dcfe01dc256f376c346ddfb14c7a389b95 by Christoph 
Cullmann to branch master.


Repository: kio


Description
---

Application to convert multiple .protocol files into on json map.
If this is acceptable my next steps would be:

1) use this, to generate json files and embedded them in io slaves
2) extend the protocol factory to search in the embedded files

That would make the protocol factory parts of: 
https://git.reviewboard.kde.org/r/125778/ not needed.


Diffs
-

  src/CMakeLists.txt f65ad8e 
  src/protocoltojson/CMakeLists.txt PRE-CREATION 
  src/protocoltojson/main.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125797/diff/


Testing
---

Feed in http slave files: 

./protocoltojson -o http.json 
/local/cullmann/kf5/src/frameworks/kio/src/ioslaves/http/*.protocol

We get mapping:

{
"http": {
"Class": ":internet",
"Icon": "text-html",
"X-DocPath": "kioslave5/http/index.html",
"defaultMimetype": "application/octet-stream",
"deleting": true,
"determineMimetypeFromExtension": false,
"exec": "kf5/kio/http",
"input": "none",
"maxInstances": 20,
"maxInstancesPerHost": 5,
"output": "filesystem",
"protocol": "http",
"reading": true,
"writing": true
},
"https": {
"Class": ":internet",
"Icon": "text-html",
"X-DocPath": "kioslave5/http/index.html",
"config": "http",
"defaultMimetype": "application/octet-stream",
"deleting": true,
"determineMimetypeFromExtension": false,
"exec": "kf5/kio/http",
"input": "none",
"maxInstances": 20,
"maxInstancesPerHost": 5,
"output": "filesystem",
"protocol": "https",
"reading": true,
"writing": true
},
"webdav": {
"Class": ":internet",
"Icon": "folder-remote",
"X-DocPath": "kioslave5/webdav/index.html",
"defaultMimetype": "application/octet-stream",
"deleteRecursive": true,
"deleting": true,
"determineMimetypeFromExtension": false,
"exec": "kf5/kio/http",
"input": "none",
"listing": [
"Name",
"Type",
"Size",
"Date",
"AccessDate",
"Access"
],
"makedir": true,
"maxInstances": 20,
"maxInstancesPerHost": 5,
"moving": true,
"output": "filesystem",
"protocol": "webdav",
"reading": true,
"writing": true
},
"webdavs": {
"Class": ":internet",
"Icon": "folder-remote",
"X-DocPath": "kioslave5/webdav/index.html",
"config": "webdav",
"defaultMimetype": "application/octet-stream",
"deleteRecursive": true,
"deleting": true,
"determineMimetypeFromExtension": false,
"exec": "kf5/kio/http",
"input": "none",
"listing": [
"Name",
"Type",
"Size",
"Date",
"AccessDate",
"Access"
],
"makedir": true,
"maxInstances": 20,
"maxInstancesPerHost": 5,
"moving": true,
"output": "filesystem",
"protocol": "webdavs",
"reading": true,
"writing": true
}
}


Thanks,

Christoph Cullmann

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125830: Read protocol info from plugin metadata

2015-10-27 Thread Christoph Cullmann 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125830/
---

Review request for KDE Frameworks, Alex Richardson and David Faure.


Repository: kio


Description
---

Extends the protocol factory and co. to allow reading of protocol data from 
embedded json.
Allows to deploy io slaves without anything else than the io slave itself in 
librarypath kf5/kio.

I changed to factory to ALWAYS fill its cache for any request, as now the 
determination which protocols are around is more expensive than just some 
directory traversal.

If this preview is ok, I will do that for all other shipped slaves and update 
this request.


Diffs
-

  src/core/kprotocolinfo.cpp 8a02f7a 
  src/core/kprotocolinfo_p.h c3dea6b 
  src/core/kprotocolinfofactory.cpp 29ba8f4 
  src/core/kprotocolinfofactory_p.h aa79fc5 
  src/ioslaves/http/http.cpp 1727d41 
  src/ioslaves/http/http.json PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125830/diff/


Testing
---

http slave still seems to be found and work.


Thanks,

Christoph Cullmann

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125817: Add plugin system for Calendar events

2015-10-27 Thread Martin Klapetek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125817/
---

(Updated Oct. 27, 2015, 7:30 p.m.)


Review request for KDE Frameworks, Plasma and Daniel Vrátil.


Changes
---

Changes:
* uses QDate as the hash key
* uses dpointer for EventData
* added signals for eventModified and eventRemoved
* added eventColor property to set calendar colors
* improved the docs for isAllDay
* generated export header
* addressed the rest of the comments


Repository: plasma-framework


Description
---

This adds a simple plugin interface that can be subclassed
and provide events integration with Plasma Calendar applet.

It's asynchronous and I've kept it deliberately simple.
For now the Calendar tells the plugins which date range
is being displayed, the plugins load the data and then
emit the dataReady() signal containing the events.

The events are stored in a multihash for quick access
by the Calendar's agenda part but also for overall
easy-to-use (eg. in teh model data()).

The event data is stored in EventData class, which has
a pretty self-explanatory members, except perhaps the
"isMinor" one. The intention with this is to support
namedays, where in some countries the calendars have
different name every day. This is just a minor holiday
and as such should not mark the calendar grid, otherwise
the whole grid would be in a different color.

Putting the interface here might raise the question of
depending on plasma-framework, but plugins provided by
KDE can go to plasma-workspace and other 3rd party ones
would just have to live with it. I don't think it will
be a problem but if it turns out it is, we can rethink
the placement.


Diffs (updated)
-

  src/declarativeimports/calendar/CMakeLists.txt 40ead91 
  src/declarativeimports/calendar/calendarplugin.cpp bafe80c 
  src/declarativeimports/calendar/daysmodel.h a5bdac9 
  src/declarativeimports/calendar/daysmodel.cpp 2d059a8 
  src/declarativeimports/calendar/eventdatadecorator.h PRE-CREATION 
  src/declarativeimports/calendar/eventdatadecorator.cpp PRE-CREATION 
  src/declarativeimports/calendar/plasmacalendarintegration/CMakeLists.txt 
PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/PlasmaCalendarIntegrationConfig.cmake.in
 PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.h
 PRE-CREATION 
  
src/declarativeimports/calendar/plasmacalendarintegration/calendareventsplugin.cpp
 PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125817/diff/


Testing
---

I have a simple KHolidays based plugin written (patch should be up later today)
and patches in the Calendar applet.

Everything works as expected:
* the days are marked as containing an event
* the agenda part displays details of that event (name)


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 125819: Use KDE_INSTALL_FULL_DBUSINTERFACEDIR to install dbus interfaces

2015-10-27 Thread Heiko Becker 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125819/
---

(Updated Oct. 27, 2015, 6:46 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 59509139a33829a5b76424d2a8c1cb2f3b885580 by Heiko Becker 
to branch master.


Repository: kwallet


Description
---

Two reasons to do this:
- DBUS_INTERFACES_INSTALL_DIR is marked deprecated
- It's helpful on a multiarch layout where the prefix is /usr/${host}
  but arch-independent files should still be installed to /usr/share.


Diffs
-

  src/api/KWallet/KF5WalletConfig.cmake.in 
82a18aa342d7e4abcde3fadec0b0dc802a2ef4ef 
  src/api/KWallet/CMakeLists.txt 539b034d20a0e10ef7471bcc515b7b3885d617d6 

Diff: https://git.reviewboard.kde.org/r/125819/diff/


Testing
---

Successfully installed it with 
-DCMAKE_INSTALL_PREFIX:PATH=/usr/x86_64-pc-linux-gnu and 
-DCMAKE_INSTALL_FULL_DATAROOTDIR:PATH=/usr/share


Thanks,

Heiko Becker

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125343: bump so version from 5 to 6

2015-10-27 Thread Martin Klapetek 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125343/#review87548
---


Ping; John, can you have a look please?

- Martin Klapetek


On Sept. 22, 2015, 10:02 a.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125343/
> ---
> 
> (Updated Sept. 22, 2015, 10:02 a.m.)
> 
> 
> Review request for KDE Frameworks, Daniel Vrátil and John Layt.
> 
> 
> Repository: kholidays
> 
> 
> Description
> ---
> 
> since Applications/15.08 KHolidays::HolidayRegionSelector was removed
> constituting an incompatible change.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt ebd4b8981a658665a42140250b6eb3d92662e607 
> 
> Diff: https://git.reviewboard.kde.org/r/125343/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125830: Read protocol info from plugin metadata

2015-10-27 Thread Alex Merry 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125830/#review87558
---



src/core/kprotocolinfo.cpp (lines 121 - 122)


I would still rather calculate this information - protocol is the key from 
the iterated map, and exec is (I think) the base name of the file the JSON was 
extracted from. These could be passed in as separate parameters.

exec in particular is a case of easily eliminating a place people could 
make mistakes. It also allows the binaries to be freely renamed (although 
that's not an important feature, really).


- Alex Merry


On Oct. 27, 2015, 5:43 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 27, 2015, 5:43 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QVariant precision issues

2015-10-27 Thread David Edmundson 
qFuzzyCompare ?
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125830: Read protocol info from plugin metadata

2015-10-27 Thread Christoph Cullmann 


> On Oct. 27, 2015, 10:23 p.m., Alex Merry wrote:
> > src/core/kprotocolinfo.cpp, lines 121-122
> > 
> >
> > I would still rather calculate this information - protocol is the key 
> > from the iterated map, and exec is (I think) the base name of the file the 
> > JSON was extracted from. These could be passed in as separate parameters.
> > 
> > exec in particular is a case of easily eliminating a place people could 
> > make mistakes. It also allows the binaries to be freely renamed (although 
> > that's not an important feature, really).

You are right ;=)
I wanted to do that later anyway, done now.


- Christoph


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125830/#review87558
---


On Oct. 27, 2015, 10:31 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 27, 2015, 10:31 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

QVariant precision issues

2015-10-27 Thread Albert Astals Cid 
Hi, i remember a while ago an issue with QVariant not storing doubles the same 
way it used to in this list.

We seem to have hit that in step
https://build.kde.org/job/step%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/
19/testReport/%28root%29/TestSuite/stepcore_test_metaobject/

Does anyone remember what was the fix/workaround?

Cheers,
  Albert
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: QVariant precision issues

2015-10-27 Thread Christoph Cullmann 
Hi,

i guess the test should use values representable, e.g not stuff like 0.2. 
doubles are stored in 2 not 10 base.

Greetings
Christoph

- Albert Astals Cid  schrieb:
> Hi, i remember a while ago an issue with QVariant not storing doubles the 
> same 
> way it used to in this list.
> 
> We seem to have hit that in step
> https://build.kde.org/job/step%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/
> 19/testReport/%28root%29/TestSuite/stepcore_test_metaobject/
> 
> Does anyone remember what was the fix/workaround?
> 
> Cheers,
>   Albert
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125800: OS X build and warning fix

2015-10-27 Thread Samuel Gaist 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125800/
---

(Updated Oct. 27, 2015, 11:01 p.m.)


Review request for KDE Frameworks and Ivan Romanov.


Repository: qca


Description
---

The cmake find file was missing, but CoreFoundation being a system
framework, no need to search for it.

OS X: Update code to not use deprecated functions/data structure

CSSM_DATA and SecCertificateGetData have been deprecated since 10.7.
This patch uses SecCertificateCopyData which is the official
replacement.


Diffs (updated)
-

  CMakeLists.txt dbce08272deb284f3cb0fd09ccfec4ab93ce3e23 
  src/CMakeLists.txt a60bda0bf3d8bad7523ee7d50798c8cdb6c2eccb 
  src/qca_systemstore_mac.cpp 9349c90c8258d3d1f00a3796d93f94c09f5b1f2a 

Diff: https://git.reviewboard.kde.org/r/125800/diff/


Testing
---

Build on OS X 10.8

Check that qcatool-qt5 keystore list-stores returns the same results


Thanks,

Samuel Gaist

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125830: Read protocol info from plugin metadata

2015-10-27 Thread Alex Richardson 

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125830/#review87561
---


Looks good to me if it still works. 

I don't really like all the code being duplicated with config.readEntry() 
changing to value().toFoo() but I don't see an easy way to avoid the 
duplication.


src/core/kprotocolinfo.cpp (line 126)


toBool() has has bool defaultValue parameter which could be used instead



src/core/kprotocolinfofactory.cpp (line 87)


Probably easier to use KPluginLoader::findPlugins() instead, it only 
returns plugins with metadata:

Something like this should work (untested)

```
foreach (const KPluginMetaData& md : KPluginLoader::findPlugins("kf5/kio")) 
{
const QString slavePath = md.fileName()
const QJsonObject 
protocols(md.rawData().value(QStringLiteral("KDE-KIO-Protocols")).toObject());
// add all protocols, does nothing if object invalid

for (auto it = protocols.begin(); it != protocols.end(); ++it) {
// skip empty objects
const QJsonObject protocol(it.value().toObject());
if (protocol.isEmpty()) {
continue;
}

// add to cache, skip double entries
if (!m_cache.contains(it.key())) {
m_cache.insert(it.key(), new KProtocolInfoPrivate(it.key(), 
slavePath, protocol));
}

}
```


- Alex Richardson


On Oct. 27, 2015, 10:31 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 27, 2015, 10:31 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel