KDE CI: Frameworks frameworkintegration kf5-qt5 FreeBSDQt5.9 - Build # 20 - Fixed!

[CI System]

BUILD SUCCESS
 Build URL
https://build.kde.org/job/Frameworks%20frameworkintegration%20kf5-qt5%20FreeBSDQt5.9/20/
 Project:
Frameworks frameworkintegration kf5-qt5 FreeBSDQt5.9
 Date of build:
Mon, 23 Apr 2018 07:00:38 +
 Build duration:
51 sec and counting
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)

D12371: fix always reproducible crash

[Jaime Torres Amate]

jtamate added a comment.


  > One solution is to call printDebug(), which will output lots of information 
including the contents of directoryData().
  
  I have some questions:
  Is a KCoreDirLister able to handle more than one directory? The same 
KCoreDirLister pointer is holding smb:// and smb:/// at some point.
  Shouldn't something be done in the cache when the KCoreDirLister changes from 
smb:// to smb:/// ?
  
  The output I get, with a printDebug() call before Iterating over dirs;
  
kf5.kio.core.dirlister: +KCoreDirLister
kf5.kio.core.dirlister: 
kf5.kio.core.dirlister: +KCoreDirLister
kf5.kio.core.dirlister: ~KCoreDirLister KCoreDirLister(0x2b6add0)
kf5.kio.core.dirlister: lister: KCoreDirLister(0x2b6add0) silent= false
kf5.kio.core.dirlister: KCoreDirLister(0x2b6add0)
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: Iterating over dirs ()
kf5.kio.core.dirlister: KDirLister(0x2b69460) url= QUrl("file:///kk") keep= 
false reload= false
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: lister: KDirLister(0x2b69460) silent= true
kf5.kio.core.dirlister: KDirLister(0x2b69460)
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: Iterating over dirs ()
kf5.kio.core.dirlister: Listing directory: QUrl("file:///kk")
kf5.kio.core.dirlister: Entry now being listed by (KDirLister(0x2b69460))
kf5.kio.core.dirlister: new entries for  QUrl("file:///kk")
kf5.kio.core.dirlister: finished listing QUrl("file:///kk")
kf5.kio.core.dirlister: KDirLister(0x2b69460) numJobs: 0
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: "file:///kk" URL: QUrl("file:///kk") rootItem: 
QUrl("file:///kk") autoUpdates refcount: 1 complete: true "with 0 items."
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister:"file:///kk" 0 listers: ""
kf5.kio.core.dirlister:"file:///kk" 1 holders: " 0x2b69460"
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: KDirLister(0x2b69460) url= QUrl("remote:/") keep= 
false reload= false
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: "file:///kk" URL: QUrl("file:///kk") rootItem: 
QUrl("file:///kk") autoUpdates refcount: 1 complete: true "with 0 items."
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister:"file:///kk" 0 listers: ""
kf5.kio.core.dirlister:"file:///kk" 1 holders: " 0x2b69460"
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: lister: KDirLister(0x2b69460) silent= true
kf5.kio.core.dirlister: KDirLister(0x2b69460)  url= QUrl("file:///kk")
kf5.kio.core.dirlister: KDirLister(0x2b69460)
kf5.kio.core.dirlister: =Items in use:
kf5.kio.core.dirlister: "file:///kk" URL: QUrl("file:///kk") rootItem: 
QUrl("file:///kk") autoUpdates refcount: 1 complete: true "with 0 items."
kf5.kio.core.dirlister: Directory data:
kf5.kio.core.dirlister:"file:///kk" 0 listers: ""
kf5.kio.core.dirlister:"file:///kk" 1 holders: " 0x2b69460"
kf5.kio.core.dirlister: Jobs:
kf5.kio.core.dirlister: Items in cache:
kf5.kio.core.dirlister: =
kf5.kio.core.dirlister: Iterating over dirs (QUrl("file:///kk"))
kf5.kio.core.dirlister: KDirLister(0x2b69460)  _url:  QUrl("file:///kk")
kf5.kio.core.dirlister: KDirLister(0x2b69460) item moved into cache: 
QUrl("file:///kk")
kf5.kio.core.dirlister: Listing directory: QUrl("remote:/")
kf5.kio.core.dirlister: Entry now being listed by (KDirLister(0x2b69460))
kf5.kio.core.dirlister: new entries for  QUrl("remote:/")
kf5.kio.core.dirlister: Adding item:  
QUrl("remote:/x-wizard_service.desktop")
kf5.kio.core.dirlister: in QUrl("remote:/") item: 
QUrl("remote:/x-wizard_service.desktop")
kf5.kio.core.dirlister: Adding item:  QUrl("remote:/bluetooth-network")
kf5.kio.core.dirlister: in QUrl("remote:/") item: 
QUrl("remote:/bluetooth-network")
kf5.kio.core.dirlister: Adding item:  QUrl("remote:/mtp-network")
kf5.kio.core.dirlister: in QUrl("remote:/") item: 
QUrl("remote:/mtp-network")
kf5.kio.core.dirlister: Adding item:  QUrl("remote:/network")
kf5.kio.core.dirlister: in QUrl("remote:/") item: QUrl("remote:/network")
kf5.kio.core.dirlister: Adding item:

D12311: Align lock icon with bold message text; reduce overall size of dialog

[Andrius Štikonas]

stikonas added a comment.


  In D12311#252165 , @bruns wrote:
  
  > Resizing: 
http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Partition.html#gdbus-method-org-freedesktop-UDisks2-Partition.Resize
  
  
  Does not work well yet, just a few errors where KPM succeeds:
  
  - Cannot resize btrfs filesystem on /dev/sdb1: (null) filesystem 'btrfs' is 
not supported.
  - LUKS encrypted ext4: looks like I can resize internal file system but no 
way to resize outer LUKS container (i.e. what cryptsetup resize does)
  - Does not recognize LVM PVs, no way to resize them.
  
  On the other hand, it might be useful in certain cases. E.g. to resize FAT 
and maybe HPFS (not all distros ship fatresize).
  
  In any case, resizing is not the only thing. No way to copy/move file systems.
  
  I'm not opposed to UDisks in principle, I am just saying it's not there yet.

REPOSITORY
  R121 Policykit (Polkit) KDE Agent

BRANCH
  align-lock-icon (branched from master)

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

To: sharvey, davidedmundson, ngraham, abetts, #frameworks
Cc: stikonas, bruns, ltoscano, broulik, davidedmundson, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart

D12321: Hide file preview when icon is too small

[Alex Nemeth]

anemeth updated this revision to Diff 32872.
anemeth added a comment.


  Change tooltip when preview button is disabled/enabled.

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D12321?vs=32602&id=32872

BRANCH
  conditional_preview (branched from master)

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

AFFECTED FILES
  src/filewidgets/kdiroperator.cpp

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin
Cc: xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12328: Enable preview by default in the filepicker dialog

[Alex Nemeth]

anemeth added a comment.


  I manually copied the .upd file to `/home/alex/.kde/share/apps/kconf_update` 
and to `/usr/share/apps/kconf_update` but it doesn't seem like kconf_update is 
doing its thing.
  What am I doing wrong?

REPOSITORY
  R241 KIO

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

To: anemeth, #frameworks, #vdg, rkflx
Cc: abetts, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

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


  That looks really fancy! :)
  Yet i have to give it a -1..
  
  You are overwriting a setting that the user had explicitly set (show 
preview). That will result in a "huh, why is the preview off all of a sudden?" 
responses which will lead to bug reports.
  I would consider it a bug if the view is going to decide for me when i want 
to see previews and when not.
  
  Also, i really would not base this logic on fonts. I can have smaller fonts 
just because i might like that (or bigger, same argument) which would then 
determine when the preview is switched off.
  I get that this is a tricky area, but it would be much better if you can 
somehow determine if the preview is going to be smaller then - lets say - 1 by 
1 centimeters (in physical size, therefore you need to know the scaling ratio 
and the dpi) or in inch it would be 0.39 by 0.39. That would be a more logical 
decision to turn on/off previews.
  
  This logic breaks in really high resolution displays (take smartphones for 
example) where a 1x1 cm block can (and should!) easily show you an image. But 
lets lets consider that a out-of-scope issue as dolphin isn't on the smartphone 
(that i'm aware of), just something that might need to be considered in the 
future.
  
  That being said, having an "auto preview" (aka, the view knows best, your 
implementation) would be awesome! But not as overridden user setting.
  Perhaps the preview button needs to become a tri-state button:
  
  - Off
  - On (always a preview, the user knows best)
  - Auto (the view decides when you see a preview)
  
  I have no clue how a tri-state button would look in dolphin though :) Or even 
if the Breeze theme has a graphical representation for it.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252238 , @markg wrote:
  
  > That looks really fancy! :)
  >  Yet i have to give it a -1..
  >
  > You are overwriting a setting that the user had explicitly set (show 
preview). That will result in a "huh, why is the preview off all of a sudden?" 
responses which will lead to bug reports.
  
  
  That's simply a bug with the patch: Enable previews, set small icon set, 
click Cancel, reopen dialog, set large icon size. Previews should still be 
enabled, but they are not. I guess this needs to track separately what the user 
set vs. what the button says (as for small sizes the thumbnails are turned off 
by the slider, not by the user) when writing to the config.
  
  > This logic breaks in really high resolution displays (take smartphones for 
example) where a 1x1 cm block can (and should!) easily show you an image. But 
lets lets consider that a out-of-scope issue as dolphin isn't on the smartphone 
(that i'm aware of), just something that might need to be considered in the 
future.
  
  The patch is basing the cut-off point on the logical size, not on the 
physical size, and as such should work just fine in HiDPI mode. Also, in 
general the font size is a good approximation on what sizes user prefer. There 
is no need to make every single aspect of our UI's behaviour configurable, 
because we should pick good defaults.
  
  > That being said, having an "auto preview" (aka, the view knows best, your 
implementation) would be awesome! But not as overridden user setting.
  >  Perhaps the preview button needs to become a tri-state button:
  > 
  > - Off
  > - On (always a preview, the user knows best)
  > - Auto (the view decides when you see a preview)
  
  I think this was discussed before, and rejected? @ngraham Can you remember?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12328: Enable preview by default in the filepicker dialog

[Henrik Fehlauer]

rkflx added a comment.


  In D12328#250028 , @anemeth wrote:
  
  > Rebase on D12321 
  
  
  While the dependency tree is now looking good, the rebase did not work out 
correctly. While it might look correct on your local branch, on Phabricator you 
can clearly see that in this Diff the changes from the parent revision are 
visible, which should not be there. Please make sure to always check what ends 
up on Phabricator, as that's what your reviewers are seeing.
  
  `arc diff` will upload the commit range between `HEAD` and the upstream 
tracking branch. Here the upstream branch apparently is `master`, while it 
should be your local branch where D12321  
is living (you have a separate branch per Diff as written in the wiki, right?). 
You may want to look at my advice in D12321#249646 
 again.
  
  ---
  
  In D12328#25 , @anemeth wrote:
  
  > I manually copied the .upd file to 
`/home/alex/.kde/share/apps/kconf_update` and to `/usr/share/apps/kconf_update` 
but it doesn't seem like kconf_update is doing its thing.
  >  What am I doing wrong?
  
  
  Did you read 
https://techbase.kde.org/Development/Tools/Using_kconf_update#Debugging_and_testing?
 Or maybe you need to manually call the `kconf_update` executable? Checking 
kded's output should tell you whether it ran.

REPOSITORY
  R241 KIO

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

To: anemeth, #frameworks, #vdg, rkflx
Cc: abetts, rkflx, ngraham, #frameworks, michaelh, bruns

D11470: SQL: various improvements and fix if/case/loop/end detection with SQL (Oracle)

[Henrik Fehlauer]

rkflx added a comment.


  Sorry for chiming in, but in light of the focus goal T7116: Streamlined 
onboarding of new contributors  it's 
important to fix rough edges in our infrastructure, too:
  
  In D11470#252163 , @jpoelen wrote:
  
  > I am completely lost with `arc diff`. The command adds files that I did not 
normally modify in this branch and specifiying a reference commit does not seem 
to work.
  
  
  Do you know about our recommended workflow in 
https://community.kde.org/Infrastructure/Phabricator#Workflow? Happy to help 
with that, just let me know.
  
  > I ended up doing everything through a new branch, sorry to rot the history 
like this :/.
  
  Phabricator's Differential is simply a list of patch iterations if you will, 
there is no "history" as such which you might have impacted. Only if you use 
the web uploader instead of Arcanist you make life for the reviewer a bit 
harder (no author information when landing, no context in the diff view, no 
base commit).

REPOSITORY
  R216 Syntax Highlighting

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

To: jpoelen, #framework_syntax_highlighting, dhaumann
Cc: rkflx, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Alex Nemeth]

anemeth added a comment.


  In D12321#252245 , @rkflx wrote:
  
  > That's simply a bug with the patch: Enable previews, set small icon set, 
click Cancel, reopen dialog, set large icon size. Previews should still be 
enabled, but they are not.
  
  
  I already fixed that 2 diffs ago.
  
  F5819083: 2018-04-23 13-15-44.webm 

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Alex Nemeth]

anemeth added a comment.


  In D12321#252238 , @markg wrote:
  
  > You are overwriting a setting that the user had explicitly set (show 
preview). That will result in a "huh, why is the preview off all of a sudden?" 
responses which will lead to bug reports.
  
  
  That's why the tooltip changes when that is the case.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252258 , @anemeth wrote:
  
  > In D12321#252245 , @rkflx wrote:
  >
  > > That's simply a bug with the patch: Enable previews, set small icon set, 
click Cancel, reopen dialog, set large icon size. Previews should still be 
enabled, but they are not.
  >
  >
  > I already fixed that 2 diffs ago.
  
  
  Indeed, it's working now. Sorry for the confusion. I guess I was testing 
D12328  then. Normally due to the dependent 
revision it should pick up the change, but because of the rebase gone wrong, it 
did not work apparently.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252259 , @anemeth wrote:
  
  > In D12321#252238 , @markg wrote:
  >
  > > You are overwriting a setting that the user had explicitly set (show 
preview). That will result in a "huh, why is the preview off all of a sudden?" 
responses which will lead to bug reports.
  >
  >
  > That's why the tooltip changes when that is the case.
  
  
  Let me rephrase it then :)
  
  The user **explicitly** clicks on the preview button. If the user then zooms 
in/out that same preview button might change to what the view thinks is best.
  That is unexpected behavior.
  
  A tri-state would prevent that.
  For the record, if it becomes a tri-state i would set it to auto (this 
implementation, the view knows best) by default.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252261 , @markg wrote:
  
  > That is unexpected behavior.
  
  
  I disagree, adapting the interface dynamically is good design.
  
  > A tri-state would prevent that.
  >  For the record, if it becomes a tri-state i would set it to auto (this 
implementation, the view knows best) by default.
  
  Suppose previews are on. Now the user clicks on the button, wanting to turn 
previews off. Sadly, nothing will happen, because the user just switched into 
"automatic" mode. That's not something we should implement!
  
  Besides that, `tristate` is only a property of `QCheckBox`, but not of 
`QToolButton`. (And see also confusion here: 
https://www.reddit.com/r/kde/comments/8c5ael/there_are_several_settings_in_kde_that_have_a/.)
  
  Thus this would need to be a separate config option, making everything even 
more complicated. I don't get why you want to see those tiny previews? Or is it 
simply out of principle that you want to control the thumbnails, even if they 
are not useful?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  @markg One more thing: This patch is a prerequisite for D12321: Hide file 
preview when icon is too small , because 
otherwise for small icons the previews would also be turned on by default, 
which we don't want obviously (even you said by default for tiny icons 
thumbnails don't make any sense).
  
  D12321  again is required for the vision 
outlined T8552 , i.e. having a details tree 
view mode with tiny icons, and a visual text-under-icons mode with large icons 
and previews.
  
  If you think we should abandon the dialog overhaul in it's entirety, please 
comment on that task.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252264 , @rkflx wrote:
  
  > In D12321#252261 , @markg wrote:
  >
  > > That is unexpected behavior.
  >
  >
  > I disagree, adapting the interface dynamically is good design.
  
  
  I agree but not for a button that the user controls.
  It should either be a tri-state or a "auto preview" button.
  
  You should never change states that users had set explicitly (at least, 
that's my opinion).
  It will only cause confusion and becomes a nightmare when saving settings as 
you then already need to maintain if a button was changed by the user or code 
logic.
  In fact, the current patch already adds class-wide bools to check for this 
thus internally it already needs a tri state.
  
  > 
  > 
  >> A tri-state would prevent that.
  >>  For the record, if it becomes a tri-state i would set it to auto (this 
implementation, the view knows best) by default.
  > 
  > Suppose previews are on. Now the user clicks on the button, wanting to turn 
previews off. Sadly, nothing will happen, because the user just switched into 
"automatic" mode. That's not something we should implement!
  > 
  > Besides that, `tristate` is only a property of `QCheckBox`, but not of 
`QToolButton`. (And see also confusion here: 
https://www.reddit.com/r/kde/comments/8c5ael/there_are_several_settings_in_kde_that_have_a/.)
  > 
  > Thus this would need to be a separate config option, making everything even 
more complicated. I don't get why you want to see those tiny previews? Or is it 
simply out of principle that you want to control the thumbnails, even if they 
are not useful?
  
  With a two-state button you either give me control or you don't, anything in 
between is potentially unexpected behavior.
  If you want smarter ways then two-states then it should either be represented 
in a button that can handle it (a tri-state) or a new button altogether with 
the downside that you get two (at first sight seemingly the same) buttons.
  
  As for the vision, i'm perfectly fine with that :)
  Just as long as it doesn't cause unexpected behavior which i think this one 
as implemented now will cause. That doesn't make the vision wrong, it merely 
means the technical execution of some parts might need a little tweaking.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252281 , @markg wrote:
  
  > I agree but not for a button that the user controls.
  
  
  We already disable options where they do not make sense, see the Icon 
position setting which is only available in select view modes.
  
  The ability to preview could similarly be disabled where it does not make 
sense. I highly doubt this will confusion for users.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252282 , @rkflx wrote:
  
  > In D12321#252281 , @markg wrote:
  >
  > > I agree but not for a button that the user controls.
  >
  >
  > We already disable options where they do not make sense, see the Icon 
position setting which is only available in select view modes.
  >
  > The ability to preview could similarly be disabled where it does not make 
sense. I highly doubt this will cause confusion for users.
  
  
  Ohh, but i'm not against that :)
  I merely don't want one button to be changed by both the user and some code 
logic.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252283 , @markg wrote:
  
  > In D12321#252282 , @rkflx wrote:
  >
  > > In D12321#252281 , @markg 
wrote:
  > >
  > > > I agree but not for a button that the user controls.
  > >
  > >
  > > We already disable options where they do not make sense, see the Icon 
position setting which is only available in select view modes.
  > >
  > > The ability to preview could similarly be disabled where it does not make 
sense. I highly doubt this will cause confusion for users.
  >
  >
  > Ohh, but i'm not against that :)
  >  I merely don't want one button to be changed by both the user and some 
code logic.
  
  
  It's the same for Icon position: Even if the user does not change from Above 
filename to Next to filename the code logic when changing the radio button 
(which would equal moving the zoom slider) to another view mode will change the 
icon position anyway, because for Detailed View you cannot have icons above the 
filename.
  
  This automatic logic is already there. You are simply objecting to not 
allowing previews for small icons. Yes, we will remove this possibility which 
was there before. No, I don't think this is bad, unless you can come up with 
reasons why anyone would want totally undecipherable previews.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252285 , @rkflx wrote:
  
  > In D12321#252283 , @markg wrote:
  >
  > > In D12321#252282 , @rkflx 
wrote:
  > >
  > > > In D12321#252281 , @markg 
wrote:
  > > >
  > > > > I agree but not for a button that the user controls.
  > > >
  > > >
  > > > We already disable options where they do not make sense, see the Icon 
position setting which is only available in select view modes.
  > > >
  > > > The ability to preview could similarly be disabled where it does not 
make sense. I highly doubt this will cause confusion for users.
  > >
  > >
  > > Ohh, but i'm not against that :)
  > >  I merely don't want one button to be changed by both the user and some 
code logic.
  >
  >
  > It's the same for Icon position: Even if the user does not change from 
Above filename to Next to filename the code logic when changing the radio 
button (which would equal moving the zoom slider) to another view mode will 
change the icon position anyway, because for Detailed View you cannot have 
icons above the filename.
  >
  > This automatic logic is already there. You are simply objecting to not 
allowing previews for small icons. Yes, we will remove this possibility which 
was there before. No, I don't think this is bad, unless you can come up with 
reasons why anyone would want totally undecipherable previews.
  
  
  Then you make it impossible (ultimately, not with this patch though) to for 
instance browse through folders with small icons (say icon sets).
  That cannot possibly be desired...
  
  What file browser should people then use to view small icons?
  Or should they just never do that and be forced to use gwenview (or some 
alternative)?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  > Then you make it impossible (ultimately, not with this patch though) to for 
instance browse through folders with small icons (say icon sets).
  
  We have an explicit icon chooser dialog for this task, using the file dialog 
is not the recommended way for apps to select an icon. Also, as you may have 
noticed, the file dialog does not show previews of SVGs for any size, making 
your point moot.
  
  As for choosing PNG icons, you can simply set the icon size large enough 
(38px for me) to see the previews anyway (and make the icon large enough to be 
visible in the first place, I might add). This workaround is good enough, and 
should not prevent us from improving the handling for all other situations. 
Let's be honest here: How often do you want to select icons with <38px size, 
but cannot increase the size temporarily?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  > simply set the icon size large enough (38px for me)
  
  To add to that: The icon //will// be shown at its native size, the "icon 
size" in this case is only about the grid spacing!

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Alex Nemeth]

anemeth added a comment.


  In D12321#252299 , @rkflx wrote:
  
  > Also, as you may have noticed, the file dialog does not show previews of 
SVGs for any size, making your point moot.
  
  
  Actually with D12389  applied it will:
  
  F5819197: svg_prev.PNG 

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Nathaniel Graham]

ngraham added a comment.


  Sorry Mark, I can respect your opinion, but I just don't see the practical 
impact.
  
  First of all, SVG previews for icons didn't even work at all until yesterday, 
when Alex fixed it in D12389: Filepicker reads thumbs preview from Dolphin 
settings .
  
  Second of all, if you're browsing icons and you have previews on, without 
this patch the previews are unusably small:
  
  F5819200: Not very useful.png 
  
  For people who have this use case, switching to large icons view or 
increasing the size makes much more sense than attempting to distinguish 
previews at 16px. I think this line of objection is a tempest in a teapot.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12420: Make the warning text for deletion operations emphasize its permanency and irreversibility

[Nathaniel Graham]

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


  Use semantic markup tags

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D12420?vs=32748&id=32885

BRANCH
  more-serious-delete-text (branched from master)

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

AFFECTED FILES
  src/widgets/jobuidelegate.cpp

To: ngraham, #frameworks, #dolphin, elvisangelaccio
Cc: michaelh, bruns

D12420: Make the warning text for deletion operations emphasize its permanency and irreversibility

[Nathaniel Graham]

ngraham marked an inline comment as done.
ngraham added inline comments.

INLINE COMMENTS

> elvisangelaccio wrote in jobuidelegate.cpp:229
> Please use semantic markup and the `` tag instead of `\n`, see 
> https://api.kde.org/frameworks/ki18n/html/prg_guide.html#kuit_markup

Couldn't get `` working, so I hope `` tags are okay.

REPOSITORY
  R241 KIO

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

To: ngraham, #frameworks, #dolphin, elvisangelaccio
Cc: michaelh, bruns

D12420: Make the warning text for deletion operations emphasize its permanency and irreversibility

[Nathaniel Graham]

ngraham edited the test plan for this revision.

REPOSITORY
  R241 KIO

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

To: ngraham, #frameworks, #dolphin, elvisangelaccio
Cc: michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252299 , @rkflx wrote:
  
  > > Then you make it impossible (ultimately, not with this patch though) to 
for instance browse through folders with small icons (say icon sets).
  >
  > We have an explicit icon chooser dialog for this task, using the file 
dialog is not the recommended way for apps to select an icon. Also, as you may 
have noticed, the file dialog does not show previews of SVGs for any size, 
making your point moot.
  >
  > As for choosing PNG icons, you can simply set the icon size large enough 
(38px for me) to see the previews anyway. This workaround is good enough, and 
should not prevent us from improving the handling for all other situations. 
Let's be honest here: How often do you want to select icons with <38px size, 
but cannot increase the size temporarily?
  
  
  I think you mis-interpreted what i said which then caused @ngraham to reply 
with apparently that in mind which is also not as i intended :)
  
  I intended specifically what i said.
  **browse** a folder with lots of icons **like** an icon pack/theme. And yes, 
that is - sometimes - very handy to have!
  I said nothing about the view mode (i meant the grid view though, not the 
list view).
  
  In those cases where you just browse through a gazillion icons (nothing with 
an icon picker or selecting icons, i didn't say any of that) becomes impossible 
in your future patch.
  This patch makes it slightly more "inconvenient" to browse folders like that.
  
  As for SVG.. Not my words. png, jpg, any format really.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Nathaniel Graham]

ngraham added a comment.


  In D12321#252337 , @markg wrote:
  
  > In D12321#252299 , @rkflx wrote:
  >
  > > > Then you make it impossible (ultimately, not with this patch though) to 
for instance browse through folders with small icons (say icon sets).
  > >
  > > We have an explicit icon chooser dialog for this task, using the file 
dialog is not the recommended way for apps to select an icon. Also, as you may 
have noticed, the file dialog does not show previews of SVGs for any size, 
making your point moot.
  > >
  > > As for choosing PNG icons, you can simply set the icon size large enough 
(38px for me) to see the previews anyway. This workaround is good enough, and 
should not prevent us from improving the handling for all other situations. 
Let's be honest here: How often do you want to select icons with <38px size, 
but cannot increase the size temporarily?
  >
  >
  > I think you mis-interpreted what i said which then caused @ngraham to reply 
with apparently that in mind which is also not as i intended :)
  >
  > I intended specifically what i said.
  >  **browse** a folder with lots of icons **like** an icon pack/theme. And 
yes, that is - sometimes - very handy to have!
  >  I said nothing about the view mode (i meant the grid view though, not the 
list view).
  
  
  Browse... grid view... small size... previews... icons... so you want to be 
able to do this?
  
  F5819296: Small, not useful.png 

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252346 , @ngraham wrote:
  
  > In D12321#252337 , @markg wrote:
  >
  > > In D12321#252299 , @rkflx 
wrote:
  > >
  > > > > Then you make it impossible (ultimately, not with this patch though) 
to for instance browse through folders with small icons (say icon sets).
  > > >
  > > > We have an explicit icon chooser dialog for this task, using the file 
dialog is not the recommended way for apps to select an icon. Also, as you may 
have noticed, the file dialog does not show previews of SVGs for any size, 
making your point moot.
  > > >
  > > > As for choosing PNG icons, you can simply set the icon size large 
enough (38px for me) to see the previews anyway. This workaround is good 
enough, and should not prevent us from improving the handling for all other 
situations. Let's be honest here: How often do you want to select icons with 
<38px size, but cannot increase the size temporarily?
  > >
  > >
  > > I think you mis-interpreted what i said which then caused @ngraham to 
reply with apparently that in mind which is also not as i intended :)
  > >
  > > I intended specifically what i said.
  > >  **browse** a folder with lots of icons **like** an icon pack/theme. And 
yes, that is - sometimes - very handy to have!
  > >  I said nothing about the view mode (i meant the grid view though, not 
the list view).
  >
  >
  > Browse... grid view... small size... previews... icons... so you want to be 
able to do this?
  >
  > F5819296: Small, not useful.png 
  
  
  Sometimes, yes.
  Like when looking for which icon to use for another button in the application 
i'm making for my job for instance

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Nathaniel Graham]

ngraham added a comment.


  In D12321#252365 , @markg wrote:
  
  > > Browse... grid view... small size... previews... icons... so you want to 
be able to do this?
  > > 
  > > F5819296: Small, not useful.png 
  >
  > Sometimes, yes.
  >  Like when looking for which icon to use for another button in the 
application i'm making for my job for instance
  
  
  Are such tiny icons actually useful and distinguishable? Wouldn't it actually 
improve your productivity to increase the size of the icons and the window, 
such that you saw this instead?
  
  F5819375: Large, more useful.png 
  
  Why torture yourself with tiny icons in a tiny window?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252337 , @markg wrote:
  
  > In those cases where you just browse through a gazillion icons (nothing 
with an icon picker or selecting icons, i didn't say any of that) becomes 
impossible in your future patch.
  >  This patch makes it slightly more "inconvenient" to browse folders like 
that.
  
  
  What "future patch" are you referring to, though?
  
  As far as I've understood, we don't plan to prevent people from viewing 
thumbnails for tiny icons anywhere (as long as they select a reasonable/medium 
grid size).
  
  In fact, with D12306: Filepicker dialog proper grid icon layout 
 there probably won't be much of a 
difference between slider position with regard to grid spacing anyway, as "this 
patch improves the grid spacing in icons-on-top mode by making it looser for 
small icons", to give more room for the filename label.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12306: Improve grid icon layout in filepicker dialog

[Henrik Fehlauer]

rkflx retitled this revision from "Filepicker dialog proper grid icon layout" 
to "Improve grid icon layout in filepicker dialog".

REPOSITORY
  R241 KIO

BRANCH
  grid_layout (branched from master)

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

To: anemeth, #frameworks, #vdg, ngraham, rkflx
Cc: abetts, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252369 , @rkflx wrote:
  
  > In D12321#252337 , @markg wrote:
  >
  > > In those cases where you just browse through a gazillion icons (nothing 
with an icon picker or selecting icons, i didn't say any of that) becomes 
impossible in your future patch.
  > >  This patch makes it slightly more "inconvenient" to browse folders like 
that.
  >
  >
  > What "future patch" are you referring to, though?
  >
  > As far as I've understood, we don't plan to prevent people from viewing 
thumbnails for tiny icons anywhere (as long as they select a reasonable/medium 
grid size).
  >
  > In fact, with D12306: Improve grid icon layout in filepicker dialog 
 there probably won't be much of a 
difference between slider position with regard to grid spacing anyway, as "this 
patch improves the grid spacing in icons-on-top mode by making it looser for 
small icons", to give more room for the filename label.
  
  
  You said:
  
  > This automatic logic is already there. You are simply objecting to not 
allowing previews for small icons. Yes, we will remove this possibility which 
was there before.
  
  Which i interpreted as "previews for small images/icons won't be possible 
anymore in the future".
  Did i interpret that wrong?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252366 , @ngraham wrote:
  
  > In D12321#252365 , @markg wrote:
  >
  > > > Browse... grid view... small size... previews... icons... so you want 
to be able to do this?
  > > > 
  > > > F5819296: Small, not useful.png 
  > >
  > > Sometimes, yes.
  > >  Like when looking for which icon to use for another button in the 
application i'm making for my job for instance
  >
  >
  > Are such tiny icons actually useful and distinguishable? Wouldn't it 
actually improve your productivity to increase the size of the icons and the 
window, such that you saw this instead?
  >
  > F5819375: Large, more useful.png 
  >
  > Why torture yourself with tiny icons in a tiny window?
  
  
  Not always. Sometimes you want to see how they look at the actual size. How 
they are represented.
  The blown up way of looking at it (resized version) does not give you an 
accurate representation of how it will look like in the native size. Granted, 
this is very developer specific and what i usually do is first look at the 
blown up version. Then single out a few i might like followed by looking at the 
real sizes to determine which one to use. But regardless of that, it's great to 
be able to do that, i see no reason why we should lose that ability.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252372 , @markg wrote:
  
  > You said:
  >
  > > This automatic logic is already there. You are simply objecting to not 
allowing previews for small icons. Yes, we will remove this possibility which 
was there before.
  >
  > Which i interpreted as "previews for small images/icons won't be possible 
anymore in the future".
  >  Did i interpret that wrong?
  
  
  Indeed, we have to be careful with the terminology here:
  
  - "Icon size" mainly refers to the "Icon size" slider, which chooses how much 
space is available in the dialog per item/cell/file.
  - The size of an image, e.g. a photo, an icon or a word document, has nothing 
to do with this patch.
  
  For example, with 38px grid "icon size", you'll be able to see a 4000x3000 
photo as well as a 4x3 icon. With 12px grid "icon size", you won't see previews 
for either the photo or the tiny icon.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252374 , @markg wrote:
  
  > The blown up way of looking at it (resized version) does not give you an 
accurate representation of how it will look like in the native size.
  
  
  Have you actually tried the patch. Raster icons are not blown up, the are 
shown at their native size as long as it is smaller than the grid spacing (and 
the grid spacing is large enough to enable showing of previews).

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

Re: [kcoreaddons] src/lib: Revert "Warning--"

[Ivan Čukić]

Hi Ben,

Is it possible to have cgit.kde.org show commit hashes in the 'log'
tab (for example [1])?

As for the Laurent's patch, it looks quite sane, so I guess the failed
compilation for other platforms should be investigated further (I've
put Laurent in the TO: field because of this).

Cheers,
Ivan

[1] https://cgit.kde.org/kcoreaddons.git/log/


On Fri, Apr 20, 2018 at 10:49 AM, Ben Cooksley  wrote:
> Git commit bf353edc42fdecf9fda34a024ba7cabcd0efaf68 by Ben Cooksley.
> Committed on 20/04/2018 at 08:47.
> Pushed by bcooksley into branch 'master'.
>
> Revert "Warning--"
>
> The changes in these commits fail on all platforms aside from Linux, breaking 
> the FreeBSD, Android and Windows builds.
>
> CCMAIL: kde-frameworks-devel@kde.org
>
> This reverts commit 6c27d32fd88387a399955e4497eb976bffc0780e.
>
> M  +1-1src/lib/io/kdirwatch.h
> M  +1-1src/lib/jobs/kjobtrackerinterface.h
> M  +0-1src/lib/kaboutdata.cpp
> M  +2-2src/lib/util/kformatprivate.cpp
>
> https://commits.kde.org/kcoreaddons/bf353edc42fdecf9fda34a024ba7cabcd0efaf68
>
> diff --git a/src/lib/io/kdirwatch.h b/src/lib/io/kdirwatch.h
> index d25f2e9..e0de0b6 100644
> --- a/src/lib/io/kdirwatch.h
> +++ b/src/lib/io/kdirwatch.h
> @@ -86,7 +86,7 @@ public:
>   * is added.
>   * @param parent the parent of the QObject (or 0 for parent-less 
> KDataTools)
>   */
> -explicit KDirWatch(QObject *parent = nullptr);
> +KDirWatch(QObject *parent = nullptr);
>
>  /**
>   * Destructor.
> diff --git a/src/lib/jobs/kjobtrackerinterface.h 
> b/src/lib/jobs/kjobtrackerinterface.h
> index 4c76ca9..f47dfc9 100644
> --- a/src/lib/jobs/kjobtrackerinterface.h
> +++ b/src/lib/jobs/kjobtrackerinterface.h
> @@ -41,7 +41,7 @@ public:
>   *
>   * @param parent the parent object
>   */
> -explicit KJobTrackerInterface(QObject *parent = nullptr);
> +KJobTrackerInterface(QObject *parent = nullptr);
>
>  /**
>   * Destroys a KJobTrackerInterface
> diff --git a/src/lib/kaboutdata.cpp b/src/lib/kaboutdata.cpp
> index bf4e505..194becf 100644
> --- a/src/lib/kaboutdata.cpp
> +++ b/src/lib/kaboutdata.cpp
> @@ -286,7 +286,6 @@ QString KAboutLicense::text() const
>  result = d->_licenseText;
>  break;
>  }
> -Q_FALLTHROUGH()
>  // fall through
>  default:
>  result += QCoreApplication::translate(
> diff --git a/src/lib/util/kformatprivate.cpp b/src/lib/util/kformatprivate.cpp
> index 3e11c84..c64917d 100644
> --- a/src/lib/util/kformatprivate.cpp
> +++ b/src/lib/util/kformatprivate.cpp
> @@ -372,7 +372,7 @@ QString KFormatPrivate::formatRelativeDate(const QDate 
> &date, QLocale::FormatTyp
>  return tr("Invalid date", "used when a relative date string can't be 
> generated because the date is invalid");
>  }
>
> -const qint64 daysTo = QDate::currentDate().daysTo(date);
> +const int daysTo = QDate::currentDate().daysTo(date);
>  if (daysTo > 7 || daysTo < -7) {
>  return m_locale.toString(date, format);
>  }
> @@ -426,7 +426,7 @@ QString KFormatPrivate::formatRelativeDate(const QDate 
> &date, QLocale::FormatTyp
>
>  QString KFormatPrivate::formatRelativeDateTime(const QDateTime &dateTime, 
> QLocale::FormatType format) const
>  {
> -const qint64 daysTo = QDate::currentDate().daysTo(dateTime.date());
> +int daysTo = QDate::currentDate().daysTo(dateTime.date());
>  if (daysTo > 7 || daysTo < -7) {
>  return m_locale.toString(dateTime, format);
>  }



-- 
KDE, ivan.cu...@kde.org, http://cukic.co/
gpg key fingerprint: 292F 9B5C 5A1B 2A2F 9CF3  45DF C9C5 77AF 0A37 240A

Re: [kcoreaddons] src/lib: Revert "Warning--"

[Ivan Čukić]

Sorry for the noise, saw that the patch was fixed and committed again. Gah...

D12321: Hide file preview when icon is too small

[Mark Gaiser]

markg added a comment.


  In D12321#252393 , @rkflx wrote:
  
  > In D12321#252374 , @markg wrote:
  >
  > > The blown up way of looking at it (resized version) does not give you an 
accurate representation of how it will look like in the native size.
  >
  >
  > Have you actually tried the patch? Raster icons are not blown up, they are 
shown at their native size as long as it is smaller than the grid spacing (and 
the grid spacing is large enough to enable showing of previews).
  
  
  I've not tried this patch nor the svg patch.
  The perfect video of this patch clearly shows me what i need to see (big pros 
for that btw!).
  The svg patch unlikely influences my png icons ;)
  
  My comment was based on what i see in an icon folder right in front of me at 
this very moment.
  16x16 icons are scaled to whatever the zoom level is (which is fine imho). 
These icons are png ones.

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Nathaniel Graham]

ngraham added a comment.


  In D12321#252421 , @markg wrote:
  
  > My comment was based on what i see in an icon folder right in front of me 
at this very moment.
  >  16x16 icons are scaled to whatever the zoom level is (which is fine imho). 
These icons are png ones.
  
  
  And the 16x16 png icons with previews are actually distinguishable and 
useful? Can you share a screenshot?

REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D10078: Add separate lib KF5::DBusRunner

[Friedrich W . H . Kossebau]

kossebau commandeered this revision.
kossebau edited reviewers, added: davidedmundson; removed: kossebau.

REPOSITORY
  R308 KRunner

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

To: kossebau, broulik, davidedmundson
Cc: bruns, michaelh, ngraham, #frameworks

D11925: Add "SkipSwitcher" to API

[Martin Flöser]

graesslin added a comment.


  There is one more file which need changes. In src/client/registry.cpp you 
need to increase the version numbers of the two changed protocols. Adding a new 
request can be really cumbersome.

INLINE COMMENTS

> plasmashell_interface.cpp:53
>  
>  const quint32 PlasmaShellInterface::Private::s_version = 4;
>  

you need to increase the version number.

> plasmashell_interface.cpp:168
>  setSkipTaskbarCallback,
> +setSkipSwitcherCallback,
>  panelAutoHideHideCallback,

This is at the wrong position. It needs to be the last entry in the list. That 
might be your compile problem you mentioned in the KWin request.

> plasmawindowmanagement_interface.cpp:122
>  
>  const quint32 PlasmaWindowManagementInterface::Private::s_version = 7;
>  

you need to increase the version number.

REPOSITORY
  R127 KWayland

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

To: sharvey, hein, graesslin
Cc: davidedmundson, #plasma, graesslin, #frameworks, michaelh, bruns

D11925: Add "SkipSwitcher" to API

[Scott Harvey]

sharvey updated this revision to Diff 32906.
sharvey added a comment.


  - Update interface version number; move setSkipSwitcherCallback to end of 
struct

REPOSITORY
  R127 KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D11925?vs=31311&id=32906

BRANCH
  arcpatch-D11925

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

AFFECTED FILES
  autotests/client/test_plasma_window_model.cpp
  autotests/client/test_plasmashell.cpp
  autotests/client/test_wayland_windowmanagement.cpp
  src/client/plasmashell.cpp
  src/client/plasmashell.h
  src/client/plasmawindowmanagement.cpp
  src/client/plasmawindowmanagement.h
  src/client/plasmawindowmodel.cpp
  src/client/plasmawindowmodel.h
  src/client/protocols/plasma-shell.xml
  src/client/protocols/plasma-window-management.xml
  src/server/plasmashell_interface.cpp
  src/server/plasmashell_interface.h
  src/server/plasmawindowmanagement_interface.cpp
  src/server/plasmawindowmanagement_interface.h
  tests/plasmasurfacetest.cpp

To: sharvey, hein, graesslin
Cc: davidedmundson, #plasma, graesslin, #frameworks, michaelh, bruns

D11925: Add "SkipSwitcher" to API

[Scott Harvey]

sharvey marked 3 inline comments as done.
sharvey added a comment.


  Changes made. KWayland compiles fine now. Thank you.

REPOSITORY
  R127 KWayland

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

To: sharvey, hein, graesslin
Cc: davidedmundson, #plasma, graesslin, #frameworks, michaelh, bruns

D12321: Hide file preview when icon is too small

[Henrik Fehlauer]

rkflx added a comment.


  In D12321#252421 , @markg wrote:
  
  > I've not tried this patch nor the svg patch.
  
  
  Maybe you should, to get a feel for how nice this works!
  
  > My comment was based on what i see in an icon folder right in front of me 
at this very moment.
  >  16x16 icons are scaled to whatever the zoom level is (which is fine imho). 
These icons are png ones.
  
  Are you sure? For me small icons do not scale up, both without and with the 
patch:
  
  F5819647: KIO-16px-icons-before-after.webm 


REPOSITORY
  R241 KIO

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

To: anemeth, #vdg, #frameworks, ngraham, rkflx, #dolphin, markg
Cc: markg, xyquadrat, sharvey, rkflx, ngraham, #frameworks, michaelh, bruns

D12477: Add unit test to see that :/ files can work

[Sune Vuorela]

svuorela created this revision.
svuorela added reviewers: dfaure, kossebau, Frameworks.
Restricted Application added a project: Frameworks.
svuorela requested review of this revision.

REVISION SUMMARY
  I wasn't sure if :/foo stuff would work, so I tried writing a unit test to 
help me. Let's submit it. It passes

TEST PLAN
  Unit test still passes.

REPOSITORY
  R306 KParts

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

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/parttest.cpp
  autotests/parttest.h

To: svuorela, dfaure, kossebau, #frameworks
Cc: michaelh, bruns

D12320: add ability to read embedded cover files

[Matthieu Gallien]

mgallien added a comment.


  In D12320#249998 , @astippich 
wrote:
  
  > In D12320#249982 , @michaelh 
wrote:
  >
  > > -2
  > >  https://cgit.kde.org/ffmpegthumbs.git/ should be useable, not sure 
though.
  >
  >
  > It is also disqualified by the fact that it is not in frameworks. I think a 
nice solution is to implement a separate "extractor" that is not an extractor 
plugin like taglib, epub, etc. but implemented like the xattr tags 
(usermetadata) as a separate, exported class. This way, baloo doesn't have to 
be changed in any way and still applications using kfilemetadata can query the 
cover files specifically.
  
  
  How does behave Baloo if you add properties of type EmbeddedPicture ?
  Is it not a good idea to fix Baloo to not index everything but only 
searchable properties (like text and numeric properties and ignore binary data) 
?
  
  The current way to manage user rating mush have had a good rationale for its 
current design but I have failed to understand it.
  It would also look quite odd to have a particular way to fetch properties of 
type EmbeddedPicture.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, michaelh
Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun

D12477: Add unit test to see that :/ files can work

[Friedrich W . H . Kossebau]

kossebau added a comment.


  It passes only by pure chance as NotepadPart uses QFile, which understands 
such an url. So the value of that new autptest is questionable, as this is not 
testing any API promise.
  
  For `ReadOnlyPart::localFilePath()` it says: "Returns the local file path 
associated with this part. " So a :/ resource url is rather out of scope, at 
least by traditional meaning of "local file path". Any KParts plugins which 
pass the file path on to non-QFile-using code will fall flat on such qrc path.

REPOSITORY
  R306 KParts

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

To: svuorela, dfaure, kossebau, #frameworks
Cc: michaelh, bruns

D12156: implement reading of rating tag

[Matthieu Gallien]

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


  In D12156#249994 , @astippich 
wrote:
  
  > In D12156#249977 , @michaelh 
wrote:
  >
  > > In D12156#249971 , @astippich 
wrote:
  > >
  > > > In D12156#249951 , @michaelh 
wrote:
  > > >
  > > > > It's for elisa I guess, could you please elaborate how POPM/RATING is 
going to be used and why xattr are not applicable?
  > > >
  > > >
  > > > It will be used as a fallback when there is no xattr rating set or 
available (e.g. on Windows) so that users who have rated their music with other 
players can still see their previous ratings. 
  > > >  It will also useful for managing ratings on other platforms when 
writing support is added.
  > >
  > >
  > > I that case I would suggest to use xattr only on systems that support it, 
and use POPM/RATING on those that don't. I afraid users will find it confusing 
to have two ways of rating a file. Or is rating via dolphin/baloo-widgets not 
planned?
  > >  Because extractors are called in sequence it would also be possible to 
create a dedicate taglibRatingExtractor (much easier to apply build 
conditionals).
  >
  >
  > We still need the ability to read the tag, since users expect to see the 
rating in music players.
  >  For baloo-widgets I created D12157 
  
  
  If I have correctly understood the ideas behind the conception of Baloo, we 
should probably prefer to store the rating with a "native" solution instead of 
the xattr one that is not portable outside of software using KFileMetaData.
  
  We have to stay compatible with older versions of KFileMetaData. So we should 
push the same rating to both properties and try to read it from both properties 
in the cases where only one exists.
  
  Could you try to modify your patch to do that ?

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, michaelh
Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun

D10078: Add separate lib KF5::DBusRunner

[Friedrich W . H . Kossebau]

kossebau updated this revision to Diff 32916.
kossebau added a comment.


  Updating with proposed further massaging of the API
  
  - changed some class/method names to closely follow KRunner terms: 
(RunnerContext, query)
  - moved RunnerContext into separate header (for one per class)
  - moving submit/cancel methods back to AbstractRunner
  
  Keeping RunnerContext a pure data container and AbstractRunner as responsible
  for creating and consuming these objects feels more balanced and means less
  spreading of responsibilities/functionality.
  
  The auto-submit in the destructor of RunnerContext left a feel of lack of
  control to the API user given the passing of RunnerContext as sharedpointer.
  Also reading the code and seeing only startMatching, one would wonder how
  actually the matching is completed. Having to read up in the API dox might
  not make up for the otherwise unneeded additional call.
  
  One challenge I found when tinkering around with this:
  a D-Bus runner could in theory receive multiple calls at the same time, from
  one or multiple processes. While the RunnerContext now would allow handling
  multiple overlapping requests easily, I have yet to get an idea how/if
  overlapping D-Bus calls work in general, with QtDBus in detail and even more
  how the D-Bus proxy krunner acts when a newer query is asked for (e.g. on
  quick typing). The current code at least should be prepared in theory to
  some bit.

REPOSITORY
  R308 KRunner

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10078?vs=31871&id=32916

BRANCH
  kdbusrunnerlib2

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

AFFECTED FILES
  CMakeLists.txt
  KF5DBusRunnerConfig.cmake.in
  autotests/CMakeLists.txt
  autotests/testremoterunner.cpp
  autotests/testremoterunner.h
  src/CMakeLists.txt
  src/dbusrunner/CMakeLists.txt
  src/dbusrunner/abstractrunner.cpp
  src/dbusrunner/abstractrunner.h
  src/dbusrunner/abstractrunner_p.cpp
  src/dbusrunner/abstractrunner_p.h
  src/dbusrunner/action.h
  src/dbusrunner/dbusadaptor.cpp
  src/dbusrunner/dbusadaptor_p.h
  src/dbusrunner/querymatch.h
  src/dbusrunner/runnercontext.cpp
  src/dbusrunner/runnercontext.h
  src/dbusrunner/runnercontext_p.h
  src/querymatch.h

To: kossebau, broulik, davidedmundson
Cc: bruns, michaelh, ngraham, #frameworks

D10078: Add separate lib KF5::DBusRunner

[David Edmundson]

davidedmundson requested changes to this revision.
davidedmundson added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> abstractrunner_p.h:46
> +
> +void cancelMatching(const RunnerContext::Ptr &context);
> +void finishMatching(const RunnerContext::Ptr &context);

This undermines the advantages of my changes. 
Its not object oriented anymore.

REPOSITORY
  R308 KRunner

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

To: kossebau, broulik, davidedmundson
Cc: bruns, michaelh, ngraham, #frameworks

D10078: Add separate lib KF5::DBusRunner

[Friedrich W . H . Kossebau]

kossebau added inline comments.

INLINE COMMENTS

> davidedmundson wrote in abstractrunner_p.h:46
> This undermines the advantages of my changes. 
> Its not object oriented anymore.

I tried to reason in the update message why I think after having tried that API 
that some other OO approach feels better to me. Any chance you missed that, 
given you do not refer to the arguments given there here?

REPOSITORY
  R308 KRunner

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

To: kossebau, broulik, davidedmundson
Cc: bruns, michaelh, ngraham, #frameworks

D12156: implement reading of rating tag

[Stefan Brüns]

bruns added a comment.


  In D12156#252575 , @mgallien wrote:
  
  > In D12156#249994 , @astippich 
wrote:
  >
  > > In D12156#249977 , @michaelh 
wrote:
  > >
  > > > In D12156#249971 , 
@astippich wrote:
  > > >
  > > > > In D12156#249951 , 
@michaelh wrote:
  > > > >
  > > > > > It's for elisa I guess, could you please elaborate how POPM/RATING 
is going to be used and why xattr are not applicable?
  > > > >
  > > > >
  > > > > It will be used as a fallback when there is no xattr rating set or 
available (e.g. on Windows) so that users who have rated their music with other 
players can still see their previous ratings. 
  > > > >  It will also useful for managing ratings on other platforms when 
writing support is added.
  > > >
  > > >
  > > > I that case I would suggest to use xattr only on systems that support 
it, and use POPM/RATING on those that don't. I afraid users will find it 
confusing to have two ways of rating a file. Or is rating via 
dolphin/baloo-widgets not planned?
  > > >  Because extractors are called in sequence it would also be possible to 
create a dedicate taglibRatingExtractor (much easier to apply build 
conditionals).
  > >
  > >
  > > We still need the ability to read the tag, since users expect to see the 
rating in music players.
  > >  For baloo-widgets I created D12157 
  >
  >
  > If I have correctly understood the ideas behind the conception of Baloo, we 
should probably prefer to store the rating with a "native" solution instead of 
the xattr one that is not portable outside of software using KFileMetaData.
  >
  > We have to stay compatible with older versions of KFileMetaData. So we 
should push the same rating to both properties and try to read it from both 
properties in the cases where only one exists.
  >
  > Could you try to modify your patch to do that ?
  
  
  Your interpretation is correct, Baloo works as a cache, storing data in a 
normalized form, to speed up lookup. It is not a permanent data store.
  
  Storing/updating metadata inside the file has the benefit it works 
independent of the filesystem capabities. On the other hand, one risks damaging 
the file, and synchronization between devices may become more difficult.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, michaelh
Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun

D12320: add ability to read embedded cover files

[Stefan Brüns]

bruns added a comment.


  In D12320#252547 , @mgallien wrote:
  
  > In D12320#249998 , @astippich 
wrote:
  >
  > > In D12320#249982 , @michaelh 
wrote:
  > >
  > > > -2
  > > >  https://cgit.kde.org/ffmpegthumbs.git/ should be useable, not sure 
though.
  > >
  > >
  > > It is also disqualified by the fact that it is not in frameworks. I think 
a nice solution is to implement a separate "extractor" that is not an extractor 
plugin like taglib, epub, etc. but implemented like the xattr tags 
(usermetadata) as a separate, exported class. This way, baloo doesn't have to 
be changed in any way and still applications using kfilemetadata can query the 
cover files specifically.
  >
  >
  > How does behave Baloo if you add properties of type EmbeddedPicture ?
  >  Is it not a good idea to fix Baloo to not index everything but only 
searchable properties (like text and numeric properties and ignore binary data) 
?
  >
  > The current way to manage user rating mush have had a good rationale for 
its current design but I have failed to understand it.
  >  It would also look quite odd to have a particular way to fetch properties 
of type EmbeddedPicture.
  
  
  It may be useful to store some "EmbeddedPicture exists" flag inside Baloo. It 
should store strings, numeric values, dates, but as it has to handle each basic 
type individually (for storing data, parsing queries and executing queries) 
bytearrays should be ignored.

REPOSITORY
  R286 KFileMetaData

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

To: astippich, mgallien, michaelh
Cc: bruns, #frameworks, ashaposhnikov, michaelh, astippich, spoorun

D12311: Align lock icon with bold message text; reduce overall size of dialog

[Stefan Brüns]

bruns added a comment.


  In D12311#252212 , @stikonas wrote:
  
  > In D12311#252165 , @bruns wrote:
  >
  > > Resizing: 
http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Partition.html#gdbus-method-org-freedesktop-UDisks2-Partition.Resize
  >
  >
  > Does not work well yet, just a few errors where KPM succeeds:
  >
  > - Cannot resize btrfs filesystem on /dev/sdb1: (null) filesystem 'btrfs' is 
not supported.
  
  
  Wrong, tested, works. You have to use 
http://storaged.org/doc/udisks2-api/latest/gdbus-org.freedesktop.UDisks2.Filesystem.BTRFS.html

REPOSITORY
  R121 Policykit (Polkit) KDE Agent

BRANCH
  align-lock-icon (branched from master)

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

To: sharvey, davidedmundson, ngraham, abetts, #frameworks
Cc: stikonas, bruns, ltoscano, broulik, davidedmundson, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, 
mart

KDE CI: Frameworks kio kf5-qt5 FreeBSDQt5.9 - Build # 209 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20FreeBSDQt5.9/209/
 Project:
Frameworks kio kf5-qt5 FreeBSDQt5.9
 Date of build:
Tue, 24 Apr 2018 03:26:39 +
 Build duration:
5 min 45 sec and counting
   JUnit Tests
  Name: (root) Failed: 6 test(s), Passed: 51 test(s), Skipped: 0 test(s), Total: 57 test(s)Failed: TestSuite.kiocore-jobtestFailed: TestSuite.kiocore-kmountpointtestFailed: TestSuite.kiofilewidgets-kfileplacesmodeltestFailed: TestSuite.kiofilewidgets-kfileplacesviewtestFailed: TestSuite.kiowidgets-kdirlistertestFailed: TestSuite.kiowidgets-kdirmodeltest

KDE CI: Frameworks kio kf5-qt5 SUSEQt5.10 - Build # 231 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20SUSEQt5.10/231/
 Project:
Frameworks kio kf5-qt5 SUSEQt5.10
 Date of build:
Tue, 24 Apr 2018 03:26:39 +
 Build duration:
8 min 8 sec and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 56 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: TestSuite.kiocore-jobtestFailed: TestSuite.kiofilewidgets-kfileplacesmodeltest
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report64%
(23/36)65%
(286/442)65%
(286/442)50%
(29907/59686)36%
(17644/48993)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests97%
(71/73)97%
(71/73)81%
(7398/9127)42%
(4549/10857)autotests.http100%
(9/9)100%
(9/9)100%
(586/587)59%
(217/368)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(180/198)67%
(63/94)src100%
(1/1)100%
(1/1)100%
(5/5)75%
(3/4)src.core79%
(94/119)79%
(94/119)55%
(7897/14351)48%
(4668/9749)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets79%
(31/39)79%
(31/39)49%
(3872/7867)33%
(1632/4938)src.gui100%
(2/2)100%
(2/2)95%
(104/110)77%
(57/74)src.ioslaves.file100%
(5/5)100%
(5/5)52%
(521/1008)42%
(417/1004)src.ioslaves.file.kauth0%
(0/3)0%
(0/3)0%
(0/104)0%
(0/75)src.ioslaves.ftp0%
(0/2)0%
(0/2)0%
(0/1365)0%
(0/1515)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/184)src.ioslaves.http89%
(8/9)89%
(8/9)41%
(1783/4338)35%
(1375/3979)src.ioslaves.http.kcookiejar33%
(2/6)33%
(2/6)47%
(631/1333)55%
(649/1174)src.ioslaves.remote100%
(2/2)100%
(2/2)28%
(72/258)8%
(19/242)src.ioslaves.remote.kdedmodule0%
(0/4)0%
(0/4)0%
(0/14)100%
(0/0)src.ioslaves.telnet0%
(0/1)0%
(0/1)0%
(0/43)0%
(0/30)src.ioslaves.trash64%
(7/11)64%
   

KDE CI: Frameworks kio kf5-qt5 SUSEQt5.9 - Build # 80 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks%20kio%20kf5-qt5%20SUSEQt5.9/80/
 Project:
Frameworks kio kf5-qt5 SUSEQt5.9
 Date of build:
Tue, 24 Apr 2018 03:26:39 +
 Build duration:
10 min and counting
   JUnit Tests
  Name: (root) Failed: 2 test(s), Passed: 56 test(s), Skipped: 0 test(s), Total: 58 test(s)Failed: TestSuite.kiocore-jobtestFailed: TestSuite.kiofilewidgets-kfileplacesmodeltest
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report64%
(23/36)65%
(286/442)65%
(286/442)50%
(29974/59687)36%
(17674/48989)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests97%
(71/73)97%
(71/73)81%
(7398/9127)42%
(4552/10857)autotests.http100%
(9/9)100%
(9/9)100%
(586/587)59%
(217/368)autotests.kcookiejar100%
(1/1)100%
(1/1)91%
(180/198)67%
(63/94)src100%
(1/1)100%
(1/1)100%
(5/5)75%
(3/4)src.core79%
(94/119)79%
(94/119)55%
(7958/14352)48%
(4697/9753)src.core.kssl100%
(1/1)100%
(1/1)40%
(35/88)50%
(3/6)src.filewidgets79%
(31/39)79%
(31/39)49%
(3874/7867)33%
(1634/4938)src.gui100%
(2/2)100%
(2/2)95%
(104/110)77%
(57/74)src.ioslaves.file100%
(5/5)100%
(5/5)52%
(521/1008)42%
(417/1004)src.ioslaves.file.kauth0%
(0/3)0%
(0/3)0%
(0/104)0%
(0/75)src.ioslaves.ftp0%
(0/2)0%
(0/2)0%
(0/1365)0%
(0/1515)src.ioslaves.help0%
(0/5)0%
(0/5)0%
(0/247)0%
(0/184)src.ioslaves.http89%
(8/9)89%
(8/9)41%
(1788/4338)35%
(1373/3979)src.ioslaves.http.kcookiejar33%
(2/6)33%
(2/6)47%
(630/1333)55%
(648/1174)src.ioslaves.remote100%
(2/2)100%
(2/2)28%
(72/258)8%
(19/242)src.ioslaves.remote.kdedmodule0%
(0/4)0%
(0/4)0%
(0/14)100%
(0/0)src.ioslaves.telnet0%
(0/1)0%
(0/1)0%
(0/43)0%
(0/30)src.ioslaves.trash64%
(7/11)64%