Re: Review Request 127896: make dbus optional on osx: kauth

2016-05-11 Thread René J . V . Bertin 

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



Forgive me if I'd like to be certain that this isn't disabling DBus altogether 
on OS X!


CMakeLists.txt (lines 14 - 18)


Am I right that on OS X use of DBus is going to depend on whether or not Qt 
provides the QtDBus component? If so, shouldn't this be done on MS Windows too?

If that's *not* the right interpretation:
PLEASE introduce proper option variables for this kind of thing, for 
instance in ECM. Consider the overal picture; is this only about DBus or is 
this ultimately about building standalone app bundles? In other words, would it 
be possible to name that option variable appropriately to allow it to act as a 
switch for other, related build options?

This is all the more appropriate (and *polite*) if this is a convenience 
change for HomeBrew - why would such a change oblige other 
packaging/distribution systems to add and maintain unknown amounts of 
additional patches to undo it?!



autotests/BackendsManager.cpp (lines 26 - 30)


Again, double-checking: Is QT_NO_DBUS really going to be defined if the 
cmake system didn't do a `find_package(Qt5 ... DBus)`? IOW, is this change not 
going to introduce a build failure on systems where Qt does provide a DBus 
interface?



autotests/BackendsManager.cpp (lines 56 - 60)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



autotests/HelperTest.cpp (lines 27 - 31)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



autotests/HelperTest.cpp (lines 106 - 110)


Ditto, no risk of a build failure on systems where Qt does provide a DBus 
interface?



src/CMakeLists.txt 


Was this a redundant statement?


- René J.V. Bertin


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Review Request 127896: make dbus optional on osx: kauth

2016-05-11 Thread René J . V . Bertin 

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



Erm, it seems I did something I shouldn't have done, *inadvertently* ...

That "a bit harsh" statement was mine, and shouldn't have had someone else's 
picture attached to it.

My apologies for that (this cannot be changed/repaired, can it?)

- René J.V. Bertin


On May 12, 2016, 7:16 a.m., Nick Shaforostoff wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127896/
> ---
> 
> (Updated May 12, 2016, 7:16 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks, David Edmundson, 
> and Martin Gräßlin.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> this is the first patch to make kde frameworks build (and then work) without 
> dbus.
> 
> this will allow homebrew users use precompiled vanilla Qt to build kde apps 
> on osx. as dbus is not a common service in osx world, kde apps on osx should 
> use native means for interprocess communication instead -- this will make 
> them better citizens in osx ecosystem.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 48dc2d9 
>   autotests/BackendsManager.cpp 59675b3 
>   autotests/CMakeLists.txt b53d760 
>   autotests/HelperTest.cpp 8050a06 
>   src/CMakeLists.txt 1b6930d 
>   src/ConfigureChecks.cmake d46761a 
> 
> Diff: https://git.reviewboard.kde.org/r/127896/diff/
> 
> 
> Testing
> ---
> 
> compiles fine on osx, compiles fine on linux, tests on linux still pass.
> 
> 
> Thanks,
> 
> Nick Shaforostoff
> 
>

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

Re: Review Request 127813: Process paths just once

2016-05-11 Thread Matthew Dawson 

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



General +1 from me, just two things:

1) Can you split these two change into two commits?  One being the part about 
not removing file: twice, the second about removing duplicate homes?  If not, 
np.
2) Do you have any benchmark numbers about this?  Just looking at comparisions, 
it will take three comparisions each time to check the list, then at least one 
more comparision assuming they are all the same.  Versus only three 
comparisions on the old code.  And if any path does clean the string, the other 
comparisions are skipped in the old version.  That being said, if benchmarks 
suggest your version is faster in wall time (not callgrind counts), I have no 
problem taking it.

- Matthew Dawson


On May 4, 2016, 9:02 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127813/
> ---
> 
> (Updated May 4, 2016, 9:02 p.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Just process every home path once, as the 3 alternatives will probably just 
> be the same.
> Don't drop the file: prefix twice in every run.
> 
> 
> Diffs
> -
> 
>   src/core/kconfiggroup.cpp 39d2441 
> 
> Diff: https://git.reviewboard.kde.org/r/127813/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, apps work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 127896: make dbus optional on osx: kauth

2016-05-11 Thread Nick Shaforostoff 

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

(Updated May 12, 2016, midnight)


Review request for KDE Frameworks, David Edmundson and Martin Gräßlin.


Changes
---

added KAUTH_HELPER_BACKEND_LIBS definition for compiling with 
-DKAUTH_HELPER_BACKEND_NAME=OSX cmake option


Repository: kauth


Description
---

this is the first patch to make kde frameworks build (and then work) without 
dbus.

this will allow homebrew users use precompiled vanilla Qt to build kde apps on 
osx. as dbus is not a common service in osx world, kde apps on osx should use 
native means for interprocess communication instead -- this will make them 
better citizens in osx ecosystem.


Diffs (updated)
-

  CMakeLists.txt 48dc2d9 
  autotests/BackendsManager.cpp 59675b3 
  autotests/CMakeLists.txt b53d760 
  autotests/HelperTest.cpp 8050a06 
  src/CMakeLists.txt 1b6930d 
  src/ConfigureChecks.cmake d46761a 

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


Testing
---

compiles fine on osx, compiles fine on linux, tests on linux still pass.


Thanks,

Nick Shaforostoff

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

Re: Review Request 127850: Let Plasma::Corona load the layout on all cases.

2016-05-11 Thread Aleix Pol Gonzalez 

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

(Updated May 12, 2016, 1:20 a.m.)


Review request for KDE Frameworks, Plasma and David Rosca.


Changes
---

Looked into the issue again, we shouldn't be notifying the startup completed 
only because the script finished. This re-uses the same code for both cases and 
fixes Plasma 5.5 and 5.6 without touching them.


Bugs: 60777
http://bugs.kde.org/show_bug.cgi?id=60777


Repository: plasma-framework


Description
---

Iteration of: https://git.reviewboard.kde.org/r/127848/

We either load the existing layout or we load a default one.

With this, it could be removed from ShellCorona.


Diffs (updated)
-

  src/plasma/corona.h d8f829a 
  src/plasma/corona.cpp 1784516 

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


Testing
---

Tests pass.
PlasmaShell prints completed once both with and without configuration.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 127813: Process paths just once

2016-05-11 Thread Aleix Pol Gonzalez 

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



ping?

- Aleix Pol Gonzalez


On May 5, 2016, 3:02 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127813/
> ---
> 
> (Updated May 5, 2016, 3:02 a.m.)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Just process every home path once, as the 3 alternatives will probably just 
> be the same.
> Don't drop the file: prefix twice in every run.
> 
> 
> Diffs
> -
> 
>   src/core/kconfiggroup.cpp 39d2441 
> 
> Diff: https://git.reviewboard.kde.org/r/127813/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, apps work.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 127817: Don't make KIconThemes depend on Oxygen

2016-05-11 Thread Aleix Pol Gonzalez 


> On May 4, 2016, 11:45 p.m., Albert Astals Cid wrote:
> > +1 would i'd like someone else opinion.

Ping?


- Aleix


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


On May 3, 2016, 1:09 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127817/
> ---
> 
> (Updated May 3, 2016, 1:09 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> We were using oxygen as the default theme, this meant that oxygen was 
> processed by every application. This was fixed in the past by changing this 
> setting to `breeze`, but this only brought new kinds of problems (e.g. review 
> 127232).
> 
> See bug 336739, bug 360664.
> 
> By just using hicolor, we don't make the application fetch `oxygen` for 
> little reason.
> 
> 
> Diffs
> -
> 
>   src/kiconloader.cpp 6ce7ecdc0b9c38647994c750e77980fbf9b6fdd4 
>   src/kicontheme.cpp f8c0a37754848a74e42bba5866aa4ce0998bce7c 
> 
> Diff: https://git.reviewboard.kde.org/r/127817/diff/
> 
> 
> Testing
> ---
> 
> On dolphin:
> This has an improvement on callgrind 1556M/1185M instructions (30% 
> improvement).
> KIconLoader allocations correspond to 3.8% instead of 4.8%, going down by: 
> 535K/509K
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 127887: Improve usage of Qt APIs

2016-05-11 Thread Aleix Pol Gonzalez 

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

(Updated May 12, 2016, 1:01 a.m.)


Review request for KDE Frameworks and Jeremy Whiting.


Changes
---

Address most Kai issues.


Repository: knewstuff


Description
---

Mostly clazy fixes, few cleanups


Diffs (updated)
-

  src/core/installation.cpp 1887d0f 
  src/kmoretools/kmoretools.h 32da22c 
  src/kmoretools/kmoretools.cpp 8bd6751 
  src/kmoretools/kmoretoolsconfigdialog_p.cpp 466b887 
  src/kmoretools/kmoretoolsmenufactory.cpp aad3f00 
  src/kmoretools/kmoretoolspresets.cpp 679e849 
  src/staticxml/staticxmlprovider.cpp 541bf57 
  src/ui/itemsviewdelegate.cpp 7001be2 
  tests/kmoretools/kmoretoolstest_interactive.cpp b1cbdea 

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


Testing
---

Builds, tests pass.


Thanks,

Aleix Pol Gonzalez

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

Review Request 127896: make dbus optional on osx: kauth

2016-05-11 Thread Nick Shaforostoff 

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

Review request for KDE Frameworks, David Edmundson and Martin Gräßlin.


Repository: kauth


Description
---

this is the first patch to make kde frameworks build (and then work) without 
dbus.

this will allow homebrew users use precompiled vanilla Qt to build kde apps on 
osx. as dbus is not a common service in osx world, kde apps on osx should use 
native means for interprocess communication instead -- this will make them 
better citizens in osx ecosystem.


Diffs
-

  CMakeLists.txt 05e2874 
  autotests/BackendsManager.cpp 59675b3 
  autotests/CMakeLists.txt b53d760 
  autotests/HelperTest.cpp 8050a06 
  src/CMakeLists.txt 1b6930d 

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


Testing
---

compiles fine on osx, compiles fine on linux, tests on linux still pass.


Thanks,

Nick Shaforostoff

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

Re: Can we have a headersclean check for frameworks?

2016-05-11 Thread Aleix Pol 
On Wed, May 11, 2016 at 10:51 PM, Stephen Kelly  wrote:
> Hi,
>
> Qt has a headersclean utility which runs each header through the compiler on
> its own. That verifies that it doesn't cause certain warnings, can compile
> in the presence of certain Qt defines, and includes or forward declares
> everything it should.
>
> We don't have such a thing in KF5, but as shown by
>
>  https://quickgit.kde.org/?p=kconfigwidgets.git=commitdiff=2900814b
>
> we would benefit from it.
>
> Does anyone want to try to implement it (or borrow the Qt implementation)
> and integrate it?
>
> We can probably add it to ECM and run it as part of the build of frameworks.

That could make sense, maybe as a clazy check?

Can you point us to Qt's so we know what we're talking about?

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

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

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/36/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:47:51 +
Build duration: 2 min 25 sec

CHANGE SET
No changes


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 75/84 (89%)CLASSES 75/84 (89%)LINE 5459/7979 
(68%)CONDITIONAL 2952/6140 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1440/1528 
(94%)CONDITIONAL 883/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 755/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2042/2796 
(73%)CONDITIONAL 1229/2056 (60%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/36/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:47:51 +
Build duration: 2 min 25 sec

CHANGE SET
No changes


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 75/84 (89%)CLASSES 75/84 (89%)LINE 5459/7979 
(68%)CONDITIONAL 2952/6140 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1440/1528 
(94%)CONDITIONAL 883/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 755/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2042/2796 
(73%)CONDITIONAL 1229/2056 (60%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kdelibs4support master stable-kf5-qt5 » Linux,gcc - Build # 29 - Still Unstable!

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/29/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:42:14 +
Build duration: 12 min

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 38 test(s), Skipped: 0 test(s), Total: 
39 test(s)Failed: TestSuite.globalcleanuptest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 160/268 (60%)CLASSES 160/268 (60%)LINE 21694/42775 
(51%)CONDITIONAL 14666/36447 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11519/11768 
(98%)CONDITIONAL 8481/16820 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9221/16863 
(55%)CONDITIONAL 5722/11783 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9815 
(10%)CONDITIONAL 460/5673 (8%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2396 (1%)CONDITIONAL 
3/1226 (0%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/14 
(0%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1708 (0%)CONDITIONAL 0/836 
(0%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/199 (0%)CONDITIONAL 0/95 
(0%)___
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 # 35 - Fixed!

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/35/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:46:05 +
Build duration: 2 min 5 sec

CHANGE SET
No changes


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 75/84 (89%)CLASSES 75/84 (89%)LINE 5455/7979 
(68%)CONDITIONAL 2961/6140 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1442/1528 
(94%)CONDITIONAL 889/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 763/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2036/2796 
(73%)CONDITIONAL 1224/2056 (60%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
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 # 35 - Fixed!

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/35/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:46:05 +
Build duration: 2 min 5 sec

CHANGE SET
No changes


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 75/84 (89%)CLASSES 75/84 (89%)LINE 5455/7979 
(68%)CONDITIONAL 2961/6140 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1442/1528 
(94%)CONDITIONAL 889/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1761/3042 
(58%)CONDITIONAL 763/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2036/2796 
(73%)CONDITIONAL 1224/2056 (60%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kpty master stable-kf5-qt5 » Linux,gcc - Build # 32 - Unstable!

2016-05-11 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kpty%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/32/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Wed, 11 May 2016 20:46:05 +
Build duration: 1 min 1 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 432/557 
(78%)CONDITIONAL 128/243 (53%)

By packages
  
autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 111/111 
(100%)CONDITIONAL 41/72 (57%)
src
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 321/446 (72%)CONDITIONAL 
87/171 (51%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127895: Remove unused dependencies and translation handling.

2016-05-11 Thread Michael Palimaka 

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

(Updated May 11, 2016, 6:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit b50958516e6cf05f04ff92437e04228950a0ddec by Michael 
Palimaka to branch master.


Repository: frameworkintegration


Description
---

These are no longer used since 5ddb0b262dc409071f556dbd3f94799136b60909.


Diffs
-

  CMakeLists.txt 753177a101e965a86f48915ea0ab723f16c46d1a 
  autotests/CMakeLists.txt 8874f61daca2a5fdeb69faae80183802b0e63969 
  src/Messages.sh 5ee7c10ef734e30d70491acd6e5ecc52d3c41186 

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


Testing
---

Inspected source, builds, tests pass.


Thanks,

Michael Palimaka

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

Re: Review Request 127895: Remove unused dependencies and translation handling.

2016-05-11 Thread Aleix Pol Gonzalez 

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


Ship it!




Ship It!

- Aleix Pol Gonzalez


On May 11, 2016, 8:49 p.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127895/
> ---
> 
> (Updated May 11, 2016, 8:49 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> These are no longer used since 5ddb0b262dc409071f556dbd3f94799136b60909.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 753177a101e965a86f48915ea0ab723f16c46d1a 
>   autotests/CMakeLists.txt 8874f61daca2a5fdeb69faae80183802b0e63969 
>   src/Messages.sh 5ee7c10ef734e30d70491acd6e5ecc52d3c41186 
> 
> Diff: https://git.reviewboard.kde.org/r/127895/diff/
> 
> 
> Testing
> ---
> 
> Inspected source, builds, tests pass.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

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

Re: Review Request 127822: address the potential name/case clash of the Attica/Attica and Attica/attica header dirs

2016-05-11 Thread René J . V . Bertin 

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




src/CMakeLists.txt (lines 160 - 163)


This change is problematic, and apparently needs to be platform-specific 
(if done here):

- on OS X it works as intended, despite the fact one should use `INCLUDES 
DESTINATION` instead of `INCLUDES` alone
- on Linux, it adds an additional path to the search path 
($PREFIX/INCLUDES), which raises an error if inexistent. The intended behaviour 
is obtained by removing the `INCLUDES` keyword.

This is probably because of this extract from `ECM/KDEInstallDirs.cmake`:

```
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  RUNTIME DESTINATION 
"${CMAKE_INSTALL_BINDIR}"
  LIBRARY DESTINATION 
"${CMAKE_INSTALL_LIBDIR}"
  ARCHIVE DESTINATION 
"${CMAKE_INSTALL_LIBDIR}" COMPONENT Devel
  INCLUDES DESTINATION 
"${CMAKE_INSTALL_INCLUDEDIR_KF5}"
)

# on the Mac support an extra install directory for application bundles
if(APPLE)
set(KDE_INSTALL_TARGETS_DEFAULT_ARGS  
${KDE_INSTALL_TARGETS_DEFAULT_ARGS}
  BUNDLE DESTINATION 
"${BUNDLE_INSTALL_DIR}" )
set(KF5_INSTALL_TARGETS_DEFAULT_ARGS  
${KF5_INSTALL_TARGETS_DEFAULT_ARGS}
  BUNDLE DESTINATION 
"${BUNDLE_INSTALL_DIR}" )
endif()
```

IOW, it *may* be that OS X ("APPLE") requires a dedicated change to 
`src/CMakelists.txt`, or else there'd be special cases for OS X, MSWin and the 
default (anything that always has a case-sensitive platform).

I don't see an alternative, except possibly at the level of 
`CMAKE_INSTALL_INCLUDEDIR_KF5`, but I cannot find where that variable is 
defined.


- René J.V. Bertin


On May 3, 2016, 3:29 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127822/
> ---
> 
> (Updated May 3, 2016, 3:29 p.m.)
> 
> 
> Review request for Build System, KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: attica
> 
> 
> Description
> ---
> 
> Attica has long adhered to an install layout that relies on case to 
> distinguish directories. For instance:
> 
> ```
> include/KF5/Attica/Attica/AccountBalance
> include/KF5/Attica/attica/accountbalance.h
> ```
> 
> Depending on the order in which those files are installed on a FS like HFS+ 
> (in case-insensitive-but-case-preserving mode), you will end up with 
> `Attica/Attica` or `Attica/attica` directories; the directory name case 
> changes to reflect the last write.
> 
> Basic calls like fopen() will succeed regardless of case because the 
> filesystem ignores case in such operations. However, compilers (clang at 
> least) do not simply try to open a requested include file in each element of 
> the header directory search path. They use a search algorithm to locate the 
> file first ... and that algorithm takes case into account. So `#include 
> ` will fail if the file is installed as 
> `include/KF5/Attica/attica/AccountBalance`.
> 
> This issue is delicate to fix: the most trivial solution (installing all 
> headers in a single directory) would still require changes in all dependent 
> code.
> 
> I'm just proposing a fix that builds on the assumption that the 
> `` style is part of C++ semantics (as opposed to a more 
> traditional ``). The fix installs headers in 
> `KF5/Attica/attica` and `KF5/Attica/c++/Attica`, and adds the additional 
> `Attica/c++` component to the header search path. It also corrects the 
> pkg-config file.
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt 984f7ff 
>   src/cmake/libKF5Attica.pc.cmake 75387fa 
> 
> Diff: https://git.reviewboard.kde.org/r/127822/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 with FWs. 5.20.0 installed under /opt/local . As a test-case I 
> rebuilt `knewstuff` after changing its `src/uploaddialog_p.h` to include 
> `` instead of `` and `` 
> instead of ``.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 127878: use the "selected" icon mode in file open dialog sidebar

2016-05-11 Thread David Edmundson 

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




src/widgets/kfileitemdelegate.cpp (line 1220)


QCommonStyle when rendering CE_ItemViewItem checks for disabled first

QIcon::Mode mode = QIcon::Normal;
if (!(vopt->state & QStyle::State_Enabled))
mode = QIcon::Disabled;
else if (vopt->state & QStyle::State_Selected)
mode = QIcon::Selected;

qcommonstyle:2167

it's probably best to emulate that

also why do you have the && active?

That means it'd need to be both selected and have mouse over at the same 
time in order to change icon?


- David Edmundson


On May 10, 2016, 11:57 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127878/
> ---
> 
> (Updated May 10, 2016, 11:57 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> since now kiconloader can color the icons in the sidebar, by using the 
> "selected" icon mode, when the breeze icon theme is used the icon of the 
> current sidebar item will be of the same color of selected text (white-ish by 
> default), is more in line with breeze style and the monochrome icons become 
> more readable
> 
> 
> Diffs
> -
> 
>   src/filewidgets/kfileplacesview.cpp 03074e0 
>   src/widgets/kfileitemdelegate.cpp 1516b9e 
> 
> Diff: https://git.reviewboard.kde.org/r/127878/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> menu3.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/09/41f52d86-6fc5-4799-bd9e-18d17dc5a65a__menu3.png
> 
> 
> 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 127888: use selected icon effect for current KPageView page

2016-05-11 Thread David Edmundson 

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


Ship it!




- David Edmundson


On May 10, 2016, 3:12 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127888/
> ---
> 
> (Updated May 10, 2016, 3:12 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> in case icons of KPageView are monochromatic, recolor them of the 
> highlightedtext color as the other patches on the breeze style and kio
> 
> 
> Diffs
> -
> 
>   src/kpageview_p.cpp 650a7b3 
> 
> Diff: https://git.reviewboard.kde.org/r/127888/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel3.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/10/72741885-021d-448f-892e-1590b95ef8c0__dadel3.png
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: dbus-less frameworks on osx

2016-05-11 Thread Ben Cooksley 
On Wed, May 11, 2016 at 6:39 PM, Kevin Funk  wrote:
> On Wednesday, May 11, 2016 7:38:58 AM CEST Martin Graesslin wrote:
>> On Wednesday, May 11, 2016 4:00:45 AM CEST Nick Shaforostoff wrote:
>> > hi all! I'm investigating possibility of getting some kde apps to build on
>> > osx with vanilla Qt without dbus.
>> >
>> > would you accept patches that make that possible?
>
> +1

I'm also in favour of this, mainly as D-Bus doesn't really belong on
those platforms, and if I recall correctly people have had issues with
false positives from Windows antimalware programs flagging D-Bus code
in the past.

>
> I looked into that a while ago, but quickly discarded the idea, because QtDBus
> was just so broadly used in KF5. Just checked again, and it appeared to me
> it's indeed doable, when skipping a few frameworks (see below).
>
> FYI: Just scan frameworks for "include.+QDBus", you'll hits in the following
> repositories:
>
> bluez-qt
> kactivities
> kactivities-stats
> kauth
> kbookmarks
> kcmutils
> kconfigwidgets
> kdbusaddons
> kded
> kdelibs4support
> kdnssd
> kglobalaccel
> khtml
> kiconthemes
> kinit
> kio
> kmediaplayer
> knotifications
> knotifyconfig
> kservice
> kwallet
> kxmlgui
> modemmanager-qt
> networkmanager-qt
> solid
>
> bluez-qt, modemmanager-qt, networkmanager-qt are heavy users of QtDBus, but
> are normally not needed for the majority of our KDE apps. I'd leave them as-
> is.

They're also rather pointless outside of Linux (Windows and Mac have
their own interfaces/services for that stuff anyway)

>
> Solid is another heavy user, but only in the Linux-specific backends iiuc, so
> not a problem.
>
> You'll have some fun getting kio to built without DBus, tons of uses of QtDBus
> there.
>
> The other frameworks only use QtDBus in a few places, definitely possible to
> make them optional. A few of them are not needed on OS X/Windows anyway -- say
> kded, kactivities, etc. -- not sure if they need to be dbus-less.
>
> IOW: Go ahead! :)
>
> Cheers,
> Kevin

Regards,
Ben

>
>> >
>> > for example, i have just built kauth without dbus and i can prepare a
>> > review request with a (nice) patch for this
>>
>> Having suggested this in the past: I think that's a good idea and I fully
>> support it.
>>
>> Cheers,
>> Martin
>
>
> --
> Kevin Funk | kf...@kde.org | http://kfunk.org
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KFilePlacesModelTest

2016-05-11 Thread David Faure 
On Saturday 07 May 2016 19:50:36 Michael Pyne wrote:
> On Sat, May 7, 2016 14:33:53 David Faure wrote:
> > The thing I wonder is... does it really make sense to have a model with
> > random ordering? Isn't it a problem for users if their visible list of
> > places is different between every run? Or am I missing something and the
> > different order in the test isn't actually user visible?
> 
> Is it trying to test that the entries are present in a *specific* order, or 
> simply that the entries will be maintained in a constant order between 
> serialization/deserialization? If it's the latter then we could instead use 
> whatever the existing order is in one call as the expected order for the 
> second call.
> 
> Also, if we're just trying to show that a specific set of entries would be 
> present, couldn't we sort the expected and the actual lists before doing the 
> comparison, to make it independent of order? In other words we could break 
> the 
> test into two: 1) ensure order is properly saved and loaded, and 2) ensure 
> right items are present independent of their order.

For the record, this is now fixed in solid and kio.
The random ordering came from QList->QSet->QList, which I managed
to simplify to avoid the QSet step.

Giuseppe: it wasn't about two sets, but about a single intermediary qset,
and then checking the final QList with a fixed "expected" list. Since everything
is fixed upfront (the initial QList comes from parsing a test file), it looked
like this could be made reliable - but somehow on two different machines
with the exact same code (AFAICS), I was getting a different order.
Oh well, doesn't matter anymore :-)

Thanks for the input everyone.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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