Re: Review Request 127795: [DataEngine] Invalidate DataEngine on unknown plugin + detailed test

[Anthony Fieroni]

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

(Updated Май 3, 2016, 7:10 преди обяд)


Review request for KDE Frameworks and Marco Martin.


Changes
---

Add test case
Invalidate DataEngine if KPluingInfo does not know the plugin
Don't emit sourceRemoved twice, it was done before destruction


Summary (updated)
-

[DataEngine] Invalidate DataEngine on unknown plugin + detailed test


Repository: plasma-framework


Description
---

^^


Diffs (updated)
-

  autotests/pluginloadertest.h 61fc963 
  autotests/pluginloadertest.cpp 4f96780 
  src/plasma/dataengine.cpp f942926 

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


Testing
---

Test pass.


Thanks,

Anthony Fieroni

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

Re: Review Request 127655: Fix KAboutData::applicationData() to init from current Q*Application metadata

[Friedrich W. H. Kossebau]

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

(Updated May 3, 2016, 12:39 a.m.)


Review request for KDE Frameworks, Alex Richardson and Michael Pyne.


Changes
---

Drop all-the-time-syncing idea and turn into fix for init +  some warnings


Summary (updated)
-

Fix KAboutData::applicationData() to init from current Q*Application metadata


Repository: kcoreaddons


Description (updated)
---

There is code in e.g. KXMLGUI which relies on KAboutData::applicationData(), 
without requiring the user to use KAboutData::setApplicationData(). So better 
be complete when initializing the data from the Q*Application metadata.

Also
- warn if there is no Q*App instance yet to set properties in 
KAboutData::setApplicationData
- check and warn if KAboutData::applicationData is out-of-sync with qapp data
- remove bogus check for empty display name, as the method defaults to 
componentname
- unit tests 
KAboutDataTest::testSetOfQApplicationData/testPickupOfQApplicationData


Diffs (updated)
-

  autotests/kaboutdatatest.cpp f31e7f3 
  src/lib/kaboutdata.h 97c0f2b 
  src/lib/kaboutdata.cpp ceb0c06 

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


Testing
---

Added autotests pass.


Thanks,

Friedrich W. H. Kossebau

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

Re: Review Request 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Friedrich W. H. Kossebau]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if 
> > they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically 
> > setting it up makes sense, and QCoreApplication is a good source. But I 
> > would rather flag property conflicts than to break ties when developer 
> > selects two different values for same property, as that's change in 
> > behavior might break other parts of code that rely on KAboutData not 
> > changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?
> 
> Albert Astals Cid wrote:
> > I think I disagree with the idea of overwriting KAboutData properties 
> if they are already set by the user. Alex, any thoughts?
> 
> I agree with Michael, it seems strage it overwriting what you may have 
> set in setAboutData.
> 
> Friedrich W. H. Kossebau wrote:
> Hm. Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()? And similar for the other shared/mapped 
> application metadata properties? Why would I rather expect the original 
> property of the KAboutData value to be kept, than it being updated to its 
> counterpart in the Q*Application metadata, if changed by the Qt-API 
> afterwards?
> Surprised to see you expecting things to be different :)
> 
> Not that I expect it to happen a lot in real world code that the metadata 
> of applications is set/reset by independent code snippets (and thus a mixture 
> of KAboutData-using and Q*Application::setX-using), where random orders of 
> writing and reading the data can happen. But if it happens, should not both 
> Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and 
> both be acting on the same effective properties when it comes to metadata 
> about the application instance, where it makes sense and is defined as such?
> 
> Or, why should KAboutData::setApplicationData be allowed to overrule any 
> already set QApplication metadata (which makes sense to everyone), but not 
> the other way around? :) Why should KAboutData::setApplicationData be 
> write-through, but KAboutData::applicationData not be read-through?
> 
> Like it is now, if I would want to use metadata of the application, I 
> cannot rely on KAboutData::applicationData alone, I also have to separately 
> read things by Q*Application::x, to be sure to really have the values also 
> used by other Qt-only parts of the code. Which renders the duplicates of 
> those Q*Application properties in KAboutData useless, no?
> I would expect more code to be broken if it relies only on 
> KAboutData::applicationData() than code which expects any properties to keep 
> their values, even if getting out-of-sync with the Qt application metadata.
> 
> For the bug which motivated me to write this patch, agreeing on 
> initialising at least the global KAboutData instance to current Q*Application 
> data should be fine, so will change the patch to that now. But well, I think 
> this initial patch should be the way to go and yield less surprising 
> behaviour :)
> 
> Albert Astals Cid wrote:
> > Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()?
> 
> To me, no.
> 
> > Why would I rather expect the original property of the KAboutData value 
> to be kept, than it being updated to its counterpart in the Q*Application 
> metadata, if changed by the Qt-API afterwards?
> 
> Why should they match? You're basically arguing for
> a->setX("BOO")
> b->setY("LALA")
> a->x() => should return "LALA"
> 
> That's the most strange API ever.
> 
> > Or, why should KAboutData::setApplicationData be allowed to overrule 
> any already set QApplication metadata (which makes sense to everyone), but 
> not the other way around?
> 
> I don't think it makes sense either. If we're to fix this assymetry, I 
> would much rather prefer a patch that doesn't overwrite QCoreApplication 
> version, name and organization domain if they have already been set.
> 
> I am not the maintainer of this framework though, so wait for a more 
> qualified opinion.

Well, I am arguing for what KAboutData::applicationData is about IMHO and 
expected by most code I have seen, which is:
a representation of the metadata of the Q*Application instance (which I 
consider a result of quick porting to Qt5 under the premise of API 
compatibility for all the existing codebase, not something which is well 
designed given the Qt5 API, in case you doubt). Do not agree with your code 
abstraction, but well, it's not straight object-oriented code in any case.

So what is the intend of any code which uses the setter/getter for that global 
KAboutData 

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

[Aleix Pol Gonzalez]

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

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

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 49 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/49/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:43:22 +
Build duration: 15 min

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

Jenkins-kde-ci: kxmlrpcclient master kf5-qt5 » Linux,gcc - Build # 41 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kxmlrpcclient%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/41/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:43:22 +
Build duration: 39 sec

CHANGE SET
No changes
___
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

[Aleix Pol Gonzalez]

> On May 2, 2016, 10:21 p.m., Albert Astals Cid wrote:
> > src/core/kconfiggroup.cpp, line 442
> > 
> >
> > Are we sure we want this to be static?

I'm not sure, my impression is that it's better if we only fetch this once, but 
I can easily be convinced otherwise.


- Aleix


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


On May 2, 2016, 6:32 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 2, 2016, 6:32 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

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 44 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/44/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:30:56 +
Build duration: 7 min 48 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 3 test(s), Passed: 47 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiocore-threadtestFailed: 
TestSuite.kiofilewidgets-kfileplacesmodeltestFailed: 
TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 259/337 (77%)CLASSES 259/337 (77%)LINE 26388/50579 
(52%)CONDITIONAL 14487/37309 (39%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 7236/7811 
(93%)CONDITIONAL 3815/8092 (47%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 95/117 (81%)CLASSES 95/117 (81%)LINE 7664/14036 
(55%)CONDITIONAL 4149/8905 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE /7564 
(29%)CONDITIONAL 889/4399 (20%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1762/3781 
(47%)CONDITIONAL 1258/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 685/762 (90%)CONDITIONAL 
433/912 (47%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 359/385 (93%)CONDITIONAL 
102/138 (74%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 31/34 (91%)CONDITIONAL 
42/54 (78%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 220/249 (88%)CONDITIONAL 
298/378 (79%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2668/10599 
(25%)CONDITIONAL 1308/6780 (19%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/23/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:20:54 +
Build duration: 4 min 49 sec

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.kurltest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21547/42796 
(50%)CONDITIONAL 14495/36438 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11392/11775 
(97%)CONDITIONAL 8368/16798 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9200/16860 
(55%)CONDITIONAL 5664/11776 (48%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9832 
(10%)CONDITIONAL 460/5693 (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: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 48 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/48/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:24:15 +
Build duration: 1 min 51 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.frameworkintegration-kfiledialogqml_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 19/19 (100%)CLASSES 19/19 (100%)LINE 1135/1717 
(66%)CONDITIONAL 442/1085 (41%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 387/395 (98%)CONDITIONAL 
199/375 (53%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 701/1144 
(61%)CONDITIONAL 214/548 (39%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: khtml master stable-kf5-qt5 » Linux,gcc - Build # 20 - Still Failing!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/khtml%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/20/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:45:29 +
Build duration: 16 min

CHANGE SET
No changes
___
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 # 20 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/20/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:48:52 +
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 21686/42783 
(51%)CONDITIONAL 14652/36438 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11514/11763 
(98%)CONDITIONAL 8471/16798 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9218/16860 
(55%)CONDITIONAL 5718/11776 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9831 
(10%)CONDITIONAL 460/5693 (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: kdelibs4support master kf5-qt5 » Linux,gcc - Build # 22 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 22:02:40 +
Build duration: 4 min 47 sec

CHANGE SET
Revision 969e62c9fea27d6fa4da83fd3919603cd7def585 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21547/42796 
(50%)CONDITIONAL 14495/36438 (40%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11392/11775 
(97%)CONDITIONAL 8368/16798 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9200/16860 
(55%)CONDITIONAL 5664/11776 (48%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 939/9832 
(10%)CONDITIONAL 460/5693 (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 kf5-qt5 » Linux,gcc - Build # 28 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/28/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:57:37 +
Build duration: 2 min 24 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5454/7979 
(68%)CONDITIONAL 2948/6140 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1440/1528 
(94%)CONDITIONAL 884/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 1762/3042 
(58%)CONDITIONAL 757/1888 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2036/2796 
(73%)CONDITIONAL 1222/2056 (59%)
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: kio master stable-kf5-qt5 » Linux,gcc - Build # 40 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/40/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:38:05 +
Build duration: 5 min 0 sec

CHANGE SET
Revision c506307ba50babe1d88297a6a5c4b1b1a224de65 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 49 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/338 (77%)CLASSES 260/338 (77%)LINE 26712/50599 
(53%)CONDITIONAL 14848/37333 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7518/7831 
(96%)CONDITIONAL 4161/8116 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 95/117 (81%)CLASSES 95/117 (81%)LINE 7661/14036 
(55%)CONDITIONAL 4141/8905 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2267/7564 
(30%)CONDITIONAL 914/4399 (21%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1754/3781 
(46%)CONDITIONAL 1249/3434 (36%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 685/762 (90%)CONDITIONAL 
433/912 (47%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 359/385 (93%)CONDITIONAL 
102/138 (74%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 387/594 (65%)CONDITIONAL 
289/580 (50%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 31/34 (91%)CONDITIONAL 
42/54 (78%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 220/249 (88%)CONDITIONAL 
298/378 (79%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2666/10599 
(25%)CONDITIONAL 1306/6780 (19%)___
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 # 22 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kpty%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:43:42 +
Build duration: 57 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 428/557 
(77%)CONDITIONAL 124/243 (51%)

By packages
  
autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 111/111 
(100%)CONDITIONAL 38/72 (53%)
src
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 317/446 (71%)CONDITIONAL 
86/171 (50%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: sonnet master kf5-qt5 » Linux,gcc - Build # 18 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/sonnet%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/18/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:29:43 +
Build duration: 15 min

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

Jenkins-kde-ci: kwidgetsaddons master kf5-qt5 » Linux,gcc - Build # 17 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/17/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:32:45 +
Build duration: 15 min

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

Jenkins-kde-ci: kwindowsystem master kf5-qt5 » Linux,All,gcc - Build # 18 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/18/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 May 2016 21:35:29 +
Build duration: 1 min 50 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 3 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.kwindowsystem-netrootinfotestwmFailed: 
TestSuite.kwindowsystem-netwininfotestclientFailed: 
TestSuite.kwindowsystem-netwininfotestwm

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/4 (75%)FILES 33/42 (79%)CLASSES 33/42 (79%)LINE 4238/7284 
(58%)CONDITIONAL 2304/5058 (46%)

By packages
  
autotests
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 1255/1302 
(96%)CONDITIONAL 594/1158 (51%)
src
FILES 11/15 (73%)CLASSES 11/15 (73%)LINE 735/1398 
(53%)CONDITIONAL 295/692 (43%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/2 (0%)
src.platforms.xcb
FILES 13/16 (81%)CLASSES 13/16 (81%)LINE 2248/4495 
(50%)CONDITIONAL 1415/3206 (44%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 43 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/43/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:28:51 +
Build duration: 5 min 57 sec

CHANGE SET
Revision c506307ba50babe1d88297a6a5c4b1b1a224de65 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 48 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiofilewidgets-kfileplacesmodeltestFailed: 
TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/338 (77%)CLASSES 260/338 (77%)LINE 26449/50618 
(52%)CONDITIONAL 14523/37357 (39%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7275/7850 
(93%)CONDITIONAL 3842/8140 (47%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 95/117 (81%)CLASSES 95/117 (81%)LINE 7686/14036 
(55%)CONDITIONAL 4155/8905 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE /7564 
(29%)CONDITIONAL 889/4399 (20%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1762/3781 
(47%)CONDITIONAL 1258/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 685/762 (90%)CONDITIONAL 
433/912 (47%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 359/385 (93%)CONDITIONAL 
102/138 (74%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 31/34 (91%)CONDITIONAL 
42/54 (78%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 220/249 (88%)CONDITIONAL 
298/378 (79%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2668/10599 
(25%)CONDITIONAL 1309/6780 (19%)___
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 # 19 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/19/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:15:33 +
Build duration: 6 min 41 sec

CHANGE SET
Revision 969e62c9fea27d6fa4da83fd3919603cd7def585 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


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 21686/42783 
(51%)CONDITIONAL 14652/36438 (40%)

By packages
  
autotests
FILES 63/63 (100%)CLASSES 63/63 (100%)LINE 11514/11763 
(98%)CONDITIONAL 8471/16798 (50%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9218/16860 
(55%)CONDITIONAL 5718/11776 (49%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 938/9831 
(10%)CONDITIONAL 460/5693 (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: khtml master stable-kf5-qt5 » Linux,gcc - Build # 19 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/khtml%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/19/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:15:33 +
Build duration: 3 min 52 sec

CHANGE SET
Revision e811b7ec815e1c0d19e2456ff0ab4593b6ca1239 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt
___
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 # 21 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kpty%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/21/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:17:15 +
Build duration: 1 min 4 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 434/557 
(78%)CONDITIONAL 128/243 (53%)

By packages
  
autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 111/111 
(100%)CONDITIONAL 39/72 (54%)
src
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 323/446 (72%)CONDITIONAL 
89/171 (52%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,All,gcc - Build # 18 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/18/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 May 2016 21:13:25 +
Build duration: 2 min 10 sec

CHANGE SET
Revision 4ce4f52081f490aa62dceee771974370af642154 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


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 3/4 (75%)FILES 40/46 (87%)CLASSES 40/46 (87%)LINE 6608/8859 
(75%)CONDITIONAL 3651/6779 (54%)

By packages
  
autotests
FILES 13/13 (100%)CLASSES 13/13 (100%)LINE 2814/2875 
(98%)CONDITIONAL 1508/2879 (52%)
src
FILES 13/15 (87%)CLASSES 13/15 (87%)LINE 748/1400 
(53%)CONDITIONAL 307/692 (44%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/2 (0%)
src.platforms.xcb
FILES 14/16 (88%)CLASSES 14/16 (88%)LINE 3046/4495 
(68%)CONDITIONAL 1836/3206 (57%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,All,gcc - Build # 18 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/18/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 May 2016 21:13:25 +
Build duration: 2 min 10 sec

CHANGE SET
Revision 4ce4f52081f490aa62dceee771974370af642154 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


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 3/4 (75%)FILES 40/46 (87%)CLASSES 40/46 (87%)LINE 6608/8859 
(75%)CONDITIONAL 3651/6779 (54%)

By packages
  
autotests
FILES 13/13 (100%)CLASSES 13/13 (100%)LINE 2814/2875 
(98%)CONDITIONAL 1508/2879 (52%)
src
FILES 13/15 (87%)CLASSES 13/15 (87%)LINE 748/1400 
(53%)CONDITIONAL 307/692 (44%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/2 (0%)
src.platforms.xcb
FILES 14/16 (88%)CLASSES 14/16 (88%)LINE 3046/4495 
(68%)CONDITIONAL 1836/3206 (57%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 47 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/47/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:10:34 +
Build duration: 1 min 32 sec

CHANGE SET
Revision 07548ac1fe7a7fb31a941473911e982fb623c07d by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.frameworkintegration-kfiledialogqml_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 19/19 (100%)CLASSES 19/19 (100%)LINE 1140/1717 
(66%)CONDITIONAL 451/1085 (42%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 387/395 (98%)CONDITIONAL 
199/375 (53%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 706/1144 
(62%)CONDITIONAL 223/548 (41%)___
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 # 20 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kpty%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/20/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 21:08:34 +
Build duration: 55 sec

CHANGE SET
Revision ca9620c3987a429ea2ae032949d04298a3f395e4 by scripty: (Upgrade KF5 
version to 5.22.0.)
  change: edit CMakeLists.txt


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

Jenkins-kde-ci: kwindowsystem master stable-kf5-qt5 » Linux,All,gcc - Build # 17 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kwindowsystem%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/17/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Mon, 02 May 2016 20:59:26 +
Build duration: 2 min 37 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.kwindowsystem-netwininfotestclient

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/4 (75%)FILES 39/45 (87%)CLASSES 39/45 (87%)LINE 5809/8189 
(71%)CONDITIONAL 3211/6046 (53%)

By packages
  
autotests
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 2149/2206 
(97%)CONDITIONAL 1125/2146 (52%)
src
FILES 13/15 (87%)CLASSES 13/15 (87%)LINE 747/1399 
(53%)CONDITIONAL 307/692 (44%)
src.platforms.wayland
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/89 (0%)CONDITIONAL 0/2 (0%)
src.platforms.xcb
FILES 14/16 (88%)CLASSES 14/16 (88%)LINE 2913/4495 
(65%)CONDITIONAL 1779/3206 (55%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Albert Astals Cid]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if 
> > they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically 
> > setting it up makes sense, and QCoreApplication is a good source. But I 
> > would rather flag property conflicts than to break ties when developer 
> > selects two different values for same property, as that's change in 
> > behavior might break other parts of code that rely on KAboutData not 
> > changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?
> 
> Albert Astals Cid wrote:
> > I think I disagree with the idea of overwriting KAboutData properties 
> if they are already set by the user. Alex, any thoughts?
> 
> I agree with Michael, it seems strage it overwriting what you may have 
> set in setAboutData.
> 
> Friedrich W. H. Kossebau wrote:
> Hm. Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()? And similar for the other shared/mapped 
> application metadata properties? Why would I rather expect the original 
> property of the KAboutData value to be kept, than it being updated to its 
> counterpart in the Q*Application metadata, if changed by the Qt-API 
> afterwards?
> Surprised to see you expecting things to be different :)
> 
> Not that I expect it to happen a lot in real world code that the metadata 
> of applications is set/reset by independent code snippets (and thus a mixture 
> of KAboutData-using and Q*Application::setX-using), where random orders of 
> writing and reading the data can happen. But if it happens, should not both 
> Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and 
> both be acting on the same effective properties when it comes to metadata 
> about the application instance, where it makes sense and is defined as such?
> 
> Or, why should KAboutData::setApplicationData be allowed to overrule any 
> already set QApplication metadata (which makes sense to everyone), but not 
> the other way around? :) Why should KAboutData::setApplicationData be 
> write-through, but KAboutData::applicationData not be read-through?
> 
> Like it is now, if I would want to use metadata of the application, I 
> cannot rely on KAboutData::applicationData alone, I also have to separately 
> read things by Q*Application::x, to be sure to really have the values also 
> used by other Qt-only parts of the code. Which renders the duplicates of 
> those Q*Application properties in KAboutData useless, no?
> I would expect more code to be broken if it relies only on 
> KAboutData::applicationData() than code which expects any properties to keep 
> their values, even if getting out-of-sync with the Qt application metadata.
> 
> For the bug which motivated me to write this patch, agreeing on 
> initialising at least the global KAboutData instance to current Q*Application 
> data should be fine, so will change the patch to that now. But well, I think 
> this initial patch should be the way to go and yield less surprising 
> behaviour :)

> Would it not be more strange if one cannot be sure that 
> KAboutData::applicationData().displayName() matches 
> app->applicationDisplayName()?

To me, no.

> Why would I rather expect the original property of the KAboutData value to be 
> kept, than it being updated to its counterpart in the Q*Application metadata, 
> if changed by the Qt-API afterwards?

Why should they match? You're basically arguing for
a->setX("BOO")
b->setY("LALA")
a->x() => should return "LALA"

That's the most strange API ever.

> Or, why should KAboutData::setApplicationData be allowed to overrule any 
> already set QApplication metadata (which makes sense to everyone), but not 
> the other way around?

I don't think it makes sense either. If we're to fix this assymetry, I would 
much rather prefer a patch that doesn't overwrite QCoreApplication version, 
name and organization domain if they have already been set.

I am not the maintainer of this framework though, so wait for a more qualified 
opinion.


- Albert


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


On April 28, 2016, 1:04 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127655/
> ---
> 
> (Updated April 28, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---

Re: Review Request 127655: Fix KAboutData::applicationData() to sync to current Q*Application metadata

[Friedrich W. H. Kossebau]

> On April 29, 2016, 3:15 a.m., Michael Pyne wrote:
> > I think I disagree with the idea of overwriting KAboutData properties if 
> > they are already set by the user. Alex, any thoughts?
> > 
> > In the event the KAboutData doesn't already exist I think automatically 
> > setting it up makes sense, and QCoreApplication is a good source. But I 
> > would rather flag property conflicts than to break ties when developer 
> > selects two different values for same property, as that's change in 
> > behavior might break other parts of code that rely on KAboutData not 
> > changing values.
> > 
> > Would this partial solution be OK for the problem you're running into?
> 
> Albert Astals Cid wrote:
> > I think I disagree with the idea of overwriting KAboutData properties 
> if they are already set by the user. Alex, any thoughts?
> 
> I agree with Michael, it seems strage it overwriting what you may have 
> set in setAboutData.

Hm. Would it not be more strange if one cannot be sure that 
KAboutData::applicationData().displayName() matches 
app->applicationDisplayName()? And similar for the other shared/mapped 
application metadata properties? Why would I rather expect the original 
property of the KAboutData value to be kept, than it being updated to its 
counterpart in the Q*Application metadata, if changed by the Qt-API afterwards?
Surprised to see you expecting things to be different :)

Not that I expect it to happen a lot in real world code that the metadata of 
applications is set/reset by independent code snippets (and thus a mixture of 
KAboutData-using and Q*Application::setX-using), where random orders of writing 
and reading the data can happen. But if it happens, should not both 
Q*Application::setX and KAboutData::setApplicationData be equi-mighty, and both 
be acting on the same effective properties when it comes to metadata about the 
application instance, where it makes sense and is defined as such?

Or, why should KAboutData::setApplicationData be allowed to overrule any 
already set QApplication metadata (which makes sense to everyone), but not the 
other way around? :) Why should KAboutData::setApplicationData be 
write-through, but KAboutData::applicationData not be read-through?

Like it is now, if I would want to use metadata of the application, I cannot 
rely on KAboutData::applicationData alone, I also have to separately read 
things by Q*Application::x, to be sure to really have the values also used by 
other Qt-only parts of the code. Which renders the duplicates of those 
Q*Application properties in KAboutData useless, no?
I would expect more code to be broken if it relies only on 
KAboutData::applicationData() than code which expects any properties to keep 
their values, even if getting out-of-sync with the Qt application metadata.

For the bug which motivated me to write this patch, agreeing on initialising at 
least the global KAboutData instance to current Q*Application data should be 
fine, so will change the patch to that now. But well, I think this initial 
patch should be the way to go and yield less surprising behaviour :)


- Friedrich W. H.


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


On April 28, 2016, 1:04 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127655/
> ---
> 
> (Updated April 28, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and Michael Pyne.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> KAboutData is passed as values on getting and setting the "applicationData",
> and it only makes sense to have its properties be a transparent access
> to the actual mirrored Q*Application metadata.
> 
> Even more as there is code in KF5 (e.g. KXMLGUI) which relies on 
> KAboutData::applicationData(),
> without requiring the user to use KAboutData::setApplicationData().
> 
> 
> Diffs
> -
> 
>   autotests/kaboutdatatest.cpp f31e7f3 
>   src/lib/kaboutdata.h 97c0f2b 
>   src/lib/kaboutdata.cpp ceb0c06 
> 
> Diff: https://git.reviewboard.kde.org/r/127655/diff/
> 
> 
> Testing
> ---
> 
> Added autotests pass.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

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

Re: Version 5.21.0 for ECM missing (was: Re: Please add new versions on bugs.kde.org products on KF5 releases)

[David Faure]

On Monday 02 May 2016 10:02:29 Friedrich W. H. Kossebau wrote:
> Hi David,
> 
> Am Samstag, 9. April 2016, 12:09:30 CEST schrieb David Faure:
> > On Friday 08 April 2016 02:10:15 Friedrich W. H. Kossebau wrote:
> > > Right now it seems at least the 5.21.0 version misses with all KF5
> > > products, though some also seem to miss the version 5.20.0 (e.g.
> > > frameworks-khtml or frameworks-kiconthemes)
> > 
> > Indeed there was a bug in the script (I added a "grep for errors in the
> > returned HTML" and it made the script abort at the first error due to "set
> > -e").
> > 
> > I have now re-run the script for 5.20.0 (I'll do 5.21.0 later today) and it
> > created a few missing versions.
> 
> Given somehow ECM is now part of KF5 releases, could you please extend the 
> script to also add new versions for product=extra-cmake-modules to 
> bugs.kde.org?

It's supposed to handle ecm already.

> Right now at least 5.21.0 is missing for product extra-cmake-modules. Cmp.
> https://bugs.kde.org/editproducts.cgi?action=edit=extra-cmake-modules

Indeed. Very strange, because I just ran the script locally (with only ecm in 
modules.git)
and it created 5.21.0. So I don't know why it didn't do that on release day...

Let's keep an eye on it for 5.22.

-- 
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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[Anthony Fieroni]

> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/datacontainer.cpp, line 262
> > 
> >
> > why check storage is not null?
> > 
> > if storageCount > 1 and storage is null we have a huge bug elsewhere.
> 
> Anthony Fieroni wrote:
> So this *can* dangerous, if job emit twice. It's complex.
> 
> David Edmundson wrote:
> If a job emits what twice?

So, you are right, if KJob emitted twice whole logic is broken


- Anthony


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


On Май 2, 2016, 5:20 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated Май 2, 2016, 5:20 след обяд)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[David Edmundson]

> On May 2, 2016, 5:04 p.m., David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 574
> > 
> >
> > This is the memory leak fix?
> > 
> > If so, it's wrong.
> > 
> > we get called from:
> > 
> > QObject::connect(source, SIGNAL(destroyed(QObject*)), this, 
> > SLOT(sourceDestroyed(QObject*)));
> > 
> > 
> > destroyed() signal is emitted in QObject::~QObject
> > 
> > so it's already been deleted.
> 
> Anthony Fieroni wrote:
> A witch line is that?
> 
> David Edmundson wrote:
> dataengine.cpp:270
> 
> and QObject::destroyed is described here: 
> http://doc.qt.io/qt-5/qobject.html#destroyed
> 
> Anthony Fieroni wrote:
> 521 is the same. But in two cases 'this' and 'q' are DataEngine not 
> DataEnginePrivate where is actually the slot void 
> DataEnginePrivate::sourceDestroyed(QObject *object).
> So even my fix is wrong :)

>But in two cases 'this' and 'q' are DataEngine not DataEnginePrivate 

That's not a problem because the DataEngine header uses Q_PRIVATE_SLOT.

So it's still the DataEngine qobject with the slot, it's just the 
implementation is in DataEnginePrivate


- David


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


On May 2, 2016, 2:20 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated May 2, 2016, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[Anthony Fieroni]

> On Май 2, 2016, 8:04 след обяд, David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 574
> > 
> >
> > This is the memory leak fix?
> > 
> > If so, it's wrong.
> > 
> > we get called from:
> > 
> > QObject::connect(source, SIGNAL(destroyed(QObject*)), this, 
> > SLOT(sourceDestroyed(QObject*)));
> > 
> > 
> > destroyed() signal is emitted in QObject::~QObject
> > 
> > so it's already been deleted.
> 
> Anthony Fieroni wrote:
> A witch line is that?
> 
> David Edmundson wrote:
> dataengine.cpp:270
> 
> and QObject::destroyed is described here: 
> http://doc.qt.io/qt-5/qobject.html#destroyed

521 is the same. But in two cases 'this' and 'q' are DataEngine not 
DataEnginePrivate where is actually the slot void 
DataEnginePrivate::sourceDestroyed(QObject *object).
So even my fix is wrong :)


- Anthony


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


On Май 2, 2016, 5:20 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated Май 2, 2016, 5:20 след обяд)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[David Edmundson]

> On May 2, 2016, 5:04 p.m., David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 574
> > 
> >
> > This is the memory leak fix?
> > 
> > If so, it's wrong.
> > 
> > we get called from:
> > 
> > QObject::connect(source, SIGNAL(destroyed(QObject*)), this, 
> > SLOT(sourceDestroyed(QObject*)));
> > 
> > 
> > destroyed() signal is emitted in QObject::~QObject
> > 
> > so it's already been deleted.
> 
> Anthony Fieroni wrote:
> A witch line is that?

dataengine.cpp:270

and QObject::destroyed is described here: 
http://doc.qt.io/qt-5/qobject.html#destroyed


- David


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


On May 2, 2016, 2:20 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated May 2, 2016, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[Anthony Fieroni]

> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 415
> > 
> >
> > This (and the following changes) accomplish absolutely nothing!
> > 
> > previously. It started on -1, went down on refs, went up on refs. 
> > The only other usage is isUsed() which compares it to zero.
> > 
> > You've just switched the logic from negative to positive.
> > 
> > Whilst I agree yours makes far more sense, given you haven't mentioned 
> > it, it seem like you're just changing things at random without 
> > understanding it.
> 
> Anthony Fieroni wrote:
> I change it to 0, at first, but i saw, after that, loading engine can be 
> make it without manager to know. For me it's a broken design. I can revert 
> manager changes, at last.
> 
> David Edmundson wrote:
> How is it a broken design? It's *exactly* the same just with negative 
> numbers.

I mean, when load engine, from somewhere, no matter where, it must be every 
time with DataEngineManager, but this is not written like that. Manager is just 
a *option*


- Anthony


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


On Май 2, 2016, 5:20 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated Май 2, 2016, 5:20 след обяд)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[David Edmundson]

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




src/plasma/dataengine.cpp (line 574)


This is the memory leak fix?

If so, it's wrong.

we get called from:

QObject::connect(source, SIGNAL(destroyed(QObject*)), this, 
SLOT(sourceDestroyed(QObject*)));

destroyed() signal is emitted in QObject::~QObject

so it's already been deleted.


- David Edmundson


On May 2, 2016, 2:20 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated May 2, 2016, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[Anthony Fieroni]

> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 573
> > 
> >
> > Deleting an object auotmatically disconnects it
> > 
> > This seems like a terrible thing to do.

It's written in that style. Leak is a line below :)


> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 419
> > 
> >
> > Why?

Because it's depend of KPluginInfo, line 425, when KPluginInfo does not know 
that plugin, this is something *really* not valid, about me.


> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/dataengine.cpp, line 415
> > 
> >
> > This (and the following changes) accomplish absolutely nothing!
> > 
> > previously. It started on -1, went down on refs, went up on refs. 
> > The only other usage is isUsed() which compares it to zero.
> > 
> > You've just switched the logic from negative to positive.
> > 
> > Whilst I agree yours makes far more sense, given you haven't mentioned 
> > it, it seem like you're just changing things at random without 
> > understanding it.

I change it to 0, at first, but i saw, after that, loading engine can be make 
it without manager to know. For me it's a broken design. I can revert manager 
changes, at last.


> On Май 2, 2016, 7:33 след обяд, David Edmundson wrote:
> > src/plasma/datacontainer.cpp, line 262
> > 
> >
> > why check storage is not null?
> > 
> > if storageCount > 1 and storage is null we have a huge bug elsewhere.

So this *can* dangerous, if job emit twice. It's complex.


- Anthony


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


On Май 2, 2016, 5:20 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated Май 2, 2016, 5:20 след обяд)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[David Edmundson]

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



Which bit leaks? Why does it leak?
and what specific thing fixes it.


src/plasma/datacontainer.cpp (line 170)


this has absolutely nothing to do with fixing a leak and a possible crash.



src/plasma/datacontainer.cpp (line 262)


why check storage is not null?

if storageCount > 1 and storage is null we have a huge bug elsewhere.



src/plasma/dataengine.cpp (line 415)


This (and the following changes) accomplish absolutely nothing!

previously. It started on -1, went down on refs, went up on refs. 
The only other usage is isUsed() which compares it to zero.

You've just switched the logic from negative to positive.

Whilst I agree yours makes far more sense, given you haven't mentioned it, 
it seem like you're just changing things at random without understanding it.



src/plasma/dataengine.cpp (line 419)


Why?



src/plasma/dataengine.cpp (line 573)


Deleting an object auotmatically disconnects it

This seems like a terrible thing to do.


- David Edmundson


On May 2, 2016, 2:20 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127795/
> ---
> 
> (Updated May 2, 2016, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks and Marco Martin.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> ^^
> 
> 
> Diffs
> -
> 
>   autotests/pluginloadertest.h 61fc963 
>   autotests/pluginloadertest.cpp 4f96780 
>   src/plasma/datacontainer.cpp ee067db 
>   src/plasma/dataengine.cpp f942926 
>   src/plasma/private/dataenginemanager.cpp 08e42fb 
> 
> Diff: https://git.reviewboard.kde.org/r/127795/diff/
> 
> 
> Testing
> ---
> 
> Test pass.
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Review Request 127813: Process paths just once

[Aleix Pol Gonzalez]

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

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 127809: [Platform xcb] Get best icon size when he's not specified

[Martin Gräßlin]

> On May 2, 2016, 4:02 p.m., Martin Gräßlin wrote:
> > What is the "best" size if it's not specified? Why is your change better 
> > than how it was?
> > 
> > This change adjusts a very important part of the icon lookup functionality 
> > used by KWin and Plasma. I'm a little bit scared of touching it.
> > 
> > The change does not come with a test, so I have problems understanding what 
> > you want to change. Could you please extend the tests to ensure that this 
> > does not break existing functionality?
> 
> Anthony Fieroni wrote:
> I, personally, don't know when NETWinInfo->icon or icccmIconPixmap can 
> fail but when it happend function returns icon with size 16x16 when is called 
> like this -> KWindowSystem::icon (wid);

well that's what we have unit test for. They can show us whether the code fails.


> On May 2, 2016, 4:02 p.m., Martin Gräßlin wrote:
> > src/platforms/xcb/kwindowsystem.cpp, lines 740-741
> > 
> >
> > This makes the code way more difficult to read. I'm no longer able to 
> > grasp what's going on there.
> 
> Anthony Fieroni wrote:
> Threshold down/up scale was wrong.

The code is still pretty much unreadable.


- Martin


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


On May 2, 2016, 4:04 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127809/
> ---
> 
> (Updated May 2, 2016, 4:04 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 362324
> https://bugs.kde.org/show_bug.cgi?id=362324
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> The api function is KWindowSystem::icon (WId win, int width=-1, int 
> height=-1, bool scale=false) so caller must get best size not worst when 
> width/height is not specified.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 5b7c65a 
> 
> Diff: https://git.reviewboard.kde.org/r/127809/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/6d718ef6-26cf-4866-94d2-4ffbdfc906fe__Screenshot_20160426_232109.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/7dcab4ae-e451-4d43-8799-a0fcab471a3d__Screenshot_20160501_224642.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127795: [DataEngine] Fix memory leak and possible crash + detailed test

[Anthony Fieroni]

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

(Updated Май 2, 2016, 5:20 след обяд)


Review request for KDE Frameworks and Marco Martin.


Changes
---

So we don't want to change the api, dataengine has ref() == 1 when it's 
constructed


Repository: plasma-framework


Description
---

^^


Diffs (updated)
-

  autotests/pluginloadertest.h 61fc963 
  autotests/pluginloadertest.cpp 4f96780 
  src/plasma/datacontainer.cpp ee067db 
  src/plasma/dataengine.cpp f942926 
  src/plasma/private/dataenginemanager.cpp 08e42fb 

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


Testing
---

Test pass.


Thanks,

Anthony Fieroni

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

Re: Review Request 127809: [Platform xcb] Get best icon size when he's not specified

[Anthony Fieroni]

> On Май 2, 2016, 5:02 след обяд, Martin Gräßlin wrote:
> > What is the "best" size if it's not specified? Why is your change better 
> > than how it was?
> > 
> > This change adjusts a very important part of the icon lookup functionality 
> > used by KWin and Plasma. I'm a little bit scared of touching it.
> > 
> > The change does not come with a test, so I have problems understanding what 
> > you want to change. Could you please extend the tests to ensure that this 
> > does not break existing functionality?

I, personally, don't know when NETWinInfo->icon or icccmIconPixmap can fail but 
when it happend function returns icon with size 16x16 when is called like this 
-> KWindowSystem::icon (wid);


- Anthony


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


On Май 2, 2016, 5:04 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127809/
> ---
> 
> (Updated Май 2, 2016, 5:04 след обяд)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 362324
> https://bugs.kde.org/show_bug.cgi?id=362324
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> The api function is KWindowSystem::icon (WId win, int width=-1, int 
> height=-1, bool scale=false) so caller must get best size not worst when 
> width/height is not specified.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 5b7c65a 
> 
> Diff: https://git.reviewboard.kde.org/r/127809/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/6d718ef6-26cf-4866-94d2-4ffbdfc906fe__Screenshot_20160426_232109.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/7dcab4ae-e451-4d43-8799-a0fcab471a3d__Screenshot_20160501_224642.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127809: [Platform xcb] Get best icon size when he's not specified

[Anthony Fieroni]

> On Май 2, 2016, 5:02 след обяд, Martin Gräßlin wrote:
> > src/platforms/xcb/kwindowsystem.cpp, lines 740-741
> > 
> >
> > This makes the code way more difficult to read. I'm no longer able to 
> > grasp what's going on there.

Threshold down/up scale was wrong.


- Anthony


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


On Май 2, 2016, 5:04 след обяд, Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127809/
> ---
> 
> (Updated Май 2, 2016, 5:04 след обяд)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 362324
> https://bugs.kde.org/show_bug.cgi?id=362324
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> The api function is KWindowSystem::icon (WId win, int width=-1, int 
> height=-1, bool scale=false) so caller must get best size not worst when 
> width/height is not specified.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 5b7c65a 
> 
> Diff: https://git.reviewboard.kde.org/r/127809/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/6d718ef6-26cf-4866-94d2-4ffbdfc906fe__Screenshot_20160426_232109.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/7dcab4ae-e451-4d43-8799-a0fcab471a3d__Screenshot_20160501_224642.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127809: [Platform xcb] Get best icon size when he's not specified

[Anthony Fieroni]

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

(Updated Май 2, 2016, 5:04 след обяд)


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


Changes
---

Correct scale threshold values


Bugs: 362324
https://bugs.kde.org/show_bug.cgi?id=362324


Repository: kwindowsystem


Description
---

The api function is KWindowSystem::icon (WId win, int width=-1, int height=-1, 
bool scale=false) so caller must get best size not worst when width/height is 
not specified.


Diffs (updated)
-

  src/platforms/xcb/kwindowsystem.cpp 5b7c65a 

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


Testing
---


File Attachments


before
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/6d718ef6-26cf-4866-94d2-4ffbdfc906fe__Screenshot_20160426_232109.png
after
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/7dcab4ae-e451-4d43-8799-a0fcab471a3d__Screenshot_20160501_224642.png


Thanks,

Anthony Fieroni

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

Re: Review Request 127809: [Platform xcb] Get best icon size when he's not specified

[Martin Gräßlin]

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



What is the "best" size if it's not specified? Why is your change better than 
how it was?

This change adjusts a very important part of the icon lookup functionality used 
by KWin and Plasma. I'm a little bit scared of touching it.

The change does not come with a test, so I have problems understanding what you 
want to change. Could you please extend the tests to ensure that this does not 
break existing functionality?


src/platforms/xcb/kwindowsystem.cpp (lines 739 - 740)


This makes the code way more difficult to read. I'm no longer able to grasp 
what's going on there.


- Martin Gräßlin


On May 1, 2016, 10:07 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127809/
> ---
> 
> (Updated May 1, 2016, 10:07 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Martin Gräßlin.
> 
> 
> Bugs: 362324
> https://bugs.kde.org/show_bug.cgi?id=362324
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> The api function is KWindowSystem::icon (WId win, int width=-1, int 
> height=-1, bool scale=false) so caller must get best size not worst when 
> width/height is not specified.
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 5b7c65a 
> 
> Diff: https://git.reviewboard.kde.org/r/127809/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/6d718ef6-26cf-4866-94d2-4ffbdfc906fe__Screenshot_20160426_232109.png
> after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/01/7dcab4ae-e451-4d43-8799-a0fcab471a3d__Screenshot_20160501_224642.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

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

Re: Review Request 127779: use system colors for monochrome icons

[Marco Martin]

> On May 2, 2016, 1:51 p.m., Milian Wolff wrote:
> > one more question: have you tried this with krita (or digicam) and their 
> > builtin functionality to change the app's color scheme? I.e. what about 
> > per-app changes vs. system-wide changes?

I have to test this more, indeed probably won't work.
I am not sure that would be really workable out of the box, but if the color 
scheme (name?hash of the actual colors?) is inserted in the pixmap cache key, 
then it should work (having a setter/getter for a custom color scheme in 
kiconloader could even work for applications that use light and dark color 
schemes at the same time in different places, provided they have different 
instance of kiconloader and load directly with kiconloader the icons in the 
areas that are using a different color scheme than the system wide one)


- Marco


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


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127810: Fix some gcc5.3 compile warnings in kwayland

[Allen Winter]

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

(Updated May 2, 2016, 3:54 p.m.)


Status
--

This change has been marked as submitted.


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


Changes
---

Submitted with commit 212db4cda72be1f406b1a1bd4756190e7e4e847f by Allen Winter 
to branch master.


Repository: kwayland


Description
---

eliminate -Wmissing-include-dirs, -Wunused-parameter and -Wsign-compare 
warnings from gcc5.3.1


Diffs
-

  autotests/client/CMakeLists.txt ed0970b 
  src/client/outputdevice.cpp 6fc3d3c 
  src/client/outputmanagement.cpp 9aaf331 
  src/client/plasmawindowmanagement.cpp 81c6a3b 

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


Testing
---

still compiles.
a warning remains that I don't know how to fix yet: 
/data/kde5/src/frameworks/kwayland/src/client/buffer_p.h:32:15: warning: 
‘KWayland::Client::Buffer::Private’ has a field 
‘KWayland::Client::Buffer::Private::nativeBuffer’ whose type uses the anonymous 
namespace

but otherwise most other compiler warnings are fixed with this patch


Thanks,

Allen Winter

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

Re: Review Request 127779: use system colors for monochrome icons

[Milian Wolff]

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



one more question: have you tried this with krita (or digicam) and their 
builtin functionality to change the app's color scheme? I.e. what about per-app 
changes vs. system-wide changes?

- Milian Wolff


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127779: use system colors for monochrome icons

[Marco Martin]

> On May 2, 2016, 1:09 p.m., Sebastian Kügler wrote:
> > Okay, let's try this in master and see if it's going to cause problems.
> 
> Kai Uwe Broulik wrote:
> Beware this is frameworks and the next frameworks release will be 
> upcoming Saturday
> 
> Marco Martin wrote:
> I was aiming at first for this one. Do you think has potential issues 
> that would make it better having it in 5.23?
> 
> Sebastian Kügler wrote:
> I don't see any, but then, it's pretty intrusive. I'd trust your 
> judgment, Marco.

ah, well, will push next monday then, if not else for the dependency it adds to 
the framework, that's better it's done at beginning of cycle


- Marco


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


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127779: use system colors for monochrome icons

[Sebastian Kügler]

> On May 2, 2016, 1:09 p.m., Sebastian Kügler wrote:
> > Okay, let's try this in master and see if it's going to cause problems.
> 
> Kai Uwe Broulik wrote:
> Beware this is frameworks and the next frameworks release will be 
> upcoming Saturday
> 
> Marco Martin wrote:
> I was aiming at first for this one. Do you think has potential issues 
> that would make it better having it in 5.23?

I don't see any, but then, it's pretty intrusive. I'd trust your judgment, 
Marco.


- Sebastian


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


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127810: Fix some gcc5.3 compile warnings in kwayland

[Sebastian Kügler]

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


Ship it!




- Sebastian Kügler


On May 1, 2016, 8:32 p.m., Allen Winter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127810/
> ---
> 
> (Updated May 1, 2016, 8:32 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> eliminate -Wmissing-include-dirs, -Wunused-parameter and -Wsign-compare 
> warnings from gcc5.3.1
> 
> 
> Diffs
> -
> 
>   autotests/client/CMakeLists.txt ed0970b 
>   src/client/outputdevice.cpp 6fc3d3c 
>   src/client/outputmanagement.cpp 9aaf331 
>   src/client/plasmawindowmanagement.cpp 81c6a3b 
> 
> Diff: https://git.reviewboard.kde.org/r/127810/diff/
> 
> 
> Testing
> ---
> 
> still compiles.
> a warning remains that I don't know how to fix yet: 
> /data/kde5/src/frameworks/kwayland/src/client/buffer_p.h:32:15: warning: 
> ‘KWayland::Client::Buffer::Private’ has a field 
> ‘KWayland::Client::Buffer::Private::nativeBuffer’ whose type uses the 
> anonymous namespace
> 
> but otherwise most other compiler warnings are fixed with this patch
> 
> 
> Thanks,
> 
> Allen Winter
> 
>

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

Re: Review Request 127779: use system colors for monochrome icons

[Marco Martin]

> On May 2, 2016, 1:09 p.m., Sebastian Kügler wrote:
> > Okay, let's try this in master and see if it's going to cause problems.
> 
> Kai Uwe Broulik wrote:
> Beware this is frameworks and the next frameworks release will be 
> upcoming Saturday

I was aiming at first for this one. Do you think has potential issues that 
would make it better having it in 5.23?


- Marco


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


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127779: use system colors for monochrome icons

[Sebastian Kügler]

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




autotests/kiconloader_unittest.cpp (line 441)


Has the image been recolored to red ...

(word order makes it easier to read)



src/kiconloader.cpp (line 290)


If the icon is an SVG file, ...



src/kiconloader.cpp (line 292)


text (lower case), perhaps @see the colors that are available?



src/kiconloader.cpp (line 869)


Where does this one get deleted?


- Sebastian Kügler


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127779: use system colors for monochrome icons

[Kai Uwe Broulik]

> On Mai 2, 2016, 1:09 nachm., Sebastian Kügler wrote:
> > Okay, let's try this in master and see if it's going to cause problems.

Beware this is frameworks and the next frameworks release will be upcoming 
Saturday


- Kai Uwe


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


On April 29, 2016, 9:25 vorm., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 vorm.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.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 127779: use system colors for monochrome icons

[Sebastian Kügler]

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


Ship it!




Okay, let's try this in master and see if it's going to cause problems.

- Sebastian Kügler


On April 29, 2016, 9:25 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127779/
> ---
> 
> (Updated April 29, 2016, 9:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kiconthemes
> 
> 
> Description
> ---
> 
> Breeze uses stylesheet information to color its icons with some "named" 
> colors that change depending from the current system color scheme, this is 
> already used since some time in the icons used by the Plasma shell.
> But QWidget applications have the same problem, when the user changes the 
> color scheme from breeze to breeze dark (or any color scheme), most of the 
> icons will be black on black.
> This patch clones (a bit simplified and taking only the most "important" 
> colors) the logic used by Plasma::Svg to color icons with the stylesheet.
> 
> even tough it's doing more things at icon generation, an application that 
> uses a lot of icons like Dolphin doesn't seem to have noticeable startup time 
> difference, even when the image cache is not present yet, so i hope is not an 
> unacceptable performance tradeoff (successive loads are unchanged as are from 
> the image cache).
> 
> still some questions and things that can be optimized, like
> 
> * an optional key in the theme metadata file to explicitly enable this, to 
> not have it running in themes that don't care?
> 
> * can i use karchive in this framework?, so it would work with svgz icons as 
> well
> 
> * right now to refresh icons at runtime it depends from a patch in the colors 
> kcm to emit iconchanges as well, alternatively kiconloader could watch for 
> kcolorscheme changes as well, but i don't think is strictly necessary
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 2e838e8 
>   autotests/coloredsvgicon.svg PRE-CREATION 
>   autotests/kiconloader_unittest.cpp 0e47cc8 
>   autotests/resources.qrc a19c963 
>   src/CMakeLists.txt 0e30a35 
>   src/kiconloader.cpp 75ab482 
>   src/kicontheme.h 3190665 
>   src/kicontheme.cpp 0996054 
> 
> Diff: https://git.reviewboard.kde.org/r/127779/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> dadel1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/04/28/0fc42425-947c-479e-9759-09c7a703a456__dadel1.png
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

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

Re: [kate/Applications/16.04] kate: Close document: use icon document-close instead of window-close

[kainz.a]

Hi,

thank's for the question.

Yes the close icon in the toolbar should be document-close, sorry that I
don't report this "bug".


​about the configure dialog:
we found the rule to don't mix monochrome and colored icons. as you have
for the most elements action icons I would suggest also action icons for
the colored ones.
- application-menu
  - go-home (that's a really good idea)
  - edit-find
  - plugins
  - view-list-tree
  * svn-commit (new)
* document-edit (new)
  - edit-guides
  * format-text-color (new)
  * document-edit (new)
  - document-save

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

DISCARDED: proposal for devel-versions with KF5 (was: Re: Please add new versions on bugs.kde.org products on KF5 releases)

[Friedrich W. H. Kossebau]

Am Sonntag, 10. April 2016, 09:33:51 CEST schrieb David Faure:
> On Saturday 09 April 2016 19:02:02 Friedrich W. H. Kossebau wrote:
> > IIRC elsewhere I have seen people using a version called "git" in issue
> > trackers, which would be used by developers for random snaphots and have
> > them state the git commit id explicitely in the bug report.
> 
> Alternatively, one can use the version number of the last release, and still
> mention in the bug report the git sha-1 they are using. This seems
> sufficient to me.
> > But that makes it hard
> > to track regressions/new bugs between 2 versions.
> > 
> > So what about some "5.xx.0-pre" version, set once the "5.(xx-1).0" is
> > branched? That would allow to collect regressions/new bugs in the
> > development phase separately, without mixing them into bugs for the last
> > released version.
> Is there an actual need for this ? It seems to me that this is
> over-engineering it "just in case".

Given no-one else (especially any of KF5 module maintainers) expressed an 
opinion indeed for KF5 it might be over-engineered :) so proposal for 
unreleased version numbers/ids with KF5 discarded here.

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

Version 5.21.0 for ECM missing (was: Re: Please add new versions on bugs.kde.org products on KF5 releases)

[Friedrich W. H. Kossebau]

Hi David,

Am Samstag, 9. April 2016, 12:09:30 CEST schrieb David Faure:
> On Friday 08 April 2016 02:10:15 Friedrich W. H. Kossebau wrote:
> > Right now it seems at least the 5.21.0 version misses with all KF5
> > products, though some also seem to miss the version 5.20.0 (e.g.
> > frameworks-khtml or frameworks-kiconthemes)
> 
> Indeed there was a bug in the script (I added a "grep for errors in the
> returned HTML" and it made the script abort at the first error due to "set
> -e").
> 
> I have now re-run the script for 5.20.0 (I'll do 5.21.0 later today) and it
> created a few missing versions.

Given somehow ECM is now part of KF5 releases, could you please extend the 
script to also add new versions for product=extra-cmake-modules to 
bugs.kde.org?

Right now at least 5.21.0 is missing for product extra-cmake-modules. Cmp.
https://bugs.kde.org/editproducts.cgi?action=edit=extra-cmake-modules

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

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/ktexteditor%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/56/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:42:53 +
Build duration: 7 min 27 sec

CHANGE SET
Revision c6b4ebb2e3ef4f27720de9dae94194b8cb8d1846 by dhaumann: (Use proper char 
syntax  instead of \)
  change: edit src/document/katedocument.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 23/27 (85%)FILES 278/314 (89%)CLASSES 278/314 (89%)LINE 29724/46495 
(64%)CONDITIONAL 15661/31618 (50%)

By packages
  
autotests.src
FILES 48/48 (100%)CLASSES 48/48 (100%)LINE 4061/4374 
(93%)CONDITIONAL 1920/3906 (49%)
autotests.src.vimode
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 3149/3164 
(100%)CONDITIONAL 374/632 (59%)
src.buffer
FILES 14/15 (93%)CLASSES 14/15 (93%)LINE 1617/1759 
(92%)CONDITIONAL 1255/1622 (77%)
src.completion
FILES 16/16 (100%)CLASSES 16/16 (100%)LINE 1746/3111 
(56%)CONDITIONAL 1206/2816 (43%)
src.completion.expandingtree
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 183/465 (39%)CONDITIONAL 
77/354 (22%)
src.dialogs
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/931 (0%)CONDITIONAL 0/278 
(0%)
src.document
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 1807/3205 
(56%)CONDITIONAL 1491/3159 (47%)
src.export
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 106/125 (85%)CONDITIONAL 
104/152 (68%)
src.include.ktexteditor
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 203/242 
(84%)CONDITIONAL 144/228 (63%)
src.inputmode
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 180/331 (54%)CONDITIONAL 
55/107 (51%)
src.mode
FILES 5/6 (83%)CLASSES 5/6 (83%)LINE 159/423 (38%)CONDITIONAL 
97/269 (36%)
src.printing
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/885 (0%)CONDITIONAL 0/294 
(0%)
src.render
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 897/1225 
(73%)CONDITIONAL 598/926 (65%)
src.schema
FILES 2/9 (22%)CLASSES 2/9 (22%)LINE 21/1538 (1%)CONDITIONAL 
7/697 (1%)
src.script
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 696/1055 
(66%)CONDITIONAL 292/556 (53%)
src.search
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 897/1389 
(65%)CONDITIONAL 519/904 (57%)
src.spellcheck
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 372/1336 (28%)CONDITIONAL 
205/820 (25%)
src.swapfile
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 119/365 (33%)CONDITIONAL 
57/195 (29%)
src.syntax
FILES 11/12 (92%)CLASSES 11/12 (92%)LINE 1661/2135 
(78%)CONDITIONAL 1057/1766 (60%)
src.syntax.data
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 51/69 (74%)CONDITIONAL 
73/92 (79%)
src.undo
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 671/772 (87%)CONDITIONAL 
321/448 (72%)
src.utils
FILES 33/36 (92%)CLASSES 33/36 (92%)LINE 2516/3882 
(65%)CONDITIONAL 1294/2706 (48%)
src.variableeditor
FILES 0/7 (0%)CLASSES 0/7 (0%)LINE 0/659 (0%)CONDITIONAL 0/170 
(0%)
src.view
FILES 15/18 (83%)CLASSES 15/18 (83%)LINE 3069/6090 
(50%)CONDITIONAL 1366/3674 (37%)
src.vimode
FILES 34/35 (97%)CLASSES 34/35 (97%)LINE 2300/3093 
(74%)CONDITIONAL 1298/2387 (54%)
src.vimode.config
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/134 (0%)CONDITIONAL 0/90 
(0%)
src.vimode.modes
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 3243/3738 
(87%)CONDITIONAL 1851/2370 (78%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/ktexteditor%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/56/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:42:53 +
Build duration: 7 min 27 sec

CHANGE SET
Revision c6b4ebb2e3ef4f27720de9dae94194b8cb8d1846 by dhaumann: (Use proper char 
syntax  instead of \)
  change: edit src/document/katedocument.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 23/27 (85%)FILES 278/314 (89%)CLASSES 278/314 (89%)LINE 29724/46495 
(64%)CONDITIONAL 15661/31618 (50%)

By packages
  
autotests.src
FILES 48/48 (100%)CLASSES 48/48 (100%)LINE 4061/4374 
(93%)CONDITIONAL 1920/3906 (49%)
autotests.src.vimode
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 3149/3164 
(100%)CONDITIONAL 374/632 (59%)
src.buffer
FILES 14/15 (93%)CLASSES 14/15 (93%)LINE 1617/1759 
(92%)CONDITIONAL 1255/1622 (77%)
src.completion
FILES 16/16 (100%)CLASSES 16/16 (100%)LINE 1746/3111 
(56%)CONDITIONAL 1206/2816 (43%)
src.completion.expandingtree
FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 183/465 (39%)CONDITIONAL 
77/354 (22%)
src.dialogs
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/931 (0%)CONDITIONAL 0/278 
(0%)
src.document
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 1807/3205 
(56%)CONDITIONAL 1491/3159 (47%)
src.export
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 106/125 (85%)CONDITIONAL 
104/152 (68%)
src.include.ktexteditor
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 203/242 
(84%)CONDITIONAL 144/228 (63%)
src.inputmode
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 180/331 (54%)CONDITIONAL 
55/107 (51%)
src.mode
FILES 5/6 (83%)CLASSES 5/6 (83%)LINE 159/423 (38%)CONDITIONAL 
97/269 (36%)
src.printing
FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/885 (0%)CONDITIONAL 0/294 
(0%)
src.render
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 897/1225 
(73%)CONDITIONAL 598/926 (65%)
src.schema
FILES 2/9 (22%)CLASSES 2/9 (22%)LINE 21/1538 (1%)CONDITIONAL 
7/697 (1%)
src.script
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 696/1055 
(66%)CONDITIONAL 292/556 (53%)
src.search
FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 897/1389 
(65%)CONDITIONAL 519/904 (57%)
src.spellcheck
FILES 5/7 (71%)CLASSES 5/7 (71%)LINE 372/1336 (28%)CONDITIONAL 
205/820 (25%)
src.swapfile
FILES 1/2 (50%)CLASSES 1/2 (50%)LINE 119/365 (33%)CONDITIONAL 
57/195 (29%)
src.syntax
FILES 11/12 (92%)CLASSES 11/12 (92%)LINE 1661/2135 
(78%)CONDITIONAL 1057/1766 (60%)
src.syntax.data
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 51/69 (74%)CONDITIONAL 
73/92 (79%)
src.undo
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 671/772 (87%)CONDITIONAL 
321/448 (72%)
src.utils
FILES 33/36 (92%)CLASSES 33/36 (92%)LINE 2516/3882 
(65%)CONDITIONAL 1294/2706 (48%)
src.variableeditor
FILES 0/7 (0%)CLASSES 0/7 (0%)LINE 0/659 (0%)CONDITIONAL 0/170 
(0%)
src.view
FILES 15/18 (83%)CLASSES 15/18 (83%)LINE 3069/6090 
(50%)CONDITIONAL 1366/3674 (37%)
src.vimode
FILES 34/35 (97%)CLASSES 34/35 (97%)LINE 2300/3093 
(74%)CONDITIONAL 1298/2387 (54%)
src.vimode.config
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/134 (0%)CONDITIONAL 0/90 
(0%)
src.vimode.modes
FILES 10/10 (100%)CLASSES 10/10 (100%)LINE 3243/3738 
(87%)CONDITIONAL 1851/2370 (78%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: ktexteditor master stable-kf5-qt5 » Linux,gcc - Build # 55 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/ktexteditor%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/55/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:29:19 +
Build duration: 8 min 35 sec

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

Jenkins-kde-ci: baloo master kf5-qt5 » Linux,gcc - Build # 44 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/baloo%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/44/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:24:14 +
Build duration: 4 min 7 sec

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

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 46 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/46/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:24:14 +
Build duration: 1 min 55 sec

CHANGE SET
No changes


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 7 
test(s)Failed: TestSuite.frameworkintegration-kfiledialogqml_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 19/19 (100%)CLASSES 19/19 (100%)LINE 1140/1717 
(66%)CONDITIONAL 451/1085 (42%)

By packages
  
autotests
FILES 6/6 (100%)CLASSES 6/6 (100%)LINE 387/395 (98%)CONDITIONAL 
199/375 (53%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)
src.platformtheme
FILES 12/12 (100%)CLASSES 12/12 (100%)LINE 706/1144 
(62%)CONDITIONAL 223/548 (41%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kross master stable-kf5-qt5 » Linux,gcc - Build # 38 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kross%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/38/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:24:00 +
Build duration: 2 min 39 sec

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

Jenkins-kde-ci: frameworkintegration master stable-kf5-qt5 » Linux,gcc - Build # 42 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/42/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:24:00 +
Build duration: 2 min 36 sec

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

Jenkins-kde-ci: kio master kf5-qt5 » Linux,gcc - Build # 42 - Still Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/42/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:17:44 +
Build duration: 4 min 29 sec

CHANGE SET
Revision ee86cc6d5c5fe22066f6e655b0d59b7e22b0b2b8 by dhaumann: 
(KMountPoint::probablySlow(): use lazy evaluation of conditions (minor)
  change: edit src/core/kmountpoint.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 48 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiofilewidgets-kfileplacesmodeltestFailed: 
TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/338 (77%)CLASSES 260/338 (77%)LINE 26420/50618 
(52%)CONDITIONAL 14495/37357 (39%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7275/7850 
(93%)CONDITIONAL 3838/8140 (47%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 95/117 (81%)CLASSES 95/117 (81%)LINE 7660/14036 
(55%)CONDITIONAL 4139/8905 (46%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE /7564 
(29%)CONDITIONAL 889/4399 (20%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1754/3781 
(46%)CONDITIONAL 1249/3434 (36%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 685/762 (90%)CONDITIONAL 
433/912 (47%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 359/385 (93%)CONDITIONAL 
102/138 (74%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 382/594 (64%)CONDITIONAL 
284/580 (49%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 31/34 (91%)CONDITIONAL 
42/54 (78%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 220/249 (88%)CONDITIONAL 
298/378 (79%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2668/10599 
(25%)CONDITIONAL 1308/6780 (19%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/39/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 02 May 2016 06:17:44 +
Build duration: 5 min 47 sec

CHANGE SET
Revision ee86cc6d5c5fe22066f6e655b0d59b7e22b0b2b8 by dhaumann: 
(KMountPoint::probablySlow(): use lazy evaluation of conditions (minor)
  change: edit src/core/kmountpoint.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 49 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/338 (77%)CLASSES 260/338 (77%)LINE 26714/50599 
(53%)CONDITIONAL 14859/37333 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7515/7831 
(96%)CONDITIONAL 4166/8116 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 95/117 (81%)CLASSES 95/117 (81%)LINE 7668/14036 
(55%)CONDITIONAL 4145/8905 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2267/7564 
(30%)CONDITIONAL 914/4399 (21%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1762/3781 
(47%)CONDITIONAL 1258/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 685/762 (90%)CONDITIONAL 
433/912 (47%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 359/385 (93%)CONDITIONAL 
102/138 (74%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 31/34 (91%)CONDITIONAL 
42/54 (78%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 220/249 (88%)CONDITIONAL 
298/378 (79%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2666/10599 
(25%)CONDITIONAL 1306/6780 (19%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127808: Minor speedup of KMountPoint::probablySlow()

[Dominik Haumann]

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

(Updated May 2, 2016, 8:17 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit ee86cc6d5c5fe22066f6e655b0d59b7e22b0b2b8 by Dominik 
Haumann to branch master.


Repository: kio


Description
---

Use lazy evaluation instead of comparing all filesystem types first, and then 
returning true/false.


Diffs
-

  src/core/kmountpoint.cpp 5feb3a8 

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


Testing
---

Compiles.


Thanks,

Dominik Haumann

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