KDE CI: Frameworks kcoreaddons kf5-qt5 SUSEQt5.10 - Build # 87 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kcoreaddons%20kf5-qt5%20SUSEQt5.10/87/
 Project:
Frameworks kcoreaddons kf5-qt5 SUSEQt5.10
 Date of build:
Fri, 29 Jun 2018 06:09:26 +
 Build duration:
6 min 2 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 22 test(s), Skipped: 0 test(s), Total: 24 test(s)Failed: TestSuite.kdirwatch_qfswatch_unittestFailed: TestSuite.kdirwatch_stat_unittest
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report91%
(10/11)85%
(69/81)85%
(69/81)75%
(6241/8332)43%
(10019/23183)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests93%
(26/28)93%
(26/28)97%
(2667/2741)49%
(5725/11731)src.desktoptojson100%
(2/2)100%
(2/2)78%
(88/113)38%
(123/326)src.lib50%
(1/2)50%
(1/2)61%
(351/572)26%
(243/928)src.lib.caching100%
(2/2)100%
(2/2)45%
(354/782)18%
(184/1038)src.lib.io82%
(9/11)82%
(9/11)68%
(854/1265)37%
(1047/2821)src.lib.jobs71%
(5/7)71%
(5/7)57%
(160/281)38%
(52/138)src.lib.plugin100%
(7/7)100%
(7/7)85%
(652/767)42%
(968/2305)src.lib.randomness100%
(2/2)100%
(2/2)70%
(67/96)58%
(44/76)src.lib.text63%
(5/8)63%
(5/8)47%
(368/778)45%
(846/1899)src.lib.util100%
(10/10)100%
(10/10)80%
(680/852)52%
(787/1523)tests0%
(0/2)0%
(0/2)0%
(0/85)0%
(0/398)

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham added a comment.


  Lol!

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid, cfeck
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Christoph Feck]

cfeck added a comment.


  too late ;)

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid, cfeck
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham closed this revision.

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid, cfeck
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Christoph Feck]

cfeck edited the summary of this revision.

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid, cfeck
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Christoph Feck]

cfeck accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R267 Oxygen Icons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid, cfeck
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham updated this revision to Diff 36863.
ngraham added a comment.


  Also do 48x48

REPOSITORY
  R267 Oxygen Icons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13786?vs=36859&id=36863

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13786

AFFECTED FILES
  16x16/actions/visibility.png
  22x22/actions/visibility.png
  32x32/actions/visibility.png
  48x48/actions/visibility.png

To: ngraham, #dolphin, aacid
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham added a comment.


  Oops, missed that one!

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Christoph Feck]

cfeck added a comment.


  I think we also use 48x48 for actions.

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Christoph Feck]

cfeck added a comment.


  I like the refactoring, much easier to read.
  
  I have to agree with Nathan that the special casing for the alpha is 
unneeded. For users having a black selection color, it wouldn't tint at all.
  
  We deliberately used a small blending value (0.2) to make sure the resulting 
color is not too different from the standard window background color.

INLINE COMMENTS

> kmessagewidget.cpp:266
> +value.setRgb(rgb.at(0).toInt(), rgb.at(1).toInt(), 
> rgb.at(2).toInt());
> +} else if (rgb.size() >= 3) {
> +value.setRgb(rgb.at(0).toInt(), rgb.at(1).toInt(), 
> rgb.at(2).toInt(), rgb.at(3).toInt());

`>= 4`

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13787: CoffeeScript & JavaScript: fix member objects. Add .ts extension in JS

[Nibaldo González]

nibags edited the summary of this revision.
nibags added reviewers: dhaumann, cullmann.
nibags added a project: Framework: Syntax Highlighting.
nibags edited subscribers, added: Framework: Syntax Highlighting; removed: 
kde-frameworks-devel.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D13787

To: nibags, dhaumann, cullmann
Cc: #framework_syntax_highlighting, michaelh, genethomas, ngraham, bruns, 
cullmann, vkrause, dhaumann, kde-frameworks-devel

D13787: CoffeeScript & JavaScript: fix member objects. Add .ts extension in JS

[Nibaldo González]

nibags created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
nibags requested review of this revision.

REVISION SUMMARY
  **CoffeeScript**
  
  - Fix [bug #394365](URL "https://bugs.kde.org/show_bug.cgi?id=394365";):
  
  **Bug:** Identifiers with member objects are not highlighted. For example, 
when writing `timelineEvent.class`, `class` is highlighted as a Keyword, which 
sends a new context, showing an incorrect highlighting.
  
  **Solution:** Add a rule to detect identifiers of the type: 
`iden1.iden2.iden3`. The first word after a "." is highlighted as an 
identifier. However, the first word before a "." can be a keyword (as 
"globals").
  
  **JavaScript**
  
  - Fix [bug #366797](URL "https://bugs.kde.org/show_bug.cgi?id=366797";):
  
  **Bug:** When writing member objects (`iten1.iden2.iden3`), all text are 
highlighted after ".", including spaces. For example, `instanceof` and `Number` 
are highlighted as `Object Member`.
  
object.property instanceof Number;
  
  **Solution:** Only the first word after `.` is highlighted as `Object member`.
  
  - Fix small bug in Shebang: multiple lines can be highlighted as Shebang 
(only the first line is considered Shebang).
  
  Example:
  
#! shebang1
#! shebang2
#! shebang3
...
  
  **Others:**
  
  - CoffeeScript: Add mimetype `application/vnd.coffeescript`: 
http://dcjtech.info/topic/coffeescript-mimetype/
  
  - JavaScript: Add extension `*.ts` of TypeScript. TypeScript is a superset of 
JavaScript, therefore, the syntax highlighting is the same, except for some 
features that aren't in the JavaScript highlighter. Therefore, this may be 
temporary as long as there isn't a TypeScript highlighting file.
- https://bugs.kde.org/show_bug.cgi?id=384716
  
  I also added a test file for CoffeeScript.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  fix-js-coffee

REVISION DETAIL
  https://phabricator.kde.org/D13787

AFFECTED FILES
  autotests/folding/test.coffee.fold
  autotests/folding/test.js.fold
  autotests/html/test.coffee.html
  autotests/html/test.js.html
  autotests/input/test.coffee
  autotests/input/test.js
  autotests/reference/test.coffee.ref
  autotests/reference/test.js.ref
  data/syntax/coffee.xml
  data/syntax/javascript.xml

To: nibags
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham edited the test plan for this revision.

REPOSITORY
  R267 Oxygen Icons

REVISION DETAIL
  https://phabricator.kde.org/D13786

To: ngraham, #dolphin, aacid
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13786: Show an icon for hidden files in Dolphin

[Nathaniel Graham]

ngraham created this revision.
ngraham added reviewers: Dolphin, aacid.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
ngraham requested review of this revision.

REVISION SUMMARY
  Dolphin uses the `hint` icon for invisible hidden files and the `visibility` 
icon for shown hidden files.
  
  Everything works fine with Breeze icons, but with Oxygen, there is no 
`visibility` icon. The `hint` icon is symlinked to something appropriate, so 
this patch just symlinks `visibility` to the its companion icon.
  
  BUG: 395963
  FIXED-IN 5.48

TEST PLAN
  [video goes here]

REPOSITORY
  R267 Oxygen Icons

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13786

AFFECTED FILES
  16x16/actions/visibility.png
  22x22/actions/visibility.png
  32x32/actions/visibility.png

To: ngraham, #dolphin, aacid
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D10663: Remove a partially copied file if copyjob was cancelled in the middle of file copying

[Dmitri Ovodok]

dmitrio abandoned this revision.
dmitrio added a comment.


  No, didn't work on that, sorry. I think I am better to close the revision.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D10663

To: dmitrio, #frameworks, dfaure, ngraham
Cc: kde-frameworks-devel, elvisangelaccio, ngraham, anthonyfieroni, meven, 
#frameworks, michaelh, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb set the repository for this revision to R236 KWidgetsAddons.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb updated this revision to Diff 36858.
rjvbb added a comment.


  The need for an extra check in `qColorFromSettings()` meant I changed the API 
to put all tests in there and added a default return value argument. IOW, 
basically the same API as KConfig has.
  
  I've simplified the information alpha calculation, now looking only at the 
message background colour intensity. I think that should address the issue with 
dark themes.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13777?vs=36846&id=36858

REVISION DETAIL
  https://phabricator.kde.org/D13777

AFFECTED FILES
  src/kmessagewidget.cpp

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Christoph Feck]

cfeck added inline comments.

INLINE COMMENTS

> kmessagewidget.cpp:263
> +QStringList rgb = settings->value(key).toStringList();
> +return QColor(rgb.at(0).toInt(), rgb.at(1).toInt(), rgb.at(2).toInt());
> +}

missing `if (rgb.size() >= 3)`

> kmessagewidget.cpp:281
> +const QString themeGroup = QStringLiteral("Colors:Window");
> +QSettings *settings = !kdeGlobals.isEmpty()? new QSettings(kdeGlobals, 
> QSettings::IniFormat) : nullptr;
> +if (settings && settings->childGroups().contains(themeGroup)) {

missing space before `?`

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13732: Add debug output for all network requests

[Ralf Habacker]

This revision was automatically updated to reflect the committed changes.
Closed by commit R235:65731a8f8ade: Add debug output for all network requests 
(authored by habacker).

REPOSITORY
  R235 Attica

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13732?vs=36848&id=36850

REVISION DETAIL
  https://phabricator.kde.org/D13732

AFFECTED FILES
  autotests/providertest.cpp
  src/atticabasejob.cpp
  src/atticautils.cpp
  src/atticautils.h
  src/getjob.cpp
  src/providermanager.cpp

To: habacker, leinir
Cc: ltoscano, bruns, kde-frameworks-devel, michaelh, ngraham

D13732: Add debug output for all network requests

[Dan Leinir Turthra Jensen]

leinir accepted this revision.
leinir added a comment.
This revision is now accepted and ready to land.


  Sorted! Good digging, nice work :)

REPOSITORY
  R235 Attica

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13732

To: habacker, leinir
Cc: ltoscano, bruns, kde-frameworks-devel, michaelh, ngraham

D13732: Add debug output for all network requests

[Ralf Habacker]

habacker updated this revision to Diff 36848.
habacker added a comment.


  - use qcDebug
  - enable debug display in providertest

REPOSITORY
  R235 Attica

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13732?vs=36667&id=36848

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D13732

AFFECTED FILES
  autotests/providertest.cpp
  src/atticabasejob.cpp
  src/atticautils.cpp
  src/atticautils.h
  src/getjob.cpp
  src/providermanager.cpp

To: habacker, leinir
Cc: ltoscano, bruns, kde-frameworks-devel, michaelh, ngraham

KDE CI: Frameworks syntax-highlighting kf5-qt5 SUSEQt5.10 - Build # 101 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20syntax-highlighting%20kf5-qt5%20SUSEQt5.10/101/
 Project:
Frameworks syntax-highlighting kf5-qt5 SUSEQt5.10
 Date of build:
Thu, 28 Jun 2018 17:48:39 +
 Build duration:
4 min 55 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 9 test(s)Failed: TestSuite.htmlhighlighter_testFailed: TestSuite.testhighlighter_test
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report60%
(3/5)82%
(27/33)82%
(27/33)79%
(2274/2891)68%
(1564/2301)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(8/8)100%
(8/8)97%
(499/512)63%
(245/388)examples0%
(0/2)0%
(0/2)0%
(0/197)0%
(0/98)src.cli0%
(0/1)0%
(0/1)0%
(0/67)0%
(0/30)src.indexer100%
(1/1)100%
(1/1)76%
(179/236)76%
(153/202)src.lib86%
(18/21)86%
(18/21)85%
(1596/1879)74%
(1166/1583)

KDE CI: Frameworks syntax-highlighting kf5-qt5 FreeBSDQt5.10 - Build # 27 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20syntax-highlighting%20kf5-qt5%20FreeBSDQt5.10/27/
 Project:
Frameworks syntax-highlighting kf5-qt5 FreeBSDQt5.10
 Date of build:
Thu, 28 Jun 2018 17:48:39 +
 Build duration:
3 min 42 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 6 test(s), Skipped: 0 test(s), Total: 8 test(s)Failed: TestSuite.htmlhighlighter_testFailed: TestSuite.testhighlighter_test

KDE CI: Frameworks syntax-highlighting kf5-qt5 SUSEQt5.9 - Build # 43 - Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20syntax-highlighting%20kf5-qt5%20SUSEQt5.9/43/
 Project:
Frameworks syntax-highlighting kf5-qt5 SUSEQt5.9
 Date of build:
Thu, 28 Jun 2018 17:48:39 +
 Build duration:
2 min 2 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 7 test(s), Skipped: 0 test(s), Total: 9 test(s)Failed: TestSuite.htmlhighlighter_testFailed: TestSuite.testhighlighter_test
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report60%
(3/5)82%
(27/33)82%
(27/33)79%
(2274/2891)68%
(1564/2301)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(8/8)100%
(8/8)97%
(499/512)63%
(245/388)examples0%
(0/2)0%
(0/2)0%
(0/197)0%
(0/98)src.cli0%
(0/1)0%
(0/1)0%
(0/67)0%
(0/30)src.indexer100%
(1/1)100%
(1/1)76%
(179/236)76%
(153/202)src.lib86%
(18/21)86%
(18/21)85%
(1596/1879)74%
(1166/1583)

D13657: Highlight Gradle files with Groovy syntax too

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R216:0abcd9de2c8e: Highlight Gradle files with Groovy syntax 
too (authored by vkrause).

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13657?vs=36461&id=36847

REVISION DETAIL
  https://phabricator.kde.org/D13657

AFFECTED FILES
  autotests/folding/build.gradle.fold
  autotests/html/build.gradle.html
  autotests/input/build.gradle
  autotests/reference/build.gradle.ref
  data/syntax/groovy.xml

To: vkrause, dhaumann
Cc: dhaumann, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> ngraham wrote in kmessagewidget.cpp:311
> Also, commits should be atomic; even if we want to do this, it should be in 
> another patch since it represents a separate conceptual change compared to 
> the status quo, as opposed to simply a bugfix or missing feature.

What, the alpha tweak? Do you really want to split this up in a 1st commit that 
makes things worse for some followed by one that make things better than the 
status quo?

We'll see about that later, any splitting up is going to me the WIP and review 
more complicated (if not I could also submit 5 different reviews, 1 introducing 
the basic QSettings code, and one for using it for each of the message types...)

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham added inline comments.

INLINE COMMENTS

> rjvbb wrote in kmessagewidget.cpp:311
> The issue I have with using these colours is that they are foreground 
> colours, to be used against one of 2 or 3 background colours. *That* is what 
> the theme can be expected to ensure.
> 
> There is however no obstacle whatsoever to introducing a few new colour 
> categories, specifically for this use. Only then can you blame the theme if 
> things don't work out.
> 
> I can modify (and maybe simplify) the alpha calculation of course.
> 
> Here's what my theme gives with the tweaked alpha. Without that, information 
> messages would be a darker red than error messages. That would be wrong, but 
> I don't see how there's anything wrong with using a dark red for active text 
> and a brighter red for negative. Red on grey works very nicely for text that 
> should draw attention.
> 
> F5967735: Screen Shot 2018-06-28 at 19.18.55.png 
> 

That's your theme's problem. You used almost the same color for Negative and 
Active. Isn't the whole point of this to respect the user's theme? If the user 
chooses theme colors that are problematic, we can't help that.

Either way, we certainly can't include a workaround that's tailored to a 
problem introduced by your specific choice of theme colors.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D11828: Simplify orPostingIterator and make it faster

[Fabian Vogt]

fvogt added inline comments.

INLINE COMMENTS

> orpostingiterator.cpp:86
> +// check if the docId is the new lowest docId
> +if (((docId < m_nextId)) || (m_nextId == 0)) {
> +m_nextId = docId;

Looks like most of those parens  are unnecessary.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D11828

To: bruns, #baloo, michaelh, #frameworks
Cc: fvogt, kde-frameworks-devel, #frameworks, ashaposhnikov, michaelh, 
astippich, spoorun, ngraham, bruns, abrahams

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb marked 2 inline comments as done.
rjvbb added inline comments.

INLINE COMMENTS

> ngraham wrote in kmessagewidget.cpp:311
> I don't think all of this complicated code is necessary. The theme itself is 
> supposed to ensure readability with the colors that it uses. Also, this 
> results in a slight regression for the Breeze Dark theme: the Information 
> widget doesn't get enough alpha and is too bright, worsening readability 
> compared to the status quo.

The issue I have with using these colours is that they are foreground colours, 
to be used against one of 2 or 3 background colours. *That* is what the theme 
can be expected to ensure.

There is however no obstacle whatsoever to introducing a few new colour 
categories, specifically for this use. Only then can you blame the theme if 
things don't work out.

I can modify (and maybe simplify) the alpha calculation of course.

Here's what my theme gives with the tweaked alpha. Without that, information 
messages would be a darker red than error messages. That would be wrong, but I 
don't see how there's anything wrong with using a dark red for active text and 
a brighter red for negative. Red on grey works very nicely for text that should 
draw attention.

F5967735: Screen Shot 2018-06-28 at 19.18.55.png 


REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham added a comment.


  I just realized that we have another case in `KWidgetsAddons` that could 
benefit from your read-theme-colors-without-using-kconfig idea: D12756: 
[KDateTable] Use more appropriate and readable text colors for weekends and 
holidays 
  
  Would you mind putting it into a function and submitting it in another patch? 
I think it could be nice to have available more generally.

INLINE COMMENTS

> ngraham wrote in kmessagewidget.cpp:311
> I don't think all of this complicated code is necessary. The theme itself is 
> supposed to ensure readability with the colors that it uses. Also, this 
> results in a slight regression for the Breeze Dark theme: the Information 
> widget doesn't get enough alpha and is too bright, worsening readability 
> compared to the status quo.

Also, commits should be atomic; even if we want to do this, it should be in 
another patch since it represents a separate conceptual change compared to the 
status quo, as opposed to simply a bugfix or missing feature.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham added inline comments.

INLINE COMMENTS

> ngraham wrote in kmessagewidget.cpp:275
> This commented-out line and its comments should be removed.

Never mind, you were too fast for me. :)

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham added a comment.


  Thanks, I think this approach is more feasible! I have some comments below:

INLINE COMMENTS

> kmessagewidget.cpp:275
> +// for best results.
> +// const QColor windowColor = KMessageWidget::palette().window().color();
> +const QColor windowColor = palette.window().color();

This commented-out line and its comments should be removed.

> kmessagewidget.cpp:311
> +qreal windowIntensity = 0.299 * windowColor.redF() + 0.586 * 
> windowColor.greenF() + 0.115 * windowColor.blueF();
> +bgBaseColorAlpha = 0.5 * qMax((bgIntensity + (1 - windowIntensity)), 
> bgIntensity);
>  break;

I don't think all of this complicated code is necessary. The theme itself is 
supposed to ensure readability with the colors that it uses. Also, this results 
in a slight regression for the Breeze Dark theme: the Information widget 
doesn't get enough alpha and is too bright, worsening readability compared to 
the status quo.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb updated this revision to Diff 36846.
rjvbb added a comment.


  cleanup

REPOSITORY
  R236 KWidgetsAddons

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13777?vs=36845&id=36846

REVISION DETAIL
  https://phabricator.kde.org/D13777

AFFECTED FILES
  src/kmessagewidget.cpp

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb set the repository for this revision to R236 KWidgetsAddons.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb updated this revision to Diff 36845.
rjvbb added a comment.


  Version using the suggested colour values from ~/.config/kdeglobals , if the 
file exists and has a Colors:Window group.
  
  In my case this gives informational and error messages almost the same 
background colour because I have configured a dark red colour for active 
foreground text (a darker colour than the negative foreground colour, in fact).
  
  The advantage of an approach like in the previous version is that at least 
some message colours adapt when the application uses a custom palette (e.g. 
KDevelop or digiKam).

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13777?vs=36841&id=36845

REVISION DETAIL
  https://phabricator.kde.org/D13777

AFFECTED FILES
  src/kmessagewidget.cpp

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham added a comment.


  This patch isn't the right place for discussing changing the conceptual color 
scheme for the widgets.
  
  This patch also isn't the place for insulting the people who you're hoping 
will accept your changes. :)
  
  If you want to implement a private method to get theme colors that doesn't 
rely on `KConfig`, you can use the ones that were in the original comments:
  
  - Window: ForegroundPositive for Positive
  - Window: ForegroundActive for Information
  - Window: ForegroundNeutral for Warning
  - Window: ForegroundNegative for Negative

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb added a comment.


  > Another idea would have been to have the widget style alter the appearance 
like it already does for things like `KTitleWidget`
  
  Care to develop?
  
  > - Suspend output in a Konsole window that has a dark background color: the 
text is unreadable.
  
  By hitting ^S? I get a yellow background regardless of the palette but it is 
possible that you're right that I should just use the application palette. Or 
(or and) maybe text should take the background colour intensity or better yet, 
colour contrast into consideration. Because what would happen if someone uses a 
dark scheme with a light (green or blue) colour for regular text, wouldn't that 
also lead to unreadable text?
  
  > - All Information-style widgets have a gray background.
  
  That depends on your palette. They are grey only when you also use grey (or 
black or white) tooltips. If that's the background you chose for delivering one 
kind of informational feedback, why not also use it for other kind(s)?
  
  > - Positive-style widgets are now blue.
  
  And why is that a problem? If you don't like blue, use a different palette? I 
agree blue is a problem (for physiological reasons) but in general, not just 
for positive messages.
  
  It would help here if there were documentation about what those messages are 
supposed to do. But conceptually speaking I think it's perfectly appropriate 
that they use the highlighting colour.
  
  *This* is where consistency comes in, IMHO.
  
  > - One of the goals was to match the colors of the Kirigami equivalent. 
Consistency is important.
  
  I've said this before, the consistency argument doesn't fly here IMHO, or 
rather, it works against the current state of things. Kirigami uses QtQuick 
which is a completely different beast than QtWidget-based things, and depending 
on the version you use it will not even use your selected widget style. 
Kirigami is also the newcomer, and IMHO it's not up to existing software to 
adapt to newcomers but up to those to adapt to the existing environment.
  
  > - There's no kind way to say this, but I don't think the new colors are 
attractive.
  
  There's also no kind way to say that you don't have to think so because those 
are *my* colours. And I'm sure I find the Breeze colour scheme much more 
disgusting O:-)
  No kind way either of saying that I don't use any kirithingy apps personally, 
in part because I don't care for the mobile-app look they have: form over 
function), and that I want to keep the subdued "professional" look I've 
achieved in the (KTextEditor based) applications I do use extensively.
  I'm reminded of a quote from a KDE ML I read this morning, with which I sadly 
have to agree:
  
  > "the wonderful thing about the apparent current mindset of the KDE 
developers, that the KDE desktop is no longer something for end-users, but just 
a toy for the edification of its developers. Continuity? Usability?  Bah, who 
needs that?  Here's some eye-candy instead."
  
  Let's avoid discussing tastes beyond the fact that one shouldn't impose a 
particular palette that isn't neutral (= grey scale).
  
  I notice that Qt's example "Settings Editor" application opens and parses 
~/.config/kdeglobals just fine:
  
  F5967227: Screen Shot 2018-06-28 at 17.02.56.png 

  
  That would mean that QSettings can indeed be used to get the colours to be 
used from that file. Which ones would we use?

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: broulik, cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added a comment.
This revision now requires changes to proceed.


  I'm not sure that's the right approach. This new version has bugs with Breeze 
light:
  
  - Suspend output in a Konsole window that has a dark background color: the 
text is unreadable.
  - All Information-style widgets have a gray background.
  - Positive-style widgets are now blue.
  
  ...And conceptual issues:
  
  - One of the goals was to match the colors of the Kirigami equivalent. 
Consistency is important.
  - There's no kind way to say this, but I don't think the new colors are 
attractive.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: broulik, cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Kai Uwe Broulik]

broulik added a comment.


  -1
  
  The upper two in second revision look quite bad.
  
  Another idea would have been to have the widget style alter the appearance 
like it already does for things like `KTitleWidget`

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: broulik, cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb added a comment.


  5.47.0 (stock) vs. 5.42.0 (stock), QtCurve (top) vs. Macintosh native (below):
  F5967082: KMessageWidget-styles-before,after.png 

  
  with revision 2 of my patch:
  F5967086: Screen Shot 2018-06-28 at 16.04.28.png 


REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb marked 3 inline comments as done.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb set the repository for this revision to R236 KWidgetsAddons.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb updated this revision to Diff 36841.
rjvbb added a comment.


  This revision incorporates the feedback and implements the approach already 
evoked:
  
  - use the user's highlight colour for positive messages, with a 0.4 alpha 
value
  - use the user's tooltip background colour for informational messages. The 
alpha value is based on the psychometric (perceived) intensity of the selected 
colour and its difference with the widget background intensity: half the 
average of those values, limited by half the intensity itself.
  - warning and error messages remain orange and red respectively as those are 
commonly accepted uses
  
  The final message background colour is determined as an average of the 
type-specific colour and the widget background colour, and should thus probably 
use the receiving widget's actual colour for best effects. Text colour is still 
taken from the application palette.
  
  This scheme works quite nicely for me with my own palette, but also (IMHO) 
with the 4 Breeze palettes, the Oxygen palette and Krita Neutral. Breeze Dark 
apparently uses the same background colour for regular windows and tooltips. I 
rather like the fact that as a result, informational messages don't stand out 
any more than tooltips or like they do with the current implementation - I 
think that must have been the intent of the theme developer(s).
  
  (A pity it's probably not possible to add a palette (theme) picker to the 
kmessagewidget test app?)

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13777?vs=36825&id=36841

REVISION DETAIL
  https://phabricator.kde.org/D13777

AFFECTED FILES
  src/kmessagewidget.cpp

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13773: [KDirOperator] Use alternating background colors for list-style views

[Nathaniel Graham]

ngraham edited the summary of this revision.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D13773

To: ngraham, #frameworks, #vdg, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Kai Uwe Broulik]

broulik updated this revision to Diff 36838.
broulik added a comment.


  Only check for folders, a file cannot be a mount, saves querying mount points 
for hidden files

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13782?vs=36837&id=36838

REVISION DETAIL
  https://phabricator.kde.org/D13782

AFFECTED FILES
  src/ioslaves/file/file_unix.cpp

To: broulik, dfaure, ngraham, yurikoles
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13782: RFC: Ignore NTFS hidden flag for root volume

[Kai Uwe Broulik]

broulik created this revision.
broulik added reviewers: dfaure, ngraham, yurikoles.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
broulik requested review of this revision.

REVISION SUMMARY
  Those are always hidden as far as NTFS is concerned but leads to unwanted 
side-effects of NTFS volumes becoming inaccessible in the UI
  
  BUG: 392913

TEST PLAN
  My NTFS drive in `/media` is visible again
  Inside the folder I get `/media/foo/.` where the mapping fails again. Any 
`QUrl` or KIO resolve magic to fix that?
  No idea this patch is the right approach, just throwing it out for discussion

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D13782

AFFECTED FILES
  src/ioslaves/file/file_unix.cpp

To: broulik, dfaure, ngraham, yurikoles
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added a comment.
This revision now requires changes to proceed.


  KWidgetsAddons is a Tier 1 framework, so it can't depend on any other KDE 
Frameworks, including KConfig, which is where the current theme's full palette 
is stored. Because of that, we're restricted to hardcoding the colors for the 
Positive, Warning, and Error styles rather than reading them from the current 
theme. My thinking was that since we're already forced to do this, it made more 
sense to just hardcode everything and preserve a consistent visual style until 
and unless we can somehow make it use the theme's colors.
  
  I'm not necessarily against using the palette's highlight color for the 
Information widget, but I'd strongly prefer a solution that allows the use of 
all colors from the active theme, not just one.
  
  We can't use the local widget's own palette, for reasons explained below in 
an inline comment.

INLINE COMMENTS

> kmessagewidget.cpp:262
> +// use the current widget's palette (it could be different from the 
> application palette)
> +const QPalette palette = palette();
>  

Using the global application palette was deliberate. Try your change and then 
suspend a terminal window that has a dark background when you're using Breeze 
light. Local widgets may set a palette that's incompatible with some of the 
colors we're forced to hardcode due to `KWidgetsAddons` being a Tier 1 
framework, or may set a palette that's incomplete and results in unreadable 
text. It's much safer to just use the app's own palette.

> kmessagewidget.cpp:272
>  case Information:
> -bgBaseColor.setRgb(61, 174, 233); // Window: ForegroundActive
> +// use the highlight colour for this type, as before
> +bgBaseColor = palette.highlight().color();

"as before" not needed. Really, @cfeck is right and the entire comment isn't 
needed.

> kmessagewidget.cpp:282
>  
> -const QPalette palette = QGuiApplication::palette();
>  const QColor windowColor = palette.window().color();

Same

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[Christoph Feck]

cfeck added a comment.


  here is WIP feedback: the comments explain the change, but they are not 
needed to explain the code. Remove them.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

To: rjvbb, ngraham, #frameworks
Cc: cfeck, kde-frameworks-devel, michaelh, ngraham, bruns

D13777: KMessageWidget : revert to using highlight colour for Information style (WIP)

[René J . V . Bertin]

rjvbb created this revision.
rjvbb added reviewers: ngraham, Frameworks.
Restricted Application added a project: Frameworks.
rjvbb requested review of this revision.

REVISION SUMMARY
  A recent commit (00bce130d35e9dc398709e690a05f8dde70f52b3 
) 
modified the KMessageWidget look and feel. While I fail to see the point to 
make them look like their Kirigami equivalent this doesn't really bother me 
either.
  
  The change did introduce 1 regression IMHO: the Information type background 
colour is now hardcoded instead of being based on the highlight colour as 
before. This is also the type I encounter most (in Kate, KDevelop etc).
  
  The patch below reverts the colour hardcoding by obtaining the base colour 
from the current palette, as before.
  
  Additionally, I propose to use the current widget palette instead of the 
global application palette, as we cannot know whether or not the code calling 
us installed a custom palette for the particular widget we're working with.
  
  I've marked this WIP because I plan to use the occasion to investigate 
whether or not it's possible to drop some of the other hardcoded colours.
  
  I am also open to discussion whether it would be more appropriate to use the 
user's tooltip colour (`QPalette::ToolTipBase`) for Information messages, or to 
introduce a type-specific darkening factor for the calculation of the final 
background colour.

TEST PLAN
  Reverts the annoying blueish background of the new-style Information messages 
to a colour I picked myself.

REPOSITORY
  R236 KWidgetsAddons

REVISION DETAIL
  https://phabricator.kde.org/D13777

AFFECTED FILES
  src/kmessagewidget.cpp

To: rjvbb, ngraham, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D9446: WIP: Allow to autogenerate and install categories file

[Ralf Habacker]

habacker added a comment.


  - doc in file header is missing
  - test case is missing

INLINE COMMENTS

> ECMQtDeclareLoggingCategory.cmake:68
>  set(options)
> -set(oneValueArgs HEADER IDENTIFIER CATEGORY_NAME DEFAULT_SEVERITY)
> +set(oneValueArgs HEADER IDENTIFIER CATEGORY_NAME DEFAULT_SEVERITY 
> CATEGORY_INSTALL_FILENAME CATEGORY_DESCRIPTION)
>  set(multiValueArgs)

may be better using shorter names like  INSTALL_FILENAME, DESTINATION  or 
FILENAME
and DESCRIPTION instead of CATEGORY_DESCRIPTION. because we are declaring a 
logging category

> ECMQtDeclareLoggingCategory.cmake:138
> +if (ARG_CATEGORY_INSTALL_FILENAME)
> +set(CAT_DESCRIPTION)
> +if (ARG_CATEGORY_DESCRIPTION) 

Using ${PROJECT_NAME} if empty ?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9446

To: mlaurent, kfunk, lbeltrame, cgiboudeaux, dfaure, fvogt
Cc: ltoscano, kde-frameworks-devel, kde-buildsystem, habacker, michaelh, 
ngraham, bruns

D9446: WIP: Allow to autogenerate and install categories file

[Ralf Habacker]

habacker added a comment.


  In D9446#284272 , @habacker wrote:
  
  > In D9446#181785 , @mlaurent wrote:
  >
  > > IT's a WIP as I use file(APPEND...) because I want to generate several 
categories in one file.
  > >  But it doesn't work as I don't have idea how to reset file when cmake is 
started...
  > >
  > > Do you have an idea ?
  >
  >
  > No cmake experts on the KF5 team like it was at KDE4?
  
  
  I tried this, which seems to work
  
#.rst:
# ECMQtDeclareLoggingCategory
...
set_property(GLOBAL PROPERTY _ecm_qtdlc_counter "0")
...
function(ecm_qt_declare_logging_category sources_var)
  ...
  if (ARG_CATEGORY_INSTALL_FILENAME)
  set(cat_file 
${CMAKE_BINARY_DIR}/${ARG_CATEGORY_INSTALL_FILENAME}.categories)
  get_property(counter GLOBAL PROPERTY _ecm_qtdlc_counter)
  if(counter STREQUAL "0")
  file(WRITE ${cat_file} "")
  endif()

  set(CAT_DESCRIPTION)
  if (ARG_CATEGORY_DESCRIPTION)
  set(CAT_DESCRIPTION ${ARG_CATEGORY_DESCRIPTION})
  endif()
  file(APPEND ${cat_file} "${ARG_CATEGORY_NAME} ${CAT_DESCRIPTION}\n")
  MESSAGE(STATUS "${cat_file} ${CAT_DESCRIPTION}")
  install( FILES ${cat_file} DESTINATION ${KDE_INSTALL_CONFDIR} )
  math(EXPR counter "${counter} + 1")
  set_property(GLOBAL PROPERTY _ecm_qtdlc_counter "${counter}")
  endif()

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9446

To: mlaurent, kfunk, lbeltrame, cgiboudeaux, dfaure, fvogt
Cc: ltoscano, kde-frameworks-devel, kde-buildsystem, habacker, michaelh, 
ngraham, bruns

D9446: WIP: Allow to autogenerate and install categories file

[Luigi Toscano]

ltoscano added a comment.


  In D9446#284288 , @cgiboudeaux 
wrote:
  
  >
  
  
  
  
  > There are several issues that need fixes:
  > 
  > - Installation dir for categories, /etc/xdg on linux has always been wrong. 
categories are not config files
  
  That's something that should be addressed separately and it requires support 
in kdebugsettings for few cycles before switching, otherwise people will not be 
able to use the new categories file generated. At this point it could be 
probably a TODO KF6...

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9446

To: mlaurent, kfunk, lbeltrame, cgiboudeaux, dfaure, fvogt
Cc: ltoscano, kde-frameworks-devel, kde-buildsystem, habacker, michaelh, 
ngraham, bruns

Re: text search balloon background colour

[René J . V . Bertin]

If we're indeed talking about the change to match Kirigami: why on earth 
do that? If developers want to achieve that style they can use the 
framework that provides it. If not, let the style in use handle the way 
things look, AS PER THE USER'S REQUEST!

R.

Re: text search balloon background colour

[René J . V . Bertin]

Kai Uwe Broulik wrote:

Hi,

> it was adjusted to more closely resemble the Breeze visual style. The colors
> are unfortunately hardcoded as KWidgetAddons as a Tier 1 framework cannot
> depend on KColorScheme.

Yeah, that's not good, hardcoding colours is in fact a bug because it can lead 
to something unreadable (for a variety of reasons including allergy to blue ;)).

Instead the appropriate colour should be read from kdeglobals, or else, why not 
simply use the tooltip background colour? I'm pretty certain you can retrieve 
that QColor with pure Qt calls, which may or may not go through a platform 
theme 
plugin that does access KColorScheme or gets the colour from the widget style 
in 
use.

At a minimum, Breeze tweaks should be applied only when using the Breeze widget 
style (which can be determined with pure Qt calls).

I'll try to look into this; are we talking about commit 
00bce130d35e9dc398709e690a05f8dde70f52b3 or 
159c6950e39968f12b6366fb167bfd441c92bf5b?

R.

D9446: WIP: Allow to autogenerate and install categories file

[Christophe Giboudeaux]

cgiboudeaux added a comment.


  In D9446#284272 , @habacker wrote:
  
  > In D9446#181785 , @mlaurent wrote:
  >
  > > IT's a WIP as I use file(APPEND...) because I want to generate several 
categories in one file.
  > >  But it doesn't work as I don't have idea how to reset file when cmake is 
started...
  > >
  > > Do you have an idea ?
  >
  >
  > No cmake experts on the KF5 team like it was at KDE4?
  
  
  I didn't forget this task. Just didn't have time.
  
  There are several issues that need fixes:
  
  - Installation dir for categories, /etc/xdg on linux has always been wrong. 
categories are not config files
  - Fix the issue Laurent raised

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9446

To: mlaurent, kfunk, lbeltrame, cgiboudeaux, dfaure, fvogt
Cc: ltoscano, kde-frameworks-devel, kde-buildsystem, habacker, michaelh, 
ngraham, bruns

D9446: WIP: Allow to autogenerate and install categories file

[Ralf Habacker]

habacker added a comment.


  In D9446#181785 , @mlaurent wrote:
  
  > IT's a WIP as I use file(APPEND...) because I want to generate several 
categories in one file.
  >  But it doesn't work as I don't have idea how to reset file when cmake is 
started...
  >
  > Do you have an idea ?
  
  
  No cmake experts on the KF5 team like it was at KDE4?

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9446

To: mlaurent, kfunk, lbeltrame, cgiboudeaux, dfaure, fvogt
Cc: ltoscano, kde-frameworks-devel, kde-buildsystem, habacker, michaelh, 
ngraham, bruns

D13747: Fuzzy filename search for Baloo

[Michael Eden]

michaeleden updated this revision to Diff 36811.
michaeleden added a comment.


  Add fuzzy search class separate from db and make tests to demonstrate 
algorithm

REPOSITORY
  R293 Baloo

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13747?vs=36724&id=36811

BRANCH
  feature/fuzzy-search

REVISION DETAIL
  https://phabricator.kde.org/D13747

AFFECTED FILES
  autotests/unit/engine/CMakeLists.txt
  autotests/unit/engine/fuzzysearchtest.cpp
  src/engine/CMakeLists.txt
  src/engine/database.cpp
  src/engine/databasedbis.h
  src/engine/fuzzydb.cpp
  src/engine/fuzzydb.h
  src/engine/fuzzysearch.cpp
  src/engine/fuzzysearch.h
  src/engine/transaction.cpp

To: michaeleden, vhanda, #baloo
Cc: bruns, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, 
spoorun, ngraham, abrahams