Re: Review Request 129170: Add KArchive::errorString() method to provide more details on KArchive errors

2016-11-01 Thread David Faure


> On Oct. 30, 2016, 10:59 p.m., David Faure wrote:
> > src/k7zip.cpp, line 2499
> > 
> >
> > Translators (and users) won't know what CTime is, but oh well, not many 
> > people know anyway ;)
> 
> Romário Rios wrote:
> I'm not sure what it is either, which is why I kept the message intact -- 
> same applies to the ATime and MTime error messages.
> 
> Any idea of a better message?

ATime => access time
MTime => modification time
CTime => technically it's the "inode change time", in practice I would remove 
the corresponding code because it's completely useless anyway.


- David


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


On Nov. 1, 2016, 8:10 p.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129170/
> ---
> 
> (Updated Nov. 1, 2016, 8:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: karchive
> 
> 
> Description
> ---
> 
> This method is similar to `QIODevice::errorString()`. I added a public 
> `errorString()` method and a protected `setErrorString()` method, to allow 
> `KArchive`'s subclasses to implement their own error messages. I also 
> implemented most error messages from most subclasses.
> 
> 
> Diffs
> -
> 
>   autotests/karchivetest.cpp d0fbf41 
>   src/k7zip.h 5b95f49 
>   src/k7zip.cpp 692b1db 
>   src/kar.h 85bd650 
>   src/kar.cpp 7204fb1 
>   src/karchive.h b528a4a 
>   src/karchive.cpp a1a160a 
>   src/karchive_p.h 256620d 
>   src/krcc.h 18c7d00 
>   src/krcc.cpp 1947dd6 
>   src/ktar.h 4bca898 
>   src/ktar.cpp f70b155 
>   src/kzip.h 84156c7 
>   src/kzip.cpp 94d4276 
> 
> Diff: https://git.reviewboard.kde.org/r/129170/diff/
> 
> 
> Testing
> ---
> 
> I added `QVERIFY` calls after all errors in `karchivetests.cpp`. Perhaps 
> we'll need more tests, but I'm not sure how to make an archive to fail in 
> some specific way aside from the very basics ("file not found", etc.).
> 
> 
> Thanks,
> 
> Romário Rios
> 
>



Re: Review Request 129170: Add KArchive::errorString() method to provide more details on KArchive errors

2016-11-01 Thread Romário Rios

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

(Updated Nov. 1, 2016, 8:10 p.m.)


Review request for KDE Frameworks.


Changes
---

Fix issues pointed out by David


Repository: karchive


Description
---

This method is similar to `QIODevice::errorString()`. I added a public 
`errorString()` method and a protected `setErrorString()` method, to allow 
`KArchive`'s subclasses to implement their own error messages. I also 
implemented most error messages from most subclasses.


Diffs (updated)
-

  autotests/karchivetest.cpp d0fbf41 
  src/k7zip.h 5b95f49 
  src/k7zip.cpp 692b1db 
  src/kar.h 85bd650 
  src/kar.cpp 7204fb1 
  src/karchive.h b528a4a 
  src/karchive.cpp a1a160a 
  src/karchive_p.h 256620d 
  src/krcc.h 18c7d00 
  src/krcc.cpp 1947dd6 
  src/ktar.h 4bca898 
  src/ktar.cpp f70b155 
  src/kzip.h 84156c7 
  src/kzip.cpp 94d4276 

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


Testing
---

I added `QVERIFY` calls after all errors in `karchivetests.cpp`. Perhaps we'll 
need more tests, but I'm not sure how to make an archive to fail in some 
specific way aside from the very basics ("file not found", etc.).


Thanks,

Romário Rios



Re: Review Request 129170: Add KArchive::errorString() method to provide more details on KArchive errors

2016-11-01 Thread Romário Rios


> On Oct. 30, 2016, 10:59 p.m., David Faure wrote:
> > src/k7zip.cpp, line 2499
> > 
> >
> > Translators (and users) won't know what CTime is, but oh well, not many 
> > people know anyway ;)

I'm not sure what it is either, which is why I kept the message intact -- same 
applies to the ATime and MTime error messages.

Any idea of a better message?


- Romário


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


On Nov. 1, 2016, 8:10 p.m., Romário Rios wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129170/
> ---
> 
> (Updated Nov. 1, 2016, 8:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: karchive
> 
> 
> Description
> ---
> 
> This method is similar to `QIODevice::errorString()`. I added a public 
> `errorString()` method and a protected `setErrorString()` method, to allow 
> `KArchive`'s subclasses to implement their own error messages. I also 
> implemented most error messages from most subclasses.
> 
> 
> Diffs
> -
> 
>   autotests/karchivetest.cpp d0fbf41 
>   src/k7zip.h 5b95f49 
>   src/k7zip.cpp 692b1db 
>   src/kar.h 85bd650 
>   src/kar.cpp 7204fb1 
>   src/karchive.h b528a4a 
>   src/karchive.cpp a1a160a 
>   src/karchive_p.h 256620d 
>   src/krcc.h 18c7d00 
>   src/krcc.cpp 1947dd6 
>   src/ktar.h 4bca898 
>   src/ktar.cpp f70b155 
>   src/kzip.h 84156c7 
>   src/kzip.cpp 94d4276 
> 
> Diff: https://git.reviewboard.kde.org/r/129170/diff/
> 
> 
> Testing
> ---
> 
> I added `QVERIFY` calls after all errors in `karchivetests.cpp`. Perhaps 
> we'll need more tests, but I'm not sure how to make an archive to fail in 
> some specific way aside from the very basics ("file not found", etc.).
> 
> 
> Thanks,
> 
> Romário Rios
> 
>



Re: Review Request 129299: Warn on startup about ambiguous shortcuts (with an exception for Shift+Delete)

2016-11-01 Thread Albert Astals Cid


> On Nov. 1, 2016, 1:35 a.m., Aleix Pol Gonzalez wrote:
> > How about putting it in QDebug?
> > Message boxes could make us all miserable.
> 
> Albert Astals Cid wrote:
> Making us miserable is the point, that way you'll fix it, a qdebug is 
> something noone will even see. (Note this should not be seen *at all* if we 
> are seeing this, there's something either wrong with this or with your app)
> 
> Aleix Pol Gonzalez wrote:
> I understand that, but applications can't be fixed retroactively.

As far as i know, there's no application where the message is shown, maybe i 
can just add a "don't show me again" thing so in case a user finds a broken 
application she doesn't have to see the message every single time he launches 
it?


> On Nov. 1, 2016, 1:35 a.m., Aleix Pol Gonzalez wrote:
> > src/kxmlguiwindow.cpp, line 313
> > 
> >
> > How come this is the _only_ exception?
> 
> Albert Astals Cid wrote:
> Because it's the only case where our StandardActions actually have 
> conflicts. DeleteFile vs EditCut
> 
> Aleix Pol Gonzalez wrote:
> If kxmlgui allows itself to have an exception, applications might 
> eventually also need such exceptions.

I don't know what you mean, please explain what an application might want?


- Albert


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


On Oct. 31, 2016, 7:18 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129299/
> ---
> 
> (Updated Oct. 31, 2016, 7:18 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Elvis Angelaccio.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Add a warning at the createGui stage about ambiguous shortcuts being found in 
> the same action collection.
> 
> This is usually a developer issue, but the error message about ambiguity will 
> only show up when someone tries to use the shortcut, so it is relatively easy 
> to miss if you do not try all your actions via a shortcut.
> 
> Also if the involved shortcut is one of the non primary shortcuts of 
> edit_cut, just give it away, since it's usually Shift+Delete being fought 
> over.
> 
> 
> Diffs
> -
> 
>   src/kxmlguiwindow.cpp 519fb26 
> 
> Diff: https://git.reviewboard.kde.org/r/129299/diff/
> 
> 
> Testing
> ---
> 
> gwenview now defaults to Shift+Delete being "Hard delete" and not "Cut", if 
> you remove the 
>   if (action == editCutAction || existingShortcutAction == editCutAction) {
> part, you get warning about the actions involved
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>



Re: Review Request 129299: Warn on startup about ambiguous shortcuts (with an exception for Shift+Delete)

2016-11-01 Thread Aleix Pol Gonzalez


> On Nov. 1, 2016, 2:35 a.m., Aleix Pol Gonzalez wrote:
> > How about putting it in QDebug?
> > Message boxes could make us all miserable.
> 
> Albert Astals Cid wrote:
> Making us miserable is the point, that way you'll fix it, a qdebug is 
> something noone will even see. (Note this should not be seen *at all* if we 
> are seeing this, there's something either wrong with this or with your app)

I understand that, but applications can't be fixed retroactively.


> On Nov. 1, 2016, 2:35 a.m., Aleix Pol Gonzalez wrote:
> > src/kxmlguiwindow.cpp, line 313
> > 
> >
> > How come this is the _only_ exception?
> 
> Albert Astals Cid wrote:
> Because it's the only case where our StandardActions actually have 
> conflicts. DeleteFile vs EditCut

If kxmlgui allows itself to have an exception, applications might eventually 
also need such exceptions.


- Aleix


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


On Oct. 31, 2016, 8:18 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129299/
> ---
> 
> (Updated Oct. 31, 2016, 8:18 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Elvis Angelaccio.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Add a warning at the createGui stage about ambiguous shortcuts being found in 
> the same action collection.
> 
> This is usually a developer issue, but the error message about ambiguity will 
> only show up when someone tries to use the shortcut, so it is relatively easy 
> to miss if you do not try all your actions via a shortcut.
> 
> Also if the involved shortcut is one of the non primary shortcuts of 
> edit_cut, just give it away, since it's usually Shift+Delete being fought 
> over.
> 
> 
> Diffs
> -
> 
>   src/kxmlguiwindow.cpp 519fb26 
> 
> Diff: https://git.reviewboard.kde.org/r/129299/diff/
> 
> 
> Testing
> ---
> 
> gwenview now defaults to Shift+Delete being "Hard delete" and not "Cut", if 
> you remove the 
>   if (action == editCutAction || existingShortcutAction == editCutAction) {
> part, you get warning about the actions involved
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>



Jenkins-kde-ci: knotifyconfig master kf5-qt5 » Linux,gcc - Build # 248 - Fixed!

2016-11-01 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/knotifyconfig%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/248/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 01 Nov 2016 17:54:02 +
Build duration: 1 min 35 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages
  

Jenkins-kde-ci: knotifyconfig master kf5-qt5 » Linux,gcc - Build # 248 - Fixed!

2016-11-01 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/knotifyconfig%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/248/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 01 Nov 2016 17:54:02 +
Build duration: 1 min 35 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages
  

Re: Review Request 129299: Warn on startup about ambiguous shortcuts (with an exception for Shift+Delete)

2016-11-01 Thread Albert Astals Cid


> On Nov. 1, 2016, 1:35 a.m., Aleix Pol Gonzalez wrote:
> > How about putting it in QDebug?
> > Message boxes could make us all miserable.

Making us miserable is the point, that way you'll fix it, a qdebug is something 
noone will even see. (Note this should not be seen *at all* if we are seeing 
this, there's something either wrong with this or with your app)


> On Nov. 1, 2016, 1:35 a.m., Aleix Pol Gonzalez wrote:
> > src/kxmlguiwindow.cpp, line 313
> > 
> >
> > How come this is the _only_ exception?

Because it's the only case where our StandardActions actually have conflicts. 
DeleteFile vs EditCut


- Albert


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


On Oct. 31, 2016, 7:18 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129299/
> ---
> 
> (Updated Oct. 31, 2016, 7:18 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Elvis Angelaccio.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Add a warning at the createGui stage about ambiguous shortcuts being found in 
> the same action collection.
> 
> This is usually a developer issue, but the error message about ambiguity will 
> only show up when someone tries to use the shortcut, so it is relatively easy 
> to miss if you do not try all your actions via a shortcut.
> 
> Also if the involved shortcut is one of the non primary shortcuts of 
> edit_cut, just give it away, since it's usually Shift+Delete being fought 
> over.
> 
> 
> Diffs
> -
> 
>   src/kxmlguiwindow.cpp 519fb26 
> 
> Diff: https://git.reviewboard.kde.org/r/129299/diff/
> 
> 
> Testing
> ---
> 
> gwenview now defaults to Shift+Delete being "Hard delete" and not "Cut", if 
> you remove the 
>   if (action == editCutAction || existingShortcutAction == editCutAction) {
> part, you get warning about the actions involved
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>



Jenkins-kde-ci: oxygen Plasma-5.8 stable-kf5-qt5 » Linux,gcc - Build # 11 - Still Failing!

2016-11-01 Thread no-reply

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/oxygen%20Plasma-5.8%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/11/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 01 Nov 2016 17:28:27 +
Build duration: 45 sec

CHANGE SET
No changes


Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Dan Leinir Turthra Jensen


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > if kns ends up using ids, maybe the server should be specified as well, 
> > as the id would be server-dependent?
> 
> Aleix Pol Gonzalez wrote:
> I'm not sure, either way we need changes in the KNS API, as the current 
> search in place won't work. I'd prefer if we could use rdn-like notation on 
> kns.
> 
> I don't think it should be server-dependent. If anything, if the user 
> changes the contents server, it might not find the component.
> 
> Dan Leinir Turthra Jensen wrote:
> Hmm... a knsrc points to a providers file, which in turn can hold more 
> than one provider. The providers in the provider file have an ID, so perhaps 
> we can use that? So we'd end up with e.g. 
> kns://colors.knsrc/api.kde-look.org/1159726 instead. While the api bit 
> looks like a server address, it's just the ID as found in the providers file 
> (and might be any string, technically), and so that would be enough (just) to 
> uniquely identify the item as found on a provider which (like with the kde 
> store) might have multiple "servers".
> 
> Marco Martin wrote:
> could a content be identified like org.joe.beautifulicontheme ?
> then the server having some function to resolve 
> org.joe.beautifulicontheme to its id like 137345

...what server? That is just another string ID (technically the number that you 
get in OCS is just a string, and at least one implementation (MidGard) uses 
that fact). i really don't see how we can get away with having anything less 
than two string IDs (server ID as defined in a providers.xml, and content ID as 
unique to that provider) to uniquely identify a content item... i also don't 
really see why it'd necessarily be better, in any real way other than 
aesthetics of the link, to have anything more concise than 
kns://knsrcfile/providerID/contentID (and possibly kns://providerID/contentID 
in cases of using the default provider as defined by kns internally, which 
resolves to using KDE's providers.xml).


- Dan Leinir Turthra


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


On Oct. 31, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129298/
> ---
> 
> (Updated Oct. 31, 2016, 5:09 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and 
> Marco Martin.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Makes it possible to specify components to be installed together with a 
> KPackage. They will be specified by a url, we'll have handlers for any kind, 
> making reasonably extensible and doesn't tie us to a technology.
> 
> In this repository I created two Proof of Concept of such handlers, one for 
> the appstream urls and one for KNS: kde:scratch/apol/kpackage-install-helpers
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 395b16e 
>   autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testpackagesdep/metadata.json PRE-CREATION 
>   autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION 
>   src/kpackage/config-package.h.cmake 61f2f0c 
>   src/kpackage/private/packagejobthread.cpp 0a0cc01 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
> 
> Diff: https://git.reviewboard.kde.org/r/129298/diff/
> 
> 
> Testing
> ---
> 
> None. just builds. It's a proof of concept, not even the test I added was 
> tested, it was just to display what it could look like.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Marco Martin


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > if kns ends up using ids, maybe the server should be specified as well, 
> > as the id would be server-dependent?
> 
> Aleix Pol Gonzalez wrote:
> I'm not sure, either way we need changes in the KNS API, as the current 
> search in place won't work. I'd prefer if we could use rdn-like notation on 
> kns.
> 
> I don't think it should be server-dependent. If anything, if the user 
> changes the contents server, it might not find the component.
> 
> Dan Leinir Turthra Jensen wrote:
> Hmm... a knsrc points to a providers file, which in turn can hold more 
> than one provider. The providers in the provider file have an ID, so perhaps 
> we can use that? So we'd end up with e.g. 
> kns://colors.knsrc/api.kde-look.org/1159726 instead. While the api bit 
> looks like a server address, it's just the ID as found in the providers file 
> (and might be any string, technically), and so that would be enough (just) to 
> uniquely identify the item as found on a provider which (like with the kde 
> store) might have multiple "servers".

could a content be identified like org.joe.beautifulicontheme ?
then the server having some function to resolve org.joe.beautifulicontheme to 
its id like 137345


- Marco


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


On Oct. 31, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129298/
> ---
> 
> (Updated Oct. 31, 2016, 5:09 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and 
> Marco Martin.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Makes it possible to specify components to be installed together with a 
> KPackage. They will be specified by a url, we'll have handlers for any kind, 
> making reasonably extensible and doesn't tie us to a technology.
> 
> In this repository I created two Proof of Concept of such handlers, one for 
> the appstream urls and one for KNS: kde:scratch/apol/kpackage-install-helpers
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 395b16e 
>   autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testpackagesdep/metadata.json PRE-CREATION 
>   autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION 
>   src/kpackage/config-package.h.cmake 61f2f0c 
>   src/kpackage/private/packagejobthread.cpp 0a0cc01 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
> 
> Diff: https://git.reviewboard.kde.org/r/129298/diff/
> 
> 
> Testing
> ---
> 
> None. just builds. It's a proof of concept, not even the test I added was 
> tested, it was just to display what it could look like.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>



Jenkins-kde-ci: oxygen Plasma-5.8 stable-kf5-qt5 » Linux,gcc - Build # 10 - Failure!

2016-11-01 Thread no-reply

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/oxygen%20Plasma-5.8%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/10/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 01 Nov 2016 11:37:42 +
Build duration: 1 min 24 sec

CHANGE SET
Revision 501585f2b39c28ccd4d2d9e465072a3eace5862d by Jonathan Riddell: (Update 
version number for 5.8.3 GIT_SILENT)
  change: edit CMakeLists.txt


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

2016-11-01 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/235/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Tue, 01 Nov 2016 10:06:05 +
Build duration: 5 min 25 sec

CHANGE SET
Revision e14a60f9a465b9b255739f2d1023d065ed0ab9a2 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit templates/qml-plasmoid/qml-plasmoid.kdevtemplate
  change: edit templates/cpp-plasmoid/cpp-plasmoid.kdevtemplate
  change: edit templates/plasma-wallpaper/plasma-wallpaper.kdevtemplate


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 15 test(s), Skipped: 0 test(s), Total: 
16 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 81/119 (68%)CLASSES 81/119 (68%)LINE 4898/11746 
(42%)CONDITIONAL 2639/8864 (30%)

By packages
  
autotests
FILES 28/28 (100%)CLASSES 28/28 (100%)LINE 981/1050 
(93%)CONDITIONAL 619/1238 (50%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 648/2129 
(30%)CONDITIONAL 300/1308 (23%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1660/3608 
(46%)CONDITIONAL 961/2705 (36%)
src.plasma.packagestructure
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 51/65 (78%)CONDITIONAL 
7/22 (32%)
src.plasma.private
FILES 14/24 (58%)CLASSES 14/24 (58%)LINE 928/1640 
(57%)CONDITIONAL 431/1068 (40%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 36/180 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 552/1825 
(30%)CONDITIONAL 300/1417 (21%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1136 (1%)CONDITIONAL 
1/978 (0%)

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

2016-11-01 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/235/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Tue, 01 Nov 2016 10:06:05 +
Build duration: 5 min 28 sec

CHANGE SET
Revision e14a60f9a465b9b255739f2d1023d065ed0ab9a2 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit templates/plasma-wallpaper/plasma-wallpaper.kdevtemplate
  change: edit templates/qml-plasmoid/qml-plasmoid.kdevtemplate
  change: edit templates/cpp-plasmoid/cpp-plasmoid.kdevtemplate


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 
15 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 9/9 (100%)FILES 78/115 (68%)CLASSES 78/115 (68%)LINE 4458/11228 
(40%)CONDITIONAL 2337/8460 (28%)

By packages
  
autotests
FILES 26/26 (100%)CLASSES 26/26 (100%)LINE 910/979 
(93%)CONDITIONAL 580/1162 (50%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 561/1880 
(30%)CONDITIONAL 217/1152 (19%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1658/3608 
(46%)CONDITIONAL 953/2705 (35%)
src.plasma.packagestructure
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 51/65 (78%)CONDITIONAL 
7/22 (32%)
src.plasma.private
FILES 13/22 (59%)CLASSES 13/22 (59%)LINE 878/1567 
(56%)CONDITIONAL 408/1022 (40%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 36/180 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 322/1700 
(19%)CONDITIONAL 151/1291 (12%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1136 (1%)CONDITIONAL 
1/978 (0%)

Re: Review Request 129299: Warn on startup about ambiguous shortcuts (with an exception for Shift+Delete)

2016-11-01 Thread Elvis Angelaccio


> On Oct. 31, 2016, 6:50 p.m., Elvis Angelaccio wrote:
> > src/kxmlguiwindow.cpp, line 327
> > 
> >
> > I think it would be better if this were not blocking (i.e. creating the 
> > QMessageBox manually and showing it with `open()`).
> > 
> > Otherwise the users get a messagebox instead of the main window of the 
> > app they started.
> 
> Albert Astals Cid wrote:
> I don't know, ideally it should only be only enabled for developer builds 
> but we do not have such flag, right?

Yeah. Btw this patch makes the app-side overrides no longer necessary, it 
seems. I tried to remove the override in Dolphin and shift+del still works (as 
force-delete). So +2 from me :)


- Elvis


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


On Oct. 31, 2016, 7:18 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129299/
> ---
> 
> (Updated Oct. 31, 2016, 7:18 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Elvis Angelaccio.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Add a warning at the createGui stage about ambiguous shortcuts being found in 
> the same action collection.
> 
> This is usually a developer issue, but the error message about ambiguity will 
> only show up when someone tries to use the shortcut, so it is relatively easy 
> to miss if you do not try all your actions via a shortcut.
> 
> Also if the involved shortcut is one of the non primary shortcuts of 
> edit_cut, just give it away, since it's usually Shift+Delete being fought 
> over.
> 
> 
> Diffs
> -
> 
>   src/kxmlguiwindow.cpp 519fb26 
> 
> Diff: https://git.reviewboard.kde.org/r/129299/diff/
> 
> 
> Testing
> ---
> 
> gwenview now defaults to Shift+Delete being "Hard delete" and not "Cut", if 
> you remove the 
>   if (action == editCutAction || existingShortcutAction == editCutAction) {
> part, you get warning about the actions involved
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>



Re: Review Request 129122: Try to use ulog-helper if utempter does not exist

2016-11-01 Thread Tobias Berner

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

(Updated Nov. 1, 2016, 9:42 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Adriaan de Groot, Gleb Popov, Oswald 
Buddenhagen, and Martin Tobias Holmedahl Sandsmark.


Changes
---

Submitted with commit 73c9dac629a59bb337168b47e0fd61975588b399 by Tobias C. 
Berner to branch master.


Repository: kpty


Description
---

FreeBSD does not have `/usr/libexec/*/utempter`. It does however have 
`/usr/libexec/ulog-helper` [1].

It uses `login` instead of `add` and `logout` instead of `del`.


[1] 
https://svnweb.freebsd.org/base/head/libexec/ulog-helper/ulog-helper.c?revision=234469&view=markup


Diffs
-

  cmake/FindUTEMPTER.cmake 4921e58 
  src/kpty.cpp 7bf31c3 

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


Testing
---

Builds fine. And it is actually working :)


Thanks,

Tobias Berner



Re: Review Request 129302: Fix include dir in pri file

2016-11-01 Thread David Rosca

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

(Updated Nov. 1, 2016, 11:39 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Jan Grulich.


Changes
---

Submitted with commit 4e295bcf03d3964d5675894053190a71a5288baa by David Rosca 
to branch master.


Repository: networkmanager-qt


Description
---

Currently the pri file has Qt.NetworkManagerQt.includes = 
/usr/include/NetworkManagerQt.
This changes fixes it and makes it /usr/include/KF5/NetworkManagerQt


Diffs
-

  src/CMakeLists.txt 3249154 

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


Testing
---

Correct include paths when used from qmake.
It still cannot be used from qmake without additional changes because 
`generictypes.h` includes `nm-version.h` from libnm which is not in include 
paths.


Thanks,

David Rosca



Re: Review Request 129303: Fix include dir in pri file

2016-11-01 Thread David Rosca

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

(Updated Nov. 1, 2016, 8:38 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Jan Grulich.


Changes
---

Submitted with commit 79725bf9892520538a6bde836ced583a65ea6767 by David Rosca 
to branch master.


Repository: modemmanager-qt


Description
---

Currently the pri file has Qt.ModemManagerQt.includes = 
/usr/include/ModemManagerQt.
This changes fixes it and makes it /usr/include/KF5/ModemManagerQt


Diffs
-

  src/CMakeLists.txt 29a7a63 

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


Testing
---

Correct include paths when used from qmake.


Thanks,

David Rosca



Re: Review Request 129303: Fix include dir in pri file

2016-11-01 Thread Jan Grulich

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


Ship it!




Ship It!

- Jan Grulich


On Lis. 1, 2016, 8:21 dop., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129303/
> ---
> 
> (Updated Lis. 1, 2016, 8:21 dop.)
> 
> 
> Review request for KDE Frameworks and Jan Grulich.
> 
> 
> Repository: modemmanager-qt
> 
> 
> Description
> ---
> 
> Currently the pri file has Qt.ModemManagerQt.includes = 
> /usr/include/ModemManagerQt.
> This changes fixes it and makes it /usr/include/KF5/ModemManagerQt
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 29a7a63 
> 
> Diff: https://git.reviewboard.kde.org/r/129303/diff/
> 
> 
> Testing
> ---
> 
> Correct include paths when used from qmake.
> 
> 
> Thanks,
> 
> David Rosca
> 
>



Re: Review Request 129302: Fix include dir in pri file

2016-11-01 Thread Jan Grulich

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


Ship it!




Not only generictypes.h includes NM headers, they are used in many places.

- Jan Grulich


On Lis. 1, 2016, 8:24 dop., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129302/
> ---
> 
> (Updated Lis. 1, 2016, 8:24 dop.)
> 
> 
> Review request for KDE Frameworks and Jan Grulich.
> 
> 
> Repository: networkmanager-qt
> 
> 
> Description
> ---
> 
> Currently the pri file has Qt.NetworkManagerQt.includes = 
> /usr/include/NetworkManagerQt.
> This changes fixes it and makes it /usr/include/KF5/NetworkManagerQt
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 3249154 
> 
> Diff: https://git.reviewboard.kde.org/r/129302/diff/
> 
> 
> Testing
> ---
> 
> Correct include paths when used from qmake.
> It still cannot be used from qmake without additional changes because 
> `generictypes.h` includes `nm-version.h` from libnm which is not in include 
> paths.
> 
> 
> Thanks,
> 
> David Rosca
> 
>



Re: Review Request 129298: RFC: supporting dependencies on KPackage

2016-11-01 Thread Dan Leinir Turthra Jensen


> On Oct. 31, 2016, 5:19 p.m., Marco Martin wrote:
> > autotests/data/testpackagesdep/metadata.json, line 14
> > 
> >
> > if kns ends up using ids, maybe the server should be specified as well, 
> > as the id would be server-dependent?
> 
> Aleix Pol Gonzalez wrote:
> I'm not sure, either way we need changes in the KNS API, as the current 
> search in place won't work. I'd prefer if we could use rdn-like notation on 
> kns.
> 
> I don't think it should be server-dependent. If anything, if the user 
> changes the contents server, it might not find the component.

Hmm... a knsrc points to a providers file, which in turn can hold more than one 
provider. The providers in the provider file have an ID, so perhaps we can use 
that? So we'd end up with e.g. kns://colors.knsrc/api.kde-look.org/1159726 
instead. While the api bit looks like a server address, it's just the ID as 
found in the providers file (and might be any string, technically), and so that 
would be enough (just) to uniquely identify the item as found on a provider 
which (like with the kde store) might have multiple "servers".


- Dan Leinir Turthra


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


On Oct. 31, 2016, 5:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129298/
> ---
> 
> (Updated Oct. 31, 2016, 5:09 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, Dan Leinir Turthra Jensen, and 
> Marco Martin.
> 
> 
> Repository: kpackage
> 
> 
> Description
> ---
> 
> Makes it possible to specify components to be installed together with a 
> KPackage. They will be specified by a url, we'll have handlers for any kind, 
> making reasonably extensible and doesn't tie us to a technology.
> 
> In this repository I created two Proof of Concept of such handlers, one for 
> the appstream urls and one for KNS: kde:scratch/apol/kpackage-install-helpers
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 395b16e 
>   autotests/data/testpackagesdep/contents/ui/main.qml PRE-CREATION 
>   autotests/data/testpackagesdep/metadata.json PRE-CREATION 
>   autotests/data/testpackagesdep/testpackagesdep.testappdataxml PRE-CREATION 
>   src/kpackage/config-package.h.cmake 61f2f0c 
>   src/kpackage/private/packagejobthread.cpp 0a0cc01 
>   src/kpackage/private/packagejobthread_p.h 1babf0b 
> 
> Diff: https://git.reviewboard.kde.org/r/129298/diff/
> 
> 
> Testing
> ---
> 
> None. just builds. It's a proof of concept, not even the test I added was 
> tested, it was just to display what it could look like.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>



Re: Review Request 129302: Fix include dir in pri file

2016-11-01 Thread David Rosca

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

(Updated Nov. 1, 2016, 8:24 a.m.)


Review request for KDE Frameworks and Jan Grulich.


Repository: networkmanager-qt


Description
---

Currently the pri file has Qt.NetworkManagerQt.includes = 
/usr/include/NetworkManagerQt.
This changes fixes it and makes it /usr/include/KF5/NetworkManagerQt


Diffs
-

  src/CMakeLists.txt 3249154 

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


Testing (updated)
---

Correct include paths when used from qmake.
It still cannot be used from qmake without additional changes because 
`generictypes.h` includes `nm-version.h` from libnm which is not in include 
paths.


Thanks,

David Rosca



Review Request 129302: Fix include dir in pri file

2016-11-01 Thread David Rosca

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

Review request for KDE Frameworks and Jan Grulich.


Repository: networkmanager-qt


Description
---

Currently the pri file has Qt.NetworkManagerQt.includes = 
/usr/include/NetworkManagerQt.
This changes fixes it and makes it /usr/include/KF5/NetworkManagerQt


Diffs
-

  src/CMakeLists.txt 3249154 

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


Testing
---

Correct include paths when used from qmake.


Thanks,

David Rosca



Review Request 129303: Fix include dir in pri file

2016-11-01 Thread David Rosca

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

Review request for KDE Frameworks and Jan Grulich.


Repository: modemmanager-qt


Description
---

Currently the pri file has Qt.ModemManagerQt.includes = 
/usr/include/ModemManagerQt.
This changes fixes it and makes it /usr/include/KF5/ModemManagerQt


Diffs
-

  src/CMakeLists.txt 29a7a63 

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


Testing
---

Correct include paths when used from qmake.


Thanks,

David Rosca