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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/97/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 21:06:28 +
Build duration: 2 min 4 sec

CHANGE SET
Revision a30e4705cb63418f3786c2fa3a70b1c7cbb0cabc by David Faure: (Fix autotest 
to actually test the recursion.)
  change: edit autotests/ksycocatest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5589/8184 
(68%)CONDITIONAL 2897/4351 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1423/1549 
(92%)CONDITIONAL 872/1586 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1803/3088 
(58%)CONDITIONAL 754/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2158/2948 
(73%)CONDITIONAL 1186/1530 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/97/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 21:06:28 +
Build duration: 2 min 4 sec

CHANGE SET
Revision a30e4705cb63418f3786c2fa3a70b1c7cbb0cabc by David Faure: (Fix autotest 
to actually test the recursion.)
  change: edit autotests/ksycocatest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5589/8184 
(68%)CONDITIONAL 2897/4351 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1423/1549 
(92%)CONDITIONAL 872/1586 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1803/3088 
(58%)CONDITIONAL 754/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2158/2948 
(73%)CONDITIONAL 1186/1530 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125695: Make KAboutData::translators/setTranslators simple

[Albert Astals Cid]

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

Review request for KDE Frameworks, Chusslove Illich and Michael Pyne.


Repository: kcoreaddons


Description
---

Move the responsability to the user.

Document how to implement them either using ki18n and document that KMainWindow 
does it for you.


Diffs
-

  src/lib/kaboutdata.h a94e2c5 
  src/lib/kaboutdata.cpp af10fc6 

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


Testing
---


Thanks,

Albert Astals Cid

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

Re: Review Request 125164: Fix misbehavior when canceling a job

[Aleix Pol Gonzalez]

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


bump?

- Aleix Pol Gonzalez


On Sept. 11, 2015, 3:24 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125164/
> ---
> 
> (Updated Sept. 11, 2015, 3:24 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Catch that the job has been cancelled and emit the job as finished.
> 
> Still, I'm not too sure it's the correct fix.
> 
> 
> Diffs
> -
> 
>   autotests/jobtest.h ef8c3e1 
>   autotests/jobtest.cpp c24bcea 
>   src/core/transferjob.cpp 0c38070 
> 
> Diff: https://git.reviewboard.kde.org/r/125164/diff/
> 
> 
> Testing
> ---
> 
> Added a test and made it pass.
> 
> 
> 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 125658: Do not treat the context menu button as modifier

[Aleix Pol Gonzalez]

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

Ship it!


Makes sense to me.

- Aleix Pol Gonzalez


On Oct. 18, 2015, 4:45 p.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125658/
> ---
> 
> (Updated Oct. 18, 2015, 4:45 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Feck and Hans Chen.
> 
> 
> Bugs: 165542
> https://bugs.kde.org/show_bug.cgi?id=165542
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> It's not and not treated as such by Qt either.
> 
> In addition suck context events while recording
> (so it doesn't activate, rather cosmetic)
> 
> BUG: 165542
> FIXED-IN: 5.16
> CHANGELOG: Allow to bind the contextmenu key (lower right) to shortcuts
> 
> 
> Diffs
> -
> 
>   src/kkeysequencewidget.cpp 2385f20 
> 
> Diff: https://git.reviewboard.kde.org/r/125658/diff/
> 
> 
> Testing
> ---
> 
> yupp.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 125681: Correctly set the printSetting's parent

[Robby Stephenson]

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

(Updated Oct. 18, 2015, 8:58 p.m.)


Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark.


Changes
---

Create the dialog first, then use it as the printSetting parent


Repository: khtml


Description
---

Avoid setting printSettings as its own parent. It should properly be
owned by the print dialog, which seems to have been the intent in KDE4.


Diffs (updated)
-

  src/khtmlview.cpp d9bbc38b1677a3faf3be46ccc3a211c8d7289e45 

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


Testing
---

Tellico's printing (which uses KHTMLPart) no longer hangs, but works properly.


Thanks,

Robby Stephenson

___
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 # 101 - Unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/101/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 21:06:28 +
Build duration: 1 min 39 sec

CHANGE SET
Revision a30e4705cb63418f3786c2fa3a70b1c7cbb0cabc by David Faure: (Fix autotest 
to actually test the recursion.)
  change: edit autotests/ksycocatest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5623/8184 
(69%)CONDITIONAL 2904/4357 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1451/1549 
(94%)CONDITIONAL 872/1586 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1803/3088 
(58%)CONDITIONAL 755/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2164/2948 
(73%)CONDITIONAL 1192/1536 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Policy for Dependencies

[Alex Merry]

On Sunday, 18 October 2015 14:45:43 BST David Faure wrote:
> On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote:
> > Lets see what David thinks about all that.
> 
> First: thanks everyone for waiting for my input, I appreciate that (I'm just
> one more voice though, no dictatorship here).

But a well-respected voice :-). Also, you're the closest thing we have to a 
"frameworks co-ordinator", in your role as release manager.

> The various global switches that have been suggested had unintuitive naming,
> so I will describe my thinking about them by using descriptions instead of
> actual names:
> 
> 1) A global switch "skip anything marked as optional" would be a very bad
> idea, it would even skip stuff that *is* available. I *think* this wasn't
> suggested, but I wanted to mention it just in case.

There may be a certain temptation to view it as an easy solution for those who 
want to build a stripped-down version of (part of) Frameworks without 
accidentally dragging in deps that happen to be on the builder's system. In 
practice, however, anyone doing this would probably want close control over 
the deps (rather than stripping out everything optional), and CMake already 
provides that via some magic variables to disable searching for packages.

> 2) A global switch "everything that can be optional, is now optional" sounds
> strange to me too. If it's optional, it's optional. (The description for
> the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a
> loss of functionality". Well, that is *always* true when an optional
> dependency isn't found - otherwise it would be useless). Really, is there
> any sense in saying that a dependency is optionally optional? 
> 
> 2.1) I can see how the purpose was to let the default build be "with as many
> dependencies as possible". But for that maybe we can have a global switch
> for "fail if something optional was not found", for distros (and CI) to
> make sure they have *everything* enabled. Would this actually work for
> distro packagers? Do they have *all* the dependencies available?

I think it's more about the distinction (vague as it may be) between 
"optional" and "recommended" dependencies (FeatureSummary provides this 
distinction, but we very rarely use it). I think the idea is to be able to 
distinguish between "if this exists on your system, we will attempt to 
integrate with it" dependencies and "if we don't make use of this, a feature 
might be missing that users would expect to be there".

(As a side note, we may have that package A depends on package B *with 
optional feature C*. In particular, bits of Plasma may well require or 
recommend that certain Frameworks are built with certain features enabled that 
rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for 
how to deal with that.)

I think the idea was essentially to have an easy way to cause a build failure 
if the recommended dependencies weren't found (possibly with the default being 
the failure mode).

I'm fairly on the fence about the usefulness of that, TBH, particularly if 
your idea below solves the "bug reports from feature-deprived builds" issue.

> An argument was made that optional deps create more work for maintainers,
> who can't know, in bug reports, whether the dep was enabled or disabled
> (i.e. more configurations to handle). That is true. The solution isn't
> however to make everything mandatory. So we should solve this, after
> accepting the existence of optional deps. One random idea could be
> (automatically) installing a file, from each framework, with the list of
> optional deps that were found. Then when handling bug reports you can ask
> for that file -- or drkonqi could grab them all and concatenate them in a
> readable way.

This seems like a useful thing to do, especially when automating it via 
DrKonqi.

> 3) A global switch for a dependency, like "don't even look for dependency A
> in any of the frameworks" brings nothing IMHO. If it's optional and not
> found, we compile without.

As in my note in (1), I don't think this is something we should be setting, 
but rather than builders should be setting if necessary - CMake provides all 
that infrastructure, so we don't need to do anything (with the exceptional 
case of X11 on Mac, as you noted).

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

Re: Review Request 125673: Remove KNotifications dep from KParts

[David Faure]

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

Ship it!


I'm no big fan of notifications myself (I certainly hate computers making 
sounds on popups -- I guess not everyone has the same opinion), but I put that 
code in because I was basically forking kmessagebox.

Looking at KMessageBox these days, it uses a plugin for the notify stuff. So we 
could either
- just remove this
- or expose KMessageBoxNotifyInterface * notifyInterface() (currently in 
kmessagebox_p.h) for others to use as well.

As you say however, other dialogs which are not messageboxes have no special 
code for notifications, so if one really wanted a notification on each dialog 
they would have to do this more low-level anyway.

So yeah. +2.

- David Faure


On Oct. 17, 2015, 1:23 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125673/
> ---
> 
> (Updated Oct. 17, 2015, 1:23 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kparts
> 
> 
> Description
> ---
> 
> KParts uses KNotification to raise some notification for the open or save 
> dialog.
> Given no other framework beside khtml/plasma uses explicit notifications, I 
> don't see a gain in having this for this one question dialog here, given all 
> other dialogs
> don't do this in all frameworks.
> Will avoid one dependency for all thigs using kparts without a loss of 
> functionality.
> If removing is bad, I can make this optional, but I don't really see the gain 
> in having it.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6abfd4d 
>   src/CMakeLists.txt 530273d 
>   src/browseropenorsavequestion.cpp e1a9f45 
> 
> Diff: https://git.reviewboard.kde.org/r/125673/diff/
> 
> 
> Testing
> ---
> 
> Compiled, worked.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 125673: Remove KNotifications dep from KParts

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 8:46 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit 9d9d34d4eb605b3a0dfdd2e055318a8c31003d3b by Christoph 
Cullmann to branch master.


Repository: kparts


Description
---

KParts uses KNotification to raise some notification for the open or save 
dialog.
Given no other framework beside khtml/plasma uses explicit notifications, I 
don't see a gain in having this for this one question dialog here, given all 
other dialogs
don't do this in all frameworks.
Will avoid one dependency for all thigs using kparts without a loss of 
functionality.
If removing is bad, I can make this optional, but I don't really see the gain 
in having it.


Diffs
-

  CMakeLists.txt 6abfd4d 
  src/CMakeLists.txt 530273d 
  src/browseropenorsavequestion.cpp e1a9f45 

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


Testing
---

Compiled, worked.


Thanks,

Christoph Cullmann

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

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

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/95/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 09:44:27 +
Build duration: 1 min 51 sec

CHANGE SET
Revision 22482e297d6f37a0541ee8de94e58b8aac16742c by David Faure: (autotest: 
use a temp dir rather than a temp file now that the code)
  change: edit autotests/kmimeassociationstest.cpp
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125679: Fix setTranslator example code

[Albert Astals Cid]

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

(Updated Oct. 18, 2015, 8:42 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Michael Pyne.


Changes
---

Submitted with commit df5ef209403866a26f16eeab830c39b57e6a9e0f by Albert Astals 
Cid to branch master.


Repository: kcoreaddons


Description
---

ki18n returns KLocalizedString not a QString.


Diffs
-

  src/lib/kaboutdata.h 134819b 

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


Testing
---


Thanks,

Albert Astals Cid

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

Re: Policy for Dependencies

[Christoph Cullmann]

Hi,

I have now all my patches in frameworks to build some KWrite/Kate application
bundle that doesn't instantly crash (and windows builds seem to be nicer, too,
without that many problems to locate assets).

My last patch missing makes still stuff optional:

https://git.reviewboard.kde.org/r/125616/

Could we come up with some "have a global switch in ECM or not" and if not,
how to do such things?

Greetings
Christoph

- Am 14. Okt 2015 um 16:03 schrieb Alex Merry alex.me...@kde.org:

> On 2015-10-13 16:54, Christoph Cullmann wrote:
>> Hi,
>> 
 I'm not sure whether it's the best solution. The problem you try to
 fix with
 it is distros breaking packaging. I agree with Martin K that this is
 a huge
 problem and that it will happen - since the automation of packages I
 also
 experienced that nobody looks at the output of optional dependencies
 and the
 packaging breaks.
 
 Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES
 switch, but
 rather a mode which will break if not found during distro builds.
 
 Something like a "STRONGLY_RECOMMENDED" which is turned into
 "REQUIRED" if
 distros build (and maybe also kdesrc-build), but is optional if
 anybody else
 builds.
 
 But I'm not sure how this could be done. Anyway, long story short: I
 think we
 need the other way around. It should be optional by default, but
 should be
 turned into stricter requirements on the linux distro case.
>>> I would be happy with such an solution, too.
>>> But I am not that optimistic that this is easy to achieve, how to
>>> ensure all
>>> distros
>>> turn this magic on?
>>> 
>>> The opposite direction at least would avoid the distro breakage and
>>> still allow
>>> optional compiles for the "3rd party wants less dependencies" or
>>> "other platform
>>> wants
>>> less dependencies" use case.
>>> 
>>> Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
>>> still
>>> better than
>>> the current situation, were either we have optional stuff that will
>>> make us
>>> unhappy because
>>> of broken distro packages or the devs unhappy that need to patch
>>> dependencies
>>> out on their own.
>>> 
>>> e.g. Kåre did in most cases exactly that for the Windows build
>>> (g...@git.kde.org:scratch/sars/kate-windows),
>>> which IMHO is sad.
>> 
>> My ECM proposal would be the following:
>> 
>> 1) add to KDECMakeSettings.cmake:
>> 
>>  Dependencies mode 
>> 
>> if(KDE_SKIP_FULL_DEPENDENCIES)
>> unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
>> set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
>> else()
>> set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
>> set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
>> endif()
>> 
>> 2) use that e.g. in knotifications:
>> 
>> find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL}
>> NO_MODULE)
>> set_package_properties(Phonon4Qt5 PROPERTIES
>>DESCRIPTION "Qt-based audio library"
>>TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
>>PURPOSE "Required to build audio notification support")
>> 
>> That would at least make people happy that want no missing features and
>> allow
>> me and others to work on minimizing the dependencies without annoying
>> others.
>> 
>> If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
>> non-distro builds,
>> that could be added later inside KDECMakeSettings.
> 
> I'm not a fan of the variable names - in particular, I think your
> original idea for an option name was better than
> "KDE_SKIP_FULL_DEPENDENCIES" - the existing KDE_SKIP_* variables are
> meant as things project authors define if they only want part of the
> module functionality, rather than as something for users/packagers to
> set. KDE_FIND_REQUIRED_OR_OPTIONAL also tells me essentially nothing
> about *why* it might be REQUIRED or optional when I'm reading the
> source.
> 
> That said, I'm on board with the overall idea.
> 
> Alex
> 
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

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

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/99/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 09:44:27 +
Build duration: 3 min 53 sec

CHANGE SET
Revision 22482e297d6f37a0541ee8de94e58b8aac16742c by David Faure: (autotest: 
use a temp dir rather than a temp file now that the code)
  change: edit autotests/kmimeassociationstest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5626/8186 
(69%)CONDITIONAL 2909/4363 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1453/1551 
(94%)CONDITIONAL 873/1588 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1802/3088 
(58%)CONDITIONAL 755/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2166/2948 
(73%)CONDITIONAL 1196/1540 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog

[Albert Astals Cid]

> On oct. 18, 2015, 6:50 a.m., Thomas Eschenbacher wrote:
> > This should work, but IMHO it does not go far enough. I can see many more 
> > calls to QCoreApplication::translate(...) with user defined content in this 
> > file (kaboutdata.cpp), which is also affected, as for example credits, 
> > authors, copyright statements and so on...
> > 
> > Furthermore feeding in already-translated strings at application start will 
> > break the feature of language switching at run time and it might confuse 
> > the developers who have to pass some strings with I18N_NOOP(), some with 
> > i18n(). I think that "translation on demand" is the right way, we just need 
> > to find a way to make it work.
> > 
> > As I wrote in the corresponding bug report: using gettext() should work for 
> > these use cases, but unfortunately only without context. What about using 
> > the strings like "NAMES OF TRANSLATORS" as message string, without 
> > translation context, and then using some low level API like dcgettext? I 
> > tried that here and it worked fine (using the application name as "domain" 
> > paramter of dcgettext). But that was only a quick experiment, maybe someone 
> > knows a more elegant way to solve this...

What other user defined content do you see in there? everything else i see is 
plain calls with hardcoded strings.

KF5 based apps do not support runtime switching of language at all.

What strings do you have to pass with I18N_NOOP?

You can't use gettext, that's adding a new dependency, and it does not solve 
the problem, the QCoreApplication::translate should basically not be part of 
kcoreaddons, then the problem is gone, you have to feed your translators for 
them to show, and kxmlgui feeds them for you, otherwise you do it manually.


- Albert


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


On oct. 18, 2015, 2:13 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> ---
> 
> (Updated oct. 18, 2015, 2:13 a.m.)
> 
> 
> Review request for KDE Frameworks, Localization and Translation (l10n) and 
> Albert Astals Cid.
> 
> 
> Bugs: 345320
> https://bugs.kde.org/show_bug.cgi?id=345320
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> KAboutData has a placeholder for information regarding who translated the 
> running KDE-based application (KAboutData::translators()). However it relies 
> on the application developer to call KAboutData::setTranslator() since 
> KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt 
> translation infrastructure is used where translations are unavoidable, but 
> that is not compatible with KF5's i18n. This (IIUC) gives different behavior 
> than KDE4, where KAboutData could (and did!) directly pull the translated 
> list of translators, so application authors didn't have to do anything 
> special for their about dialog to have the list of translators.
> 
> For the majority of our applications we can make the ::setTranslator() call 
> on the application developer's behalf, as recommended by Albert on 
> kdeframeworks-devel, and by doing so from KMainWindow (a relatively central 
> location for KF5-using applications) we can use KI18n and get the 
> accurately-translated message. Feeding the already-translated information 
> into KAboutData should work to form the list of translators for later use by 
> KAboutApplicationDialog, or other accessors of that information.
> 
> This patch implements all that. I avoided using a global startup method as 
> suggested by Albert (since the Qt docs suggest that this startup would happen 
> *before* the GUI starts up, and I want to make sure KI18n is available); 
> KMainWindow seems the next best option, and even non-KXmlGuiWindow users 
> might use this. There are probably other good alternatives too (maybe even 
> the platform plugin?).
> 
> 
> Diffs
> -
> 
>   src/kmainwindow.cpp 7c86841 
> 
> Diff: https://git.reviewboard.kde.org/r/125682/diff/
> 
> 
> Testing
> ---
> 
> Compiled, apps all still work.
> 
> I find it hard to test whether the translators actually show up or not 
> though, as I do not use translated KF5 apps.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog

[Albert Astals Cid]

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


Two more things:
 * I think this should only be done if translators() is empty
 * You should document this is going to fill in KAboutData::translators if 
empty with those values

- Albert Astals Cid


On oct. 18, 2015, 2:13 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> ---
> 
> (Updated oct. 18, 2015, 2:13 a.m.)
> 
> 
> Review request for KDE Frameworks, Localization and Translation (l10n) and 
> Albert Astals Cid.
> 
> 
> Bugs: 345320
> https://bugs.kde.org/show_bug.cgi?id=345320
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> KAboutData has a placeholder for information regarding who translated the 
> running KDE-based application (KAboutData::translators()). However it relies 
> on the application developer to call KAboutData::setTranslator() since 
> KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt 
> translation infrastructure is used where translations are unavoidable, but 
> that is not compatible with KF5's i18n. This (IIUC) gives different behavior 
> than KDE4, where KAboutData could (and did!) directly pull the translated 
> list of translators, so application authors didn't have to do anything 
> special for their about dialog to have the list of translators.
> 
> For the majority of our applications we can make the ::setTranslator() call 
> on the application developer's behalf, as recommended by Albert on 
> kdeframeworks-devel, and by doing so from KMainWindow (a relatively central 
> location for KF5-using applications) we can use KI18n and get the 
> accurately-translated message. Feeding the already-translated information 
> into KAboutData should work to form the list of translators for later use by 
> KAboutApplicationDialog, or other accessors of that information.
> 
> This patch implements all that. I avoided using a global startup method as 
> suggested by Albert (since the Qt docs suggest that this startup would happen 
> *before* the GUI starts up, and I want to make sure KI18n is available); 
> KMainWindow seems the next best option, and even non-KXmlGuiWindow users 
> might use this. There are probably other good alternatives too (maybe even 
> the platform plugin?).
> 
> 
> Diffs
> -
> 
>   src/kmainwindow.cpp 7c86841 
> 
> Diff: https://git.reviewboard.kde.org/r/125682/diff/
> 
> 
> Testing
> ---
> 
> Compiled, apps all still work.
> 
> I find it hard to test whether the translators actually show up or not 
> though, as I do not use translated KF5 apps.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog

[Thomas Eschenbacher]

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


This should work, but IMHO it does not go far enough. I can see many more calls 
to QCoreApplication::translate(...) with user defined content in this file 
(kaboutdata.cpp), which is also affected, as for example credits, authors, 
copyright statements and so on...

Furthermore feeding in already-translated strings at application start will 
break the feature of language switching at run time and it might confuse the 
developers who have to pass some strings with I18N_NOOP(), some with i18n(). I 
think that "translation on demand" is the right way, we just need to find a way 
to make it work.

As I wrote in the corresponding bug report: using gettext() should work for 
these use cases, but unfortunately only without context. What about using the 
strings like "NAMES OF TRANSLATORS" as message string, without translation 
context, and then using some low level API like dcgettext? I tried that here 
and it worked fine (using the application name as "domain" paramter of 
dcgettext). But that was only a quick experiment, maybe someone knows a more 
elegant way to solve this...

- Thomas Eschenbacher


On Okt. 18, 2015, 2:13 vorm., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> ---
> 
> (Updated Okt. 18, 2015, 2:13 vorm.)
> 
> 
> Review request for KDE Frameworks, Localization and Translation (l10n) and 
> Albert Astals Cid.
> 
> 
> Bugs: 345320
> https://bugs.kde.org/show_bug.cgi?id=345320
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> KAboutData has a placeholder for information regarding who translated the 
> running KDE-based application (KAboutData::translators()). However it relies 
> on the application developer to call KAboutData::setTranslator() since 
> KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt 
> translation infrastructure is used where translations are unavoidable, but 
> that is not compatible with KF5's i18n. This (IIUC) gives different behavior 
> than KDE4, where KAboutData could (and did!) directly pull the translated 
> list of translators, so application authors didn't have to do anything 
> special for their about dialog to have the list of translators.
> 
> For the majority of our applications we can make the ::setTranslator() call 
> on the application developer's behalf, as recommended by Albert on 
> kdeframeworks-devel, and by doing so from KMainWindow (a relatively central 
> location for KF5-using applications) we can use KI18n and get the 
> accurately-translated message. Feeding the already-translated information 
> into KAboutData should work to form the list of translators for later use by 
> KAboutApplicationDialog, or other accessors of that information.
> 
> This patch implements all that. I avoided using a global startup method as 
> suggested by Albert (since the Qt docs suggest that this startup would happen 
> *before* the GUI starts up, and I want to make sure KI18n is available); 
> KMainWindow seems the next best option, and even non-KXmlGuiWindow users 
> might use this. There are probably other good alternatives too (maybe even 
> the platform plugin?).
> 
> 
> Diffs
> -
> 
>   src/kmainwindow.cpp 7c86841 
> 
> Diff: https://git.reviewboard.kde.org/r/125682/diff/
> 
> 
> Testing
> ---
> 
> Compiled, apps all still work.
> 
> I find it hard to test whether the translators actually show up or not 
> though, as I do not use translated KF5 apps.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 125682: Pre-fill translator information for KAboutApplicationDialog

[Albert Astals Cid]

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



src/kmainwindow.cpp (line 209)


This is not going to work, you need to undefine TRANSLATION_DOMAIN include 
klocalizedstring again and then call this i18nc so it gets it from the "global" 
(i.e. the app) catalog and not from the kxmlgui5 catalog


- Albert Astals Cid


On oct. 18, 2015, 2:13 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125682/
> ---
> 
> (Updated oct. 18, 2015, 2:13 a.m.)
> 
> 
> Review request for KDE Frameworks, Localization and Translation (l10n) and 
> Albert Astals Cid.
> 
> 
> Bugs: 345320
> https://bugs.kde.org/show_bug.cgi?id=345320
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> KAboutData has a placeholder for information regarding who translated the 
> running KDE-based application (KAboutData::translators()). However it relies 
> on the application developer to call KAboutData::setTranslator() since 
> KCoreAddons (a Tier 1 framework) cannot use KI18n directly. Instead the Qt 
> translation infrastructure is used where translations are unavoidable, but 
> that is not compatible with KF5's i18n. This (IIUC) gives different behavior 
> than KDE4, where KAboutData could (and did!) directly pull the translated 
> list of translators, so application authors didn't have to do anything 
> special for their about dialog to have the list of translators.
> 
> For the majority of our applications we can make the ::setTranslator() call 
> on the application developer's behalf, as recommended by Albert on 
> kdeframeworks-devel, and by doing so from KMainWindow (a relatively central 
> location for KF5-using applications) we can use KI18n and get the 
> accurately-translated message. Feeding the already-translated information 
> into KAboutData should work to form the list of translators for later use by 
> KAboutApplicationDialog, or other accessors of that information.
> 
> This patch implements all that. I avoided using a global startup method as 
> suggested by Albert (since the Qt docs suggest that this startup would happen 
> *before* the GUI starts up, and I want to make sure KI18n is available); 
> KMainWindow seems the next best option, and even non-KXmlGuiWindow users 
> might use this. There are probably other good alternatives too (maybe even 
> the platform plugin?).
> 
> 
> Diffs
> -
> 
>   src/kmainwindow.cpp 7c86841 
> 
> Diff: https://git.reviewboard.kde.org/r/125682/diff/
> 
> 
> Testing
> ---
> 
> Compiled, apps all still work.
> 
> I find it hard to test whether the translators actually show up or not 
> though, as I do not use translated KF5 apps.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Review Request 125615: Make phonon dependency optional

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 8:50 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Sune Vuorela.


Changes
---

Submitted with commit 0c0cb0ab8119b399ef21c601990bc294d5dd84bc by Christoph 
Cullmann to branch master.


Repository: knotifications


Description
---

Make phonon dependency optional, purely internal change, like it is done for 
speech.


Diffs
-

  CMakeLists.txt 5a4ec83 
  src/CMakeLists.txt 2a88b5a 
  src/knotificationmanager.cpp 1c392b4 

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


Testing
---

Still builds with (and now even without) phonon here.


Thanks,

Christoph Cullmann

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

Re: Review Request 125616: Make doctools + wallet optional

[David Faure]

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



src/kpasswdserver/CMakeLists.txt (line 9)


I think it would make more sense to have ifdef HAVE_KWALLET in 
kpasswdserver.cpp, because kpasswdserver is useful even without kwallet: it 
stores (http) passwords in memory while it's running, which allows to avoid 
typing the same password 1000 times when browsing an HTTP site with auth.

KWallet allows to store that to disk so it's remembered after a reboot, but 
that's just a bonus. The primary function of kpasswdserver is the in-memory 
storage.


- David Faure


On Oct. 17, 2015, 12:04 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125616/
> ---
> 
> (Updated Oct. 17, 2015, 12:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Make doctools + wallet optional.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt cfea7b2 
>   src/ioslaves/help/CMakeLists.txt 3f07f31 
>   src/kpasswdserver/CMakeLists.txt c9f49a5 
> 
> Diff: https://git.reviewboard.kde.org/r/125616/diff/
> 
> 
> Testing
> ---
> 
> Still compiles all stuff if all deps are around
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 125640: Remove special handling when service is already registered

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Oct. 14, 2015, 8:04 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125640/
> ---
> 
> (Updated Oct. 14, 2015, 8:04 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> As pointed out in https://git.reviewboard.kde.org/r/125483/ the special 
> handling is useless here. If the service is registered, it will call Activate 
> and KDBusService will just exit, even with the NoExitOnFailure flag; it would 
> never reach the "if (!dbusUniqueInstance.isRegistered()) {".
> 
> Furthermore, without the NoExitOnFailure flag, it would exit right from 
> KDBusService, rendering this whole if-block kinda useless.
> 
> 
> Diffs
> -
> 
>   src/runtime/kwalletd/main.cpp fbab58d 
> 
> Diff: https://git.reviewboard.kde.org/r/125640/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 125621: Missing color initialization in KNewPasswordWidget

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Oct. 13, 2015, 1:47 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125621/
> ---
> 
> (Updated Oct. 13, 2015, 1:47 p.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Feck.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> While working on RR [125619](https://git.reviewboard.kde.org/r/125619/) I 
> discovered a missing initialization in KNewPasswordWidget.
> We need to initialize the "warning color" to the default background color, 
> otherwise if `setBackgroundWarningColor()` is not called, that color will be 
> black.
> 
> 
> Diffs
> -
> 
>   src/knewpasswordwidget.cpp 215cd206962dc57d0d05366e66d1729b45e7d956 
> 
> Diff: https://git.reviewboard.kde.org/r/125621/diff/
> 
> 
> Testing
> ---
> 
> Showing a KNewPasswordWidget, without calling `setBackgroundWarningColor()`, 
> does not show a black "warning color" anymore.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 125616: Make doctools + wallet optional

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 12:30 p.m.)


Status
--

This change has been marked as submitted.


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


Changes
---

Submitted with commit 9861d5de30c0da09de8bd50407f154f1a6c1f171 by Christoph 
Cullmann to branch master.


Repository: kio


Description
---

Make doctools + wallet optional.


Diffs
-

  CMakeLists.txt cfea7b2 
  src/ioslaves/help/CMakeLists.txt 3f07f31 
  src/kpasswdserver/CMakeLists.txt c9f49a5 
  src/kpasswdserver/kpasswdserver.h 9dc56ce 
  src/kpasswdserver/kpasswdserver.cpp 24a3a17 

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


Testing
---

Still compiles all stuff if all deps are around


Thanks,

Christoph Cullmann

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

Re: Review Request 125616: Make doctools + wallet optional

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 12:30 p.m.)


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


Repository: kio


Description
---

Make doctools + wallet optional.


Diffs (updated)
-

  CMakeLists.txt cfea7b2 
  src/ioslaves/help/CMakeLists.txt 3f07f31 
  src/kpasswdserver/CMakeLists.txt c9f49a5 
  src/kpasswdserver/kpasswdserver.h 9dc56ce 
  src/kpasswdserver/kpasswdserver.cpp 24a3a17 

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


Testing
---

Still compiles all stuff if all deps are around


Thanks,

Christoph Cullmann

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

Re: Policy for Dependencies

[David Faure]

On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote:
> 
> Lets see what David thinks about all that.

First: thanks everyone for waiting for my input, I appreciate that (I'm just 
one more voice though, no dictatorship here).

The various global switches that have been suggested had unintuitive naming, so 
I will describe
my thinking about them by using descriptions instead of actual names:

1) A global switch "skip anything marked as optional" would be a very bad idea, 
it would even skip stuff that *is* available.
I *think* this wasn't suggested, but I wanted to mention it just in case.

2) A global switch "everything that can be optional, is now optional" sounds 
strange to me too. If it's optional, it's optional.
(The description for the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this 
might lead to a loss of functionality".
Well, that is *always* true when an optional dependency isn't found - otherwise 
it would be useless).
Really, is there any sense in saying that a dependency is optionally optional? 
:-P

2.1) I can see how the purpose was to let the default build be "with as many 
dependencies as possible".
But for that maybe we can have a global switch for "fail if something optional 
was not found", for distros (and CI) to make sure they have *everything* 
enabled.
Would this actually work for distro packagers? Do they have *all* the 
dependencies available?

The discussion on 2) vs 2.1) is almost like discussing the default value of the 
same option,
except that with 2) every framework would still be able to have 
always-required, required-or-optional, and always-optional dependencies.
You could say that's extremely flexible, on the other hand I wonder if it's not 
too much choice (i.e. too much complexity).
E.g. the kwallet dependency in KIO now is optional, therefore it's optional, 
end of story. Yet we don't want distros compiling KIO without KWallet,
but aren't we optimizing for the wrong thing? I mean, I didn't hear about KF5 
packages being wrong because of missing deps
(i.e. if it happened, it must have been fixed pretty quickly). So unless 
someone proves the contrary to me, I would say this whole
2/2.1 discussion is moot, the tools that we have (to express optional 
dependencies) do work, we just need to work towards
making more stuff optional, like Christoph is doing.

An argument was made that optional deps create more work for maintainers, who 
can't know, in bug reports,
whether the dep was enabled or disabled (i.e. more configurations to handle). 
That is true. The solution isn't however
to make everything mandatory. So we should solve this, after accepting the 
existence of optional deps. One random idea
could be (automatically) installing a file, from each framework, with the list 
of optional deps that were found. Then
when handling bug reports you can ask for that file -- or drkonqi could grab 
them all and concatenate them in a readable way.

3) A global switch for a dependency, like "don't even look for dependency A in 
any of the frameworks" brings nothing IMHO.
If it's optional and not found, we compile without.

3.1) As a special case of that, I do however see the usefulness of "don't even 
look for X11" as a global switch, because of the OSX case where
it might be lying around and we don't want to use it. It's a special case 
because it's an exclusive switch (AFAIK you either use cocoa or X11, not both),
unlike most of our other dependencies.
3.2) More generally *if* distributors want a way to express "don't even look 
for dependency A, because I might have it installed
but I don't want my packages to depend on it", then I have nothing against 
that. And then the X11 case can be just one instance of that.

I'm not replying here to the part of the thread around packaging for Windows 
and Mac, that's a separate discussion.
I note, however, that Christoph's patches which make more use of .qrc files, 
are the best way to solve some of these issues.

-- 
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 125621: Missing color initialization in KNewPasswordWidget

[Elvis Angelaccio]

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

(Updated Oct. 18, 2015, 12:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Feck.


Changes
---

Submitted with commit f6fda56adc16745154c05f8a9d824f305a299f92 by Elvis 
Angelaccio to branch master.


Repository: kwidgetsaddons


Description
---

While working on RR [125619](https://git.reviewboard.kde.org/r/125619/) I 
discovered a missing initialization in KNewPasswordWidget.
We need to initialize the "warning color" to the default background color, 
otherwise if `setBackgroundWarningColor()` is not called, that color will be 
black.


Diffs
-

  src/knewpasswordwidget.cpp 215cd206962dc57d0d05366e66d1729b45e7d956 

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


Testing
---

Showing a KNewPasswordWidget, without calling `setBackgroundWarningColor()`, 
does not show a black "warning color" anymore.


Thanks,

Elvis Angelaccio

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

Re: Review Request 125616: Make doctools + wallet optional

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 10:43 a.m.)


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


Repository: kio


Description
---

Make doctools + wallet optional.


Diffs (updated)
-

  CMakeLists.txt cfea7b2 
  src/ioslaves/help/CMakeLists.txt 3f07f31 
  src/kpasswdserver/CMakeLists.txt c9f49a5 
  src/kpasswdserver/kpasswdserver.h 9dc56ce 
  src/kpasswdserver/kpasswdserver.cpp 24a3a17 

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


Testing
---

Still compiles all stuff if all deps are around


Thanks,

Christoph Cullmann

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

Re: Review Request 125616: Make doctools + wallet optional

[David Faure]

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

Ship it!



src/kpasswdserver/kpasswdserver.cpp (line 814)


you could also just move down this line into the next #ifdef block, to 
merge them.


- David Faure


On Oct. 18, 2015, 10:43 a.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125616/
> ---
> 
> (Updated Oct. 18, 2015, 10:43 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Make doctools + wallet optional.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt cfea7b2 
>   src/ioslaves/help/CMakeLists.txt 3f07f31 
>   src/kpasswdserver/CMakeLists.txt c9f49a5 
>   src/kpasswdserver/kpasswdserver.h 9dc56ce 
>   src/kpasswdserver/kpasswdserver.cpp 24a3a17 
> 
> Diff: https://git.reviewboard.kde.org/r/125616/diff/
> 
> 
> Testing
> ---
> 
> Still compiles all stuff if all deps are around
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 125619: Refactor KNewPasswordDialog class

[Elvis Angelaccio]

> On Oct. 13, 2015, 1:33 p.m., Aleix Pol Gonzalez wrote:
> > File Attachment: knewpassworddialog4.png - knewpassworddialog4.png
> > 
> >
> > Shouldn't it have a red background when empty as well?
> 
> Elvis Angelaccio wrote:
> I'm not sure honestly. Wouldn't be a little weird to have a red 
> background there and a white one below in the verification field?
> Actually your question makes me wonder another thing: should we hide the 
> verification field initially? Would make sense to show it only after the user 
> starts typing the password?
> 
> What the usability guys think?
> 
> Thomas Pfeiffer wrote:
> The background should not be red before the user even started typing. Red 
> indicates something is wrong, but the field being empty before the user 
> started typing is perfectly fine.
> It should only be red if the user clears the field again after having 
> typed, with the message "Password cannot be empty"

> The background should not be red before the user even started typing. Red 
> indicates something is wrong, but the field being empty before the user 
> started typing is perfectly fine.
It should only be red if the user clears the field again after having typed, 
with the message "Password cannot be empty"

I agree, but probably it's better to implement this in a separate patch. There 
are already enough changes here, we have to be sure first that this patch does 
not introduce regressions in KNewPasswordDialog.


- Elvis


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


On Oct. 13, 2015, 1:33 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125619/
> ---
> 
> (Updated Oct. 13, 2015, 1:33 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability, Christoph Feck, and David 
> Faure.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> Follow-up of the KNewPasswordWidget review.
> By introducing a KNewPasswordWidget in the .ui file, we can:
> 
> - remove the code that has been moved to KNewPasswordWidget
> - enable the KNewPasswordWidget additional features
> 
> The only feature that is currently not available is the ability to remove the 
> strength bar. Do we want to allow developers to show a KNewPasswordDialog 
> without a strenght bar?
> 
> 
> Diffs
> -
> 
>   src/knewpassworddialog.h 1ac7b2151f1e88681a15ce21465449cedb871f1e 
>   src/knewpassworddialog.cpp bd7459acf3c72bc6dc0711da6086213d5111d5c3 
>   src/knewpassworddialog.ui 55a1f62cf4ba6d6c87b2c47742ba3bcd531ebfe8 
> 
> Diff: https://git.reviewboard.kde.org/r/125619/diff/
> 
> 
> Testing
> ---
> 
> Trying to insert a password which is too short or too weak or empty, works as 
> expected.
> 
> 
> File Attachments
> 
> 
> knewpassworddialog1.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/62bf21f6-1dcf-46c3-8b1d-146500b5f629__knewpassworddialog1.png
> knewpassworddialog2.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b2e2666f-ce19-4df3-b6ba-25c13fc370ae__knewpassworddialog2.png
> knewpassworddialog3.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/b9536088-0cc4-470b-a211-6db4ca79aa2f__knewpassworddialog3.png
> knewpassworddialog4.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/10/13/4f826716-9ed2-4ecb-8cbe-4fb50abf1086__knewpassworddialog4.png
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Review Request 125688: Make KNotifications dep in KIO (kpac) optional

[Christoph Cullmann]

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

Review request for KDE Frameworks and David Faure.


Repository: kio


Description
---

Make KNotifications dep in KIO (kpac) optional.

I am not sure if the notifications are at all very useful, given the user won't 
understand what they are about in 99% of the cases.


Diffs
-

  src/kpac/CMakeLists.txt fc6043f 
  src/kpac/proxyscout.cpp 972dde2 

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


Testing
---

Compiles and run with and without the dep around.
Missed this dep. first as it is only for this subtool :(


Thanks,

Christoph Cullmann

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

Re: Review Request 125616: Make doctools + wallet optional

[Christoph Cullmann]

> On Oct. 18, 2015, 9:49 a.m., David Faure wrote:
> > src/kpasswdserver/CMakeLists.txt, line 9
> > 
> >
> > I think it would make more sense to have ifdef HAVE_KWALLET in 
> > kpasswdserver.cpp, because kpasswdserver is useful even without kwallet: it 
> > stores (http) passwords in memory while it's running, which allows to avoid 
> > typing the same password 1000 times when browsing an HTTP site with auth.
> > 
> > KWallet allows to store that to disk so it's remembered after a reboot, 
> > but that's just a bonus. The primary function of kpasswdserver is the 
> > in-memory storage.

Ok, true, will change that!


- Christoph


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


On Oct. 17, 2015, 12:04 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125616/
> ---
> 
> (Updated Oct. 17, 2015, 12:04 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Make doctools + wallet optional.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt cfea7b2 
>   src/ioslaves/help/CMakeLists.txt 3f07f31 
>   src/kpasswdserver/CMakeLists.txt c9f49a5 
> 
> Diff: https://git.reviewboard.kde.org/r/125616/diff/
> 
> 
> Testing
> ---
> 
> Still compiles all stuff if all deps are around
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 123376: Fix handling of mod-shift-number shortcuts.

[Yuxuan Shui]

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

(Updated Okt. 18, 2015, 2:02 nachm.)


Status
--

This change has been discarded.


Review request for KDE Frameworks, Martin Gräßlin and Thomas Lübking.


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


Repository: kglobalaccel


Description
---

For details, see discussion in corresponding bug report.


Diffs
-

  src/runtime/kglobalaccel_x11.cpp abee5bc 

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


Testing
---


Thanks,

Yuxuan Shui

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

Re: Review Request 125658: Do not treat the context menu button as modifier

[Thomas Lübking]

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

(Updated Okt. 18, 2015, 2:45 nachm.)


Review request for KDE Frameworks, Christoph Feck and Hans Chen.


Changes
---

getting a bit more audience for comments ;-)


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


Repository: kxmlgui


Description
---

It's not and not treated as such by Qt either.

In addition suck context events while recording
(so it doesn't activate, rather cosmetic)

BUG: 165542
FIXED-IN: 5.16
CHANGELOG: Allow to bind the contextmenu key (lower right) to shortcuts


Diffs
-

  src/kkeysequencewidget.cpp 2385f20 

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


Testing
---

yupp.


Thanks,

Thomas Lübking

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

Re: Review Request 125688: Make KNotifications dep in KIO (kpac) optional

[David Faure]

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

Ship it!


Well, I think the notification that your access to the internet (via a proxy) 
is broken is useful (and this only happens for users in an environment where 
their sysadmin told them to set up a specific URL as proxy script; so with the 
notification they can relay the error to their sysadmin).

So I agree with making this optional, but not really with the commit log.

- David Faure


On Oct. 18, 2015, 1:09 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125688/
> ---
> 
> (Updated Oct. 18, 2015, 1:09 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Make KNotifications dep in KIO (kpac) optional.
> 
> I am not sure if the notifications are at all very useful, given the user 
> won't understand what they are about in 99% of the cases.
> 
> 
> Diffs
> -
> 
>   src/kpac/CMakeLists.txt fc6043f 
>   src/kpac/proxyscout.cpp 972dde2 
> 
> Diff: https://git.reviewboard.kde.org/r/125688/diff/
> 
> 
> Testing
> ---
> 
> Compiles and run with and without the dep around.
> Missed this dep. first as it is only for this subtool :(
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

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

[David Rosca]

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

Review request for KDE Frameworks.


Repository: kio


Description
---

If qMimeType is empty, addToMimeAppsList shouldn't be called.


Diffs
-

  src/widgets/kopenwithdialog.cpp c60a193 

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


Testing
---

opening new KOpenWithDialog() without mimeType and typing eg "dolphin" to exec 
line now correctly returns valid KService.


Thanks,

David Rosca

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

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 96 - Still unstable!

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/96/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 18:08:48 +
Build duration: 1 min 58 sec

CHANGE SET
Revision 9fb23b0359fa2436cba04091bbd649f309412f7d by Albert Astals Cid: 
(Compile++)
  change: edit autotests/kmimeassociationstest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5621/8186 
(69%)CONDITIONAL 2907/4359 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1453/1551 
(94%)CONDITIONAL 875/1588 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1803/3088 
(58%)CONDITIONAL 755/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2160/2948 
(73%)CONDITIONAL 1192/1536 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125688: Make KNotifications dep in KIO (kpac) optional

[Christoph Cullmann]

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

(Updated Oct. 18, 2015, 4:59 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and David Faure.


Changes
---

Submitted with commit d3164ae9832bef4a9768ff8c388eda92af51a039 by Christoph 
Cullmann to branch master.


Repository: kio


Description
---

Make KNotifications dep in KIO (kpac) optional.

I am not sure if the notifications are at all very useful, given the user won't 
understand what they are about in 99% of the cases.


Diffs
-

  src/kpac/CMakeLists.txt fc6043f 
  src/kpac/proxyscout.cpp 972dde2 

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


Testing
---

Compiles and run with and without the dep around.
Missed this dep. first as it is only for this subtool :(


Thanks,

Christoph Cullmann

___
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 # 100 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/100/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 18:08:48 +
Build duration: 4 min 29 sec

CHANGE SET
Revision 9fb23b0359fa2436cba04091bbd649f309412f7d by Albert Astals Cid: 
(Compile++)
  change: edit autotests/kmimeassociationstest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5598/8187 
(68%)CONDITIONAL 2912/4365 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1427/1551 
(92%)CONDITIONAL 881/1594 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1802/3088 
(58%)CONDITIONAL 755/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2164/2949 
(73%)CONDITIONAL 1191/1536 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kservice%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/100/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 18 Oct 2015 18:08:48 +
Build duration: 4 min 29 sec

CHANGE SET
Revision 9fb23b0359fa2436cba04091bbd649f309412f7d by Albert Astals Cid: 
(Compile++)
  change: edit autotests/kmimeassociationstest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 74/83 (89%)CLASSES 74/83 (89%)LINE 5598/8187 
(68%)CONDITIONAL 2912/4365 (67%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1427/1551 
(92%)CONDITIONAL 881/1594 (55%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/53 (89%)CONDITIONAL 
15/18 (83%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/324 (0%)CONDITIONAL 0/0 
(100%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 48/101 (48%)CONDITIONAL 
36/54 (67%)
src.services
FILES 28/29 (97%)CLASSES 28/29 (97%)LINE 1802/3088 
(58%)CONDITIONAL 755/1117 (68%)
src.sycoca
FILES 27/32 (84%)CLASSES 27/32 (84%)LINE 2164/2949 
(73%)CONDITIONAL 1191/1536 (78%)
tests.pluginlocator
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 110/121 (91%)CONDITIONAL 
34/46 (74%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel