Re: Review Request 129259: Fix the buffersize in certain situations.

2016-10-25 Thread Jonathan Doman

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




src/ioslaves/file/file.cpp (line 790)


I don't think we should use buff.st_size at all. We now know that on 
"virtual" filesystems, the link's reported size is basically useless for this 
purpose. In the case I reported in the bug, we are allocating 2 GiB just to 
read a measly file path.

We should just always start with a small constant (maybe 1024 is fine), and 
then increase as necessary.


- Jonathan Doman


On Oct. 25, 2016, 9:51 a.m., taro yamada wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129259/
> ---
> 
> (Updated Oct. 25, 2016, 9:51 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 369275
> https://bugs.kde.org/show_bug.cgi?id=369275
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Currently, KIO uses lstat to get the buffersize for readlink.
> But in certain situations, it returns inappropriate value.
> 
> For example, "/proc/self" or "/sys/bus/cpu/devices/*" returns its size is 0 , 
> and then readlink fails with EINVAL.(so link won't be shown in kde 
> application.)
> TMSU seems it returns its target's actual filesize insted of the link's 
> filesize itself.
> 
> This patch changes the buffersize to 1024 bytes if it is 0.
> And later truncate it to actual size.
> 
> 
> Diffs
> -
> 
>   src/ioslaves/file/file.cpp 8b17d31 
> 
> Diff: https://git.reviewboard.kde.org/r/129259/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> taro yamada
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Matthew Dawson


> On Oct. 24, 2016, 7 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?
> 
> Albert Astals Cid wrote:
> > Lets stick to the established commands over time where Shift+del is 
> permanent delete
> 
> I don't know man, i already cited wikipedia proving you wrong, what more 
> do you want?
> 
> Luigi Toscano wrote:
> IMHO the poll should be better placed for example on forums.kde.org, or 
> woth some tool that does not require a google account.
> 
> That said, even if different, we should have a global shortcut for 
> permanent deletion as now, or we will end up with bugs to have all apps 
> provide the same shortcut anyway.
> 
> Heiko Tietze wrote:
> >IMHO the poll should be better placed for example on forums.kde.org
> 
> Don't understand a quick poll like this as a final and definite survey. 
> It's quickly done, addresses a lot of average users (guess more than on the 
> forums or via blog->planet), and adds one more insight.
> 
> Mark Gaiser wrote:
> Hi Albert,
> 
> You said "DeleteFile is Shift+Delete by default" which lead me to think 
> that pressing "delete" was going to do that action. Sorry my bad.
> 
> Regarding the shift+delete and wikipedia. I highly doubt what wikipedia 
> says is true. I know with 100% certainty that shift+delete is permanently 
> delete on windows, yet on that wikipedia page shift+delete is described as 
> cut shortcut. That is not right!
> 
> Albert Astals Cid wrote:
> > Regarding the shift+delete and wikipedia. I highly doubt what wikipedia 
> says is true. I know with 100% certainty that shift+delete is permanently 
> delete on windows, yet on that wikipedia page shift+delete is described as 
> cut 

Re: Review Request 128944: Reduce temporary allocations in the DesktopFileParser

2016-10-25 Thread Aleix Pol Gonzalez

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

(Updated Oct. 26, 2016, 2:54 a.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

While analising plasmashell under heaptrack, one of the sore spots is temporary 
allocations within DesktopFileParser. This improves the situation by:

* Only converting to QString/utf8 once.
* Using QStringRef instead of fully splitting QString to parse them.


Diffs
-

  src/lib/plugin/desktopfileparser.cpp 2eb198d 
  src/lib/plugin/desktopfileparser_p.h c61b297 

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


Testing
---

tests still pass, plasma still works normally.

heaptrack plasmashell:

after:
allocations:4169312
leaked allocations: 83225
temporary allocations:  606902

before:
allocations:4680691
leaked allocations: 84825
temporary allocations:  819292


Thanks,

Aleix Pol Gonzalez



Re: Review Request 129257: [KNewStuff] Make it possible to query installed entries

2016-10-25 Thread Aleix Pol Gonzalez

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

(Updated Oct. 26, 2016, 1:57 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Jeremy Whiting.


Changes
---

Submitted with commit 63a39fda5087db4ddf3128c2908635c36a5d58f8 by Aleix Pol to 
branch master.


Repository: knewstuff


Description
---

Much like with updates. It will be useful to be able to query for installed 
packages without having to look them all up.


Diffs
-

  src/core/engine.cpp ab47405 
  src/core/engine_p.h 11571bf 
  src/downloadmanager.h 39769f3 
  src/downloadmanager.cpp 8ce813b 

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


Testing
---

Works on my newbackends branch for discover where I refactored the internals to 
be more async, there we can just fetch the installed packages at start without 
having to fetch everything.


Thanks,

Aleix Pol Gonzalez



Re: Review Request 129261: Hide the "Show Menu Bar" action if all the menubars are native

2016-10-25 Thread Aleix Pol Gonzalez

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



+1 pretty cool!

- Aleix Pol Gonzalez


On Oct. 26, 2016, 12:15 a.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129261/
> ---
> 
> (Updated Oct. 26, 2016, 12:15 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Some applications have a "Show Menu Bar" action that is a bit silly on 
> systems where the menubar is part of the shell (for example Unity 7).
> 
> This patch attempts to fix it by iterating all the main windows when they are 
> shown and if all the menubars of all mainwindows are native, then hides the 
> show menu bar action (basically erasing it from existence).
> 
> It's not the nicest of the codes and probably has some edge cases but works 
> on the general case so i think it's worth the effort.
> 
> 
> Diffs
> -
> 
>   src/kstandardaction.cpp 89d011e 
> 
> Diff: https://git.reviewboard.kde.org/r/129261/diff/
> 
> 
> Testing
> ---
> 
> Tried konsole, kate and dolphin under Unity 7 on Ubuntu 16.10
> 
> konsole and kate work fine (i.e. the action is gone from the menus and all is 
> good)
> 
> dolphin is not 100% "perfectly behabed" (i.e. the "control" toolbar item is 
> supposed to not be shown when menubars are shown and in this case it's shown) 
> but it's not a regression and imho it's the dolphin code being a bit weird (i 
> can propose a patch for it if this gets accepted)
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>



Review Request 129261: Hide the "Show Menu Bar" action if all the menubars are native

2016-10-25 Thread Albert Astals Cid

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

Review request for KDE Frameworks.


Repository: kconfigwidgets


Description
---

Some applications have a "Show Menu Bar" action that is a bit silly on systems 
where the menubar is part of the shell (for example Unity 7).

This patch attempts to fix it by iterating all the main windows when they are 
shown and if all the menubars of all mainwindows are native, then hides the 
show menu bar action (basically erasing it from existence).

It's not the nicest of the codes and probably has some edge cases but works on 
the general case so i think it's worth the effort.


Diffs
-

  src/kstandardaction.cpp 89d011e 

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


Testing
---

Tried konsole, kate and dolphin under Unity 7 on Ubuntu 16.10

konsole and kate work fine (i.e. the action is gone from the menus and all is 
good)

dolphin is not 100% "perfectly behabed" (i.e. the "control" toolbar item is 
supposed to not be shown when menubars are shown and in this case it's shown) 
but it's not a regression and imho it's the dolphin code being a bit weird (i 
can propose a patch for it if this gets accepted)


Thanks,

Albert Astals Cid



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

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/246/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 20:59:16 +
Build duration: 21 min

CHANGE SET
Revision 9f6b69237c299cabff1427da54768624545e1943 by David Edmundson: (Support 
non integer scale factors in KFileDelegate)
  change: edit src/widgets/kfileitemdelegate.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 270/340 (79%)CLASSES 270/340 (79%)LINE 29202/51369 
(57%)CONDITIONAL 15955/38081 (42%)

By packages
  
autotests
FILES 66/66 (100%)CLASSES 66/66 (100%)LINE 7789/8113 
(96%)CONDITIONAL 4346/8494 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 96/116 (83%)CLASSES 96/116 (83%)LINE 7801/14137 
(55%)CONDITIONAL 4259/9067 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 25/36 (69%)CLASSES 25/36 (69%)LINE 3375/7561 
(45%)CONDITIONAL 1246/4383 (28%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 434/832 (52%)CONDITIONAL 
326/719 (45%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1763/3783 
(47%)CONDITIONAL 1259/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 239/268 (89%)CONDITIONAL 
333/414 (80%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3590/10953 
(33%)CONDITIONAL 1717/6944 (25%)

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

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/246/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 20:59:16 +
Build duration: 21 min

CHANGE SET
Revision 9f6b69237c299cabff1427da54768624545e1943 by David Edmundson: (Support 
non integer scale factors in KFileDelegate)
  change: edit src/widgets/kfileitemdelegate.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 270/340 (79%)CLASSES 270/340 (79%)LINE 29202/51369 
(57%)CONDITIONAL 15955/38081 (42%)

By packages
  
autotests
FILES 66/66 (100%)CLASSES 66/66 (100%)LINE 7789/8113 
(96%)CONDITIONAL 4346/8494 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 96/116 (83%)CLASSES 96/116 (83%)LINE 7801/14137 
(55%)CONDITIONAL 4259/9067 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 25/36 (69%)CLASSES 25/36 (69%)LINE 3375/7561 
(45%)CONDITIONAL 1246/4383 (28%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 434/832 (52%)CONDITIONAL 
326/719 (45%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1763/3783 
(47%)CONDITIONAL 1259/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 239/268 (89%)CONDITIONAL 
333/414 (80%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3590/10953 
(33%)CONDITIONAL 1717/6944 (25%)

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

2016-10-25 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/248/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 20:59:17 +
Build duration: 20 min

CHANGE SET
Revision 9f6b69237c299cabff1427da54768624545e1943 by David Edmundson: (Support 
non integer scale factors in KFileDelegate)
  change: edit src/widgets/kfileitemdelegate.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 51 test(s), Skipped: 0 test(s), Total: 
52 test(s)Failed: TestSuite.kiofilewidgets-kfileplacesmodeltest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 270/340 (79%)CLASSES 270/340 (79%)LINE 28899/51369 
(56%)CONDITIONAL 15592/38081 (41%)

By packages
  
autotests
FILES 66/66 (100%)CLASSES 66/66 (100%)LINE 7527/8113 
(93%)CONDITIONAL 4010/8494 (47%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 543/544 
(100%)CONDITIONAL 200/336 (60%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 179/198 (90%)CONDITIONAL 
60/90 (67%)
src.core
FILES 96/116 (83%)CLASSES 96/116 (83%)LINE 7799/14137 
(55%)CONDITIONAL 4258/9067 (47%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 25/36 (69%)CLASSES 25/36 (69%)LINE 3328/7561 
(44%)CONDITIONAL 1221/4383 (28%)
src.gui
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 104/110 (95%)CONDITIONAL 
46/72 (64%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 434/832 (52%)CONDITIONAL 
326/719 (45%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1763/3783 
(47%)CONDITIONAL 1259/3434 (37%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 620/781 (79%)CONDITIONAL 
602/831 (72%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 713/1155 (62%)CONDITIONAL 
375/753 (50%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 686/764 (90%)CONDITIONAL 
445/936 (48%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/27 (52%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 373/385 (97%)CONDITIONAL 
111/138 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 377/594 (63%)CONDITIONAL 
280/580 (48%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
144/256 (56%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 239/268 (89%)CONDITIONAL 
333/414 (80%)
src.widgets
FILES 32/64 (50%)CLASSES 32/64 (50%)LINE 3598/10953 
(33%)CONDITIONAL 1718/6944 (25%)

Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Hrvoje Senjan


> On Oct. 25, 2016, 1:31 p.m., Hrvoje Senjan wrote:
> > find-modules/FindQt5PlatformSupport.cmake, line 75
> > 
> >
> > Shouldn't this be rather Qt5PlatformSupport_PRIVATE_INCLUDE_DIRS, and  
> > ${PKG_Qt5PlatformSupport_INCLUDEDIR}/QtPlatformSupport/ be marked as 
> > Qt5PlatformSupport_INCLUDE_DIR?
> 
> Kai Uwe Broulik wrote:
> I suppose? Dunno, I just copied it from KWin and I know nothing about 
> CMake syntax.
> 
> Hrvoje Senjan wrote:
> Well, all other modules have both INCLUDE_DIRS and PRIVATE_INCLUDE_DIRS...
> Also, IMO it's a better idea to include ECMQueryQmake and use e.g. 
> query_qmake(qt_install_include_dir QT_INSTALL_HEADERS) then to use pkgconfig.
> 
> Kai Uwe Broulik wrote:
> You've just lost me.

Something like http://paste.opensuse.org/74147268


- Hrvoje


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


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129252: Support non integer scale factors in KFileDelegate

2016-10-25 Thread David Edmundson

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

(Updated Oct. 25, 2016, 4:58 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 9f6b69237c299cabff1427da54768624545e1943 by David 
Edmundson to branch master.


Repository: kio


Description
---

Support non integer scale factors in KFileDelegate


Diffs
-

  src/widgets/kfileitemdelegate.cpp 9a40b7c24d8f91600907bccbf32d70aeb78eaa2e 

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


Testing
---

Ran system settings with QT_SCALE_FACTOR=2.3 
didn't look blurry on mouseover


Thanks,

David Edmundson



Re: Review Request 129253: Support non integer scale factors in kiconengine

2016-10-25 Thread David Edmundson

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

(Updated Oct. 25, 2016, 8:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Feck.


Changes
---

Submitted with commit c203e366c400bab750e0b0f3d640f7fa85c35065 by David 
Edmundson to branch master.


Repository: kiconthemes


Description
---

Support non integer scale factors in kiconengine


Diffs
-

  src/kiconengine.cpp c31829e82237a7432e3b7c6b1cf85cc3b2bc3ebe 

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


Testing
---

Ran system settings with QT_SCALE_FACTOR=2.3 
didn't look blurry on mouseover


Thanks,

David Edmundson



Re: Review Request 128773: Revert "Don't use QQuickWidget::quickWindow() as it was added in Qt 5.5"

2016-10-25 Thread Rohan Garg

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

(Updated Oct. 25, 2016, 4:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit dbc2f83cd264fc1bfbb3321bb0f1ec8e2df1cef1 by Rohan Garg to 
branch master.


Repository: kcmutils


Description
---

This reverts commit 5432c3edf5e074f1e951e6ecc682f7a400e2818f.

kcmutils now depends on Qt 5.5 so it should be fine to go in.


Diffs
-

  src/kcmoduleqml.cpp 1165c61 

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


Testing
---


Thanks,

Rohan Garg



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Albert Astals Cid


> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?
> 
> Albert Astals Cid wrote:
> > Lets stick to the established commands over time where Shift+del is 
> permanent delete
> 
> I don't know man, i already cited wikipedia proving you wrong, what more 
> do you want?
> 
> Luigi Toscano wrote:
> IMHO the poll should be better placed for example on forums.kde.org, or 
> woth some tool that does not require a google account.
> 
> That said, even if different, we should have a global shortcut for 
> permanent deletion as now, or we will end up with bugs to have all apps 
> provide the same shortcut anyway.
> 
> Heiko Tietze wrote:
> >IMHO the poll should be better placed for example on forums.kde.org
> 
> Don't understand a quick poll like this as a final and definite survey. 
> It's quickly done, addresses a lot of average users (guess more than on the 
> forums or via blog->planet), and adds one more insight.
> 
> Mark Gaiser wrote:
> Hi Albert,
> 
> You said "DeleteFile is Shift+Delete by default" which lead me to think 
> that pressing "delete" was going to do that action. Sorry my bad.
> 
> Regarding the shift+delete and wikipedia. I highly doubt what wikipedia 
> says is true. I know with 100% certainty that shift+delete is permanently 
> delete on windows, yet on that wikipedia page shift+delete is described as 
> cut shortcut. That is not right!

> Regarding the shift+delete and wikipedia. I highly doubt what wikipedia says 
> is true. I know with 100% certainty that shift+delete is permanently delete 
> on windows, yet on that wikipedia page shift+delete is described as cut 
> shortcut. That is not right!

You just 

Re: Review Request 128773: Revert "Don't use QQuickWidget::quickWindow() as it was added in Qt 5.5"

2016-10-25 Thread David Edmundson

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


Ship it!




Ship It!

- David Edmundson


On Oct. 25, 2016, 2:49 p.m., Rohan Garg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128773/
> ---
> 
> (Updated Oct. 25, 2016, 2:49 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcmutils
> 
> 
> Description
> ---
> 
> This reverts commit 5432c3edf5e074f1e951e6ecc682f7a400e2818f.
> 
> kcmutils now depends on Qt 5.5 so it should be fine to go in.
> 
> 
> Diffs
> -
> 
>   src/kcmoduleqml.cpp 1165c61 
> 
> Diff: https://git.reviewboard.kde.org/r/128773/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rohan Garg
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Mark Gaiser


> On okt 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?
> 
> Albert Astals Cid wrote:
> > Lets stick to the established commands over time where Shift+del is 
> permanent delete
> 
> I don't know man, i already cited wikipedia proving you wrong, what more 
> do you want?
> 
> Luigi Toscano wrote:
> IMHO the poll should be better placed for example on forums.kde.org, or 
> woth some tool that does not require a google account.
> 
> That said, even if different, we should have a global shortcut for 
> permanent deletion as now, or we will end up with bugs to have all apps 
> provide the same shortcut anyway.
> 
> Heiko Tietze wrote:
> >IMHO the poll should be better placed for example on forums.kde.org
> 
> Don't understand a quick poll like this as a final and definite survey. 
> It's quickly done, addresses a lot of average users (guess more than on the 
> forums or via blog->planet), and adds one more insight.

Hi Albert,

You said "DeleteFile is Shift+Delete by default" which lead me to think that 
pressing "delete" was going to do that action. Sorry my bad.

Regarding the shift+delete and wikipedia. I highly doubt what wikipedia says is 
true. I know with 100% certainty that shift+delete is permanently delete on 
windows, yet on that wikipedia page shift+delete is described as cut shortcut. 
That is not right!


- Mark


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


On okt 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> 

Re: Review Request 129252: Support non integer scale factors in KFileDelegate

2016-10-25 Thread Roman Gilg

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


Ship it!




Tested and fixes the problem on my system aswell.

- Roman Gilg


On Okt. 24, 2016, 5:05 nachm., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129252/
> ---
> 
> (Updated Okt. 24, 2016, 5:05 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Support non integer scale factors in KFileDelegate
> 
> 
> Diffs
> -
> 
>   src/widgets/kfileitemdelegate.cpp 9a40b7c24d8f91600907bccbf32d70aeb78eaa2e 
> 
> Diff: https://git.reviewboard.kde.org/r/129252/diff/
> 
> 
> Testing
> ---
> 
> Ran system settings with QT_SCALE_FACTOR=2.3 
> didn't look blurry on mouseover
> 
> 
> Thanks,
> 
> David Edmundson
> 
>



Re: ATTN: latest changes in breeze-icons make packaging untenable

2016-10-25 Thread Martin Graesslin
On Tuesday, October 25, 2016 4:47:40 PM CEST Luca Beltrame wrote:
> Hello,
> 
> recent changes in breeze broke building in openSUSE's OBS: after a
> discussion on IRC, it turned out that there were incorrect symlinks.
> Adjustments were made in order to preserve space. However, while
> harmless at first (I didn't notice earlier, and CI was green) these
> changes *break* packaging for most systems.
> 
> The reason? Directories became symlinks, hence a package manager can't
> fix that, it will totally break when a package updates (because it will
> try to symlink something existent).
> 
> Therefore there is *no* way the current state of breeze-icons can be
> installed a the moment by any sane distribution. No problem for now,
> but Frameworks are monthly releases, so...
> 
> This needs to be fixed, even if at the cost of wasting space (but
> making packagers much happier).
> 
> If there's no consensus, I will revert these commits [1][2][3][4] in
> breeze-icons by Sunday morning.

+1 go for it. Sorry for the problems this caused to distros. As a reminder to 
our devs and designers: frameworks have a review policy. the commits mentioned 
by Luca have no Review hint. Please don't push without prior review - 
especially not if you change something like that. We could have get the 
expertise in during the review.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.


Re: ATTN: latest changes in breeze-icons make packaging untenable

2016-10-25 Thread Luca Beltrame
Il giorno Tue, 25 Oct 2016 16:47:40 +0200
Luca Beltrame  ha scritto:

> If there's no consensus, I will revert these commits [1][2][3][4] in
> breeze-icons by Sunday morning.

After discussion on IRC, the commits were reverted.


pgpkAXusssxMw.pgp
Description: Firma digitale OpenPGP


Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Kai Uwe Broulik


> On Okt. 25, 2016, 11:31 vorm., Hrvoje Senjan wrote:
> > find-modules/FindQt5PlatformSupport.cmake, line 75
> > 
> >
> > Shouldn't this be rather Qt5PlatformSupport_PRIVATE_INCLUDE_DIRS, and  
> > ${PKG_Qt5PlatformSupport_INCLUDEDIR}/QtPlatformSupport/ be marked as 
> > Qt5PlatformSupport_INCLUDE_DIR?
> 
> Kai Uwe Broulik wrote:
> I suppose? Dunno, I just copied it from KWin and I know nothing about 
> CMake syntax.
> 
> Hrvoje Senjan wrote:
> Well, all other modules have both INCLUDE_DIRS and PRIVATE_INCLUDE_DIRS...
> Also, IMO it's a better idea to include ECMQueryQmake and use e.g. 
> query_qmake(qt_install_include_dir QT_INSTALL_HEADERS) then to use pkgconfig.

You've just lost me.


- Kai Uwe


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


On Okt. 25, 2016, 11:21 vorm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Okt. 25, 2016, 11:21 vorm.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129259: Fix the buffersize in certain situations.

2016-10-25 Thread taro yamada

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

(Updated Oct. 25, 2016, 2:51 p.m.)


Review request for KDE Frameworks.


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


Repository: kio


Description
---

Currently, KIO uses lstat to get the buffersize for readlink.
But in certain situations, it returns inappropriate value.

For example, "/proc/self" or "/sys/bus/cpu/devices/*" returns its size is 0 , 
and then readlink fails with EINVAL.(so link won't be shown in kde application.)
TMSU seems it returns its target's actual filesize insted of the link's 
filesize itself.

This patch changes the buffersize to 1024 bytes if it is 0.
And later truncate it to actual size.


Diffs (updated)
-

  src/ioslaves/file/file.cpp 8b17d31 

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


Testing
---


Thanks,

taro yamada



Re: Review Request 128773: Revert "Don't use QQuickWidget::quickWindow() as it was added in Qt 5.5"

2016-10-25 Thread Rohan Garg

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

(Updated Oct. 25, 2016, 8:19 p.m.)


Review request for KDE Frameworks.


Repository: kcmutils


Description
---

This reverts commit 5432c3edf5e074f1e951e6ecc682f7a400e2818f.

kcmutils now depends on Qt 5.5 so it should be fine to go in.


Diffs (updated)
-

  src/kcmoduleqml.cpp 1165c61 

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


Testing
---


Thanks,

Rohan Garg



ATTN: latest changes in breeze-icons make packaging untenable

2016-10-25 Thread Luca Beltrame
Hello,

recent changes in breeze broke building in openSUSE's OBS: after a
discussion on IRC, it turned out that there were incorrect symlinks.
Adjustments were made in order to preserve space. However, while
harmless at first (I didn't notice earlier, and CI was green) these
changes *break* packaging for most systems.

The reason? Directories became symlinks, hence a package manager can't
fix that, it will totally break when a package updates (because it will
try to symlink something existent).

Therefore there is *no* way the current state of breeze-icons can be
installed a the moment by any sane distribution. No problem for now,
but Frameworks are monthly releases, so...

This needs to be fixed, even if at the cost of wasting space (but
making packagers much happier). 

If there's no consensus, I will revert these commits [1][2][3][4] in
breeze-icons by Sunday morning.

[1] f40a8314d292a881257767a72162ec3b2919b214
[2] c45891e5e19c0d9ba837f2ce0ef9cabff38d696c
[3] 44bee349abe50f57f799d0cb003347d48847caea
[4] fd6fbc99b2846b8baa5f266a19ab2b0e906cd353


pgpQaxvVK4vbL.pgp
Description: Firma digitale OpenPGP


Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Heiko Tietze


> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?
> 
> Albert Astals Cid wrote:
> > Lets stick to the established commands over time where Shift+del is 
> permanent delete
> 
> I don't know man, i already cited wikipedia proving you wrong, what more 
> do you want?
> 
> Luigi Toscano wrote:
> IMHO the poll should be better placed for example on forums.kde.org, or 
> woth some tool that does not require a google account.
> 
> That said, even if different, we should have a global shortcut for 
> permanent deletion as now, or we will end up with bugs to have all apps 
> provide the same shortcut anyway.

>IMHO the poll should be better placed for example on forums.kde.org

Don't understand a quick poll like this as a final and definite survey. It's 
quickly done, addresses a lot of average users (guess more than on the forums 
or via blog->planet), and adds one more insight.


- Heiko


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


On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Okt. 24, 2016, 10:47 vorm.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> 

Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Hrvoje Senjan


> On Oct. 25, 2016, 1:31 p.m., Hrvoje Senjan wrote:
> > find-modules/FindQt5PlatformSupport.cmake, line 75
> > 
> >
> > Shouldn't this be rather Qt5PlatformSupport_PRIVATE_INCLUDE_DIRS, and  
> > ${PKG_Qt5PlatformSupport_INCLUDEDIR}/QtPlatformSupport/ be marked as 
> > Qt5PlatformSupport_INCLUDE_DIR?
> 
> Kai Uwe Broulik wrote:
> I suppose? Dunno, I just copied it from KWin and I know nothing about 
> CMake syntax.

Well, all other modules have both INCLUDE_DIRS and PRIVATE_INCLUDE_DIRS...
Also, IMO it's a better idea to include ECMQueryQmake and use e.g. 
query_qmake(qt_install_include_dir QT_INSTALL_HEADERS) then to use pkgconfig.


- Hrvoje


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


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Luigi Toscano


> On Ott. 24, 2016, 1 p.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?
> 
> Albert Astals Cid wrote:
> > Lets stick to the established commands over time where Shift+del is 
> permanent delete
> 
> I don't know man, i already cited wikipedia proving you wrong, what more 
> do you want?

IMHO the poll should be better placed for example on forums.kde.org, or woth 
some tool that does not require a google account.

That said, even if different, we should have a global shortcut for permanent 
deletion as now, or we will end up with bugs to have all apps provide the same 
shortcut anyway.


- Luigi


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


On Ott. 24, 2016, 12:47 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Ott. 24, 2016, 12:47 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes 

Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Albert Astals Cid


> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg
> 
> Albert Astals Cid wrote:
> > I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> 
> Why would with my suggestion end up permanently deleted instead of trash?

> Lets stick to the established commands over time where Shift+del is permanent 
> delete

I don't know man, i already cited wikipedia proving you wrong, what more do you 
want?


- Albert


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


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: 

Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Kevin Funk


> On Oct. 25, 2016, 11:37 a.m., Aleix Pol Gonzalez wrote:
> > Shouldn't this be in Qt? What am I missing?
> 
> Martin Gräßlin wrote:
> Yes it should, but it isn't. No idea why not.
> 
> Hrvoje Senjan wrote:
> The module is internal, so it intentionally doesn't install any cmake 
> files.

Correct, that's why. See: https://bugreports.qt.io/browse/QTBUG-50073


- Kevin


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


On Oct. 25, 2016, 11:21 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 11:21 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Hrvoje Senjan


> On Oct. 25, 2016, 1:37 p.m., Aleix Pol Gonzalez wrote:
> > Shouldn't this be in Qt? What am I missing?
> 
> Martin Gräßlin wrote:
> Yes it should, but it isn't. No idea why not.

The module is internal, so it intentionally doesn't install any cmake files.


- Hrvoje


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


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Albert Astals Cid


> On Oct. 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.
> 
> Heiko Tietze wrote:
> Let's do a quick poll: 
> https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg

> I would not do that. It would be unexpected behavior when the user deletes a 
> file (in for instance dolphin) and expects it to end up in the trash. With 
> your suggestion it would be permanantly deleted.

Why would with my suggestion end up permanently deleted instead of trash?


- Albert


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


On Oct. 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Oct. 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Heiko Tietze


> On Okt. 24, 2016, 11 vorm., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.
> 
> Mark Gaiser wrote:
> I would not do that. It would be unexpected behavior when the user 
> deletes a file (in for instance dolphin) and expects it to end up in the 
> trash. With your suggestion it would be permanantly deleted.
> Regardless of the shortcut, every other modern OS (win and mac) uses the 
> delete key to "move to trash" and a +delete key to permanantly 
> remove the file.
> 
> Lets stick to the established commands over time where Shift+del is 
> permanent delete, not cut text. Other apps should _not_ use that key 
> combination for a task that isn't permanently deleting something.
> 
> Just my 2ct.

Let's do a quick poll: 
https://plus.google.com/107566594492891737454/posts/QJzpApTeSFg


- Heiko


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


On Okt. 24, 2016, 10:47 vorm., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated Okt. 24, 2016, 10:47 vorm.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>



Re: Review Request 129251: Remove Shift+Del as secondary shortcut for Cut

2016-10-25 Thread Mark Gaiser


> On okt 24, 2016, 11 a.m., Albert Astals Cid wrote:
> > -1 it's an established shortcut for cut too. even 
> > https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts lists it in "Cut 
> > the selection and store it in the clipboard"
> 
> Elvis Angelaccio wrote:
> Ah, sorry I didn't know that. Still, the conflict is caused by kconfig 
> itself and it's being worked around by applications. What should we do then?
> 
> Heiko Tietze wrote:
> This question was asked last year on the mailing list 
> https://mail.kde.org/pipermail/kde-guidelines/2015-June/thread.html#877. 
> Shift+Del dates back to the medieval ages but was never reverted and is still 
> in our HIG. The discussion didn't end with a solution. And I strongly suggest 
> to have a generic solution that works in all programs. Btw, Krusader uses 
> Shift+Del for permanently delete files.
> 
> Elvis Angelaccio wrote:
> Thanks for the link. So if I understand the issue correctly, we should 
> first agree upon another primary shortcut for "Force Delete" and replace 
> Shift+Del with that, at least in KConfig. What about Meta+Del like Thomas 
> suggested?
> 
> Heiko Tietze wrote:
> 1. Do we want to retain IBM shortcuts used for decades? Yes, keep 
> shift+del as alternative to ctrl+X; No, drop the unknown shortcut.
> 2a. If 1)=Yes, do we want to have a similar shortcut for permanently 
> delete? Yes, meta+del/alt+del... No, use something completely different and 
> app specific
> 2b. If 1)=No, do we want to have an easy shortcut for destructive 
> functions? Yes, use ctrl+del for convenience. No, make it hard to 
> unintentionally run destructive functions; rather use 
> shift+alt+del/ctrl+alt+del or the like.
> 
> (My take is 2b and No; but it has to work in _every_ KDE app unless the 
> app defines its own behavior)
> 
> Albert Astals Cid wrote:
> My suggestion is:
> 
> * Cut is Ctrl+X and Shift+Delete by default
> * DeleteFile is Shift+Delete by default
> 
> **if** both Cut and DeleteFile are used in the same action collection we 
> disable Shift+Delete from Cut (only if it's there by default and it was not 
> the user that set it on purpose)
> 
> That should be *doable* hopefully.

I would not do that. It would be unexpected behavior when the user deletes a 
file (in for instance dolphin) and expects it to end up in the trash. With your 
suggestion it would be permanantly deleted.
Regardless of the shortcut, every other modern OS (win and mac) uses the delete 
key to "move to trash" and a +delete key to permanantly remove the 
file.

Lets stick to the established commands over time where Shift+del is permanent 
delete, not cut text. Other apps should _not_ use that key combination for a 
task that isn't permanently deleting something.

Just my 2ct.


- Mark


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


On okt 24, 2016, 10:47 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129251/
> ---
> 
> (Updated okt 24, 2016, 10:47 a.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Matthew Dawson.
> 
> 
> Bugs: 357747
> https://bugs.kde.org/show_bug.cgi?id=357747
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> This patch removes Shift+Del as secondary shortcut for the Cut action. This 
> shortcut was set back in 2001.
> 
> Reasons for removing it:
> 
> * The expected standard behavior for this shortcut is "Permanently delete"
> * For the reason above, it is also set as primary shortcut for the 
> `DeleteFile` action. This causes conflicts in applications.
> * For the reason above, many applications (e.g. Dolphin or Digikam) already 
> resolve this conflict on their own.
> 
> Credits to Jan for the investigation: 
> https://bugs.kde.org/show_bug.cgi?id=347373#c2
> 
> 
> Diffs
> -
> 
>   src/gui/kstandardshortcut.cpp 92eb091382c7ab2110240cef21f29268be787250 
> 
> Diff: https://git.reviewboard.kde.org/r/129251/diff/
> 
> 
> Testing
> ---
> 
> Using Shift+Del in Gwenview now works as expected.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Kai Uwe Broulik


> On Okt. 25, 2016, 11:31 vorm., Hrvoje Senjan wrote:
> > find-modules/FindQt5PlatformSupport.cmake, line 75
> > 
> >
> > Shouldn't this be rather Qt5PlatformSupport_PRIVATE_INCLUDE_DIRS, and  
> > ${PKG_Qt5PlatformSupport_INCLUDEDIR}/QtPlatformSupport/ be marked as 
> > Qt5PlatformSupport_INCLUDE_DIR?

I suppose? Dunno, I just copied it from KWin and I know nothing about CMake 
syntax.


- Kai Uwe


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


On Okt. 25, 2016, 11:21 vorm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Okt. 25, 2016, 11:21 vorm.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Martin Gräßlin


> On Oct. 25, 2016, 1:37 p.m., Aleix Pol Gonzalez wrote:
> > Shouldn't this be in Qt? What am I missing?

Yes it should, but it isn't. No idea why not.


- Martin


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


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Review Request 129259: Fix the buffersize in certain situations.

2016-10-25 Thread taro yamada

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

Review request for KDE Frameworks.


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


Repository: kio


Description
---

Currently, KIO uses lstat to get the buffersize for readlink.
But in certain situations, it returns inappropriate value.

For example, "/proc/self" or "/sys/bus/cpu/devices/*" returns its size is 0 , 
and then readlink fails with EINVAL.(so link won't be shown in kde application.)
TMSU seems it returns its target's actual filesize insted of the link's 
filesize itself.

This patch changes the buffersize to 1024 bytes if it is 0.
And later truncate it to actual size.


Diffs
-

  src/ioslaves/file/file.cpp 8b17d31 

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


Testing
---


Thanks,

taro yamada



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Aleix Pol Gonzalez

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



Shouldn't this be in Qt? What am I missing?

- Aleix Pol Gonzalez


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Hrvoje Senjan

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




find-modules/FindQt5PlatformSupport.cmake (line 75)


Shouldn't this be rather Qt5PlatformSupport_PRIVATE_INCLUDE_DIRS, and  
${PKG_Qt5PlatformSupport_INCLUDEDIR}/QtPlatformSupport/ be marked as 
Qt5PlatformSupport_INCLUDE_DIR?


- Hrvoje Senjan


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Re: Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Martin Gräßlin

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



+1

- Martin Gräßlin


On Oct. 25, 2016, 1:21 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129260/
> ---
> 
> (Updated Oct. 25, 2016, 1:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Alex Merry and Martin Gräßlin.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Comes from KWin and will eventually be used in Plasma Integration, hence 
> moving it to extra-cmake-modules.
> 
> 
> Diffs
> -
> 
>   find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129260/diff/
> 
> 
> Testing
> ---
> 
> Removed it from KWin, built KWin, worked.
> 
> Built plasma-integration with QDBusMenu private stuff, worked, although 
> includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
> upstream issue since it works with the files Kwin includes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>



Review Request 129260: Add find module for QtPlatformSupport

2016-10-25 Thread Kai Uwe Broulik

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

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


Repository: extra-cmake-modules


Description
---

Comes from KWin and will eventually be used in Plasma Integration, hence moving 
it to extra-cmake-modules.


Diffs
-

  find-modules/FindQt5PlatformSupport.cmake PRE-CREATION 

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


Testing
---

Removed it from KWin, built KWin, worked.

Built plasma-integration with QDBusMenu private stuff, worked, although 
includes there sometimes omit the QtPlatformSupport/ prefix but this is an 
upstream issue since it works with the files Kwin includes.


Thanks,

Kai Uwe Broulik



Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 343 - Failure!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/343/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 09:37:43 +
Build duration: 1 min 52 sec

CHANGE SET
Revision 44bee349abe50f57f799d0cb003347d48847caea by alessandro.longo: (Renamed 
iconsgt;breeze and icons-darkgt;breeze-dark to take advanted of)
  change: delete icons/actions/22/pin.svg
  change: add breeze-dark/actions/16/kdenlive-lock.svg
  change: delete icons-dark/actions/16/project-development.svg
  change: delete icons/actions/22/mail-deleted.svg
  change: delete icons-dark/actions/16/distribute-vertical-margin.svg
  change: delete icons-dark/actions/16/format-line-spacing-double.svg
  change: add breeze-dark/actions/16/gtk-undelete-ltr.svg
  change: delete icons-dark/actions/16/code-class.svg
  change: add breeze-dark/actions/16/escape-direction-horizontal.svg
  change: add breeze-dark/actions/16/editor.svg
  change: add breeze-dark/actions/16/kdenlive-align-vert.svg
  change: delete icons-dark/actions/16/format-indent-more.svg
  change: add breeze-dark/actions/16/go-first-view-page.svg
  change: delete icons/actions/24/help-feedback.svg
  change: delete icons-dark/actions/16/minuet-rhythms.svg
  change: delete icons/actions/22/interface.svg
  change: add breeze-dark/actions/16/mail-tagged.svg
  change: add breeze-dark/actions/16/go-last.svg
  change: add breeze-dark/actions/16/go-next-use.svg
  change: delete icons-dark/actions/16/mail-mark-notjunk.svg
  change: delete icons-dark/actions/16/debug-step-into-instruction.svg
  change: delete icons-dark/actions/16/object-to-path.svg
  change: add breeze-dark/actions/16/project-development.svg
  change: add breeze-dark/actions/16/node-join-segment.svg
  change: delete icons/actions/32/align-vertical-top-to-anchor.svg
  change: add breeze-dark/actions/16/media-track-add-amarok.svg
  change: add breeze-dark/actions/16/grid-axonometric.svg
  change: add breeze-dark/actions/16/media-repeat-album-amarok.svg
  change: delete icons-dark/actions/16/path-union.svg
  change: delete icons-dark/actions/16/distribute-horizontal-equal.svg
  change: delete icons/actions/22/kdenlive-align-vert.svg
  change: add breeze-dark/actions/16/amarok_playcount.svg
  change: add breeze-dark/actions/16/draw-brush.svg
  change: add breeze-dark/actions/16/albumfolder-properties.svg
  change: delete icons-dark/actions/16/page-2sides.svg
  change: delete icons-dark/actions/16/distribute-vertical-equal.svg
  change: add breeze-dark/actions/16/distribute-horizontal-right.svg
  change: add breeze-dark/actions/16/merge.svg
  change: add breeze-dark/actions/16/kdenlive-align-right.svg
  change: delete icons-dark/actions/16/distribute-horizontal-page.svg
  change: add breeze-dark/actions/16/format-border-set-left.svg
  change: add breeze-dark/actions/16/minuet-chords.svg
  change: delete icons-dark/actions/16/containment.svg
  change: delete icons/actions/22/kdenlive-align-right.svg
  change: add breeze-dark/actions/16/format-justify-left.svg
  change: delete icons-dark/actions/16/format-list-ordered.svg
  change: add breeze-dark/actions/16/clock-large.svg
  change: delete icons/actions/16/edit-undo-history.svg
  change: add breeze-dark/actions/16/followmouse.svg
  change: delete icons-dark/actions/16/insert-math-expression.svg
  change: add breeze-dark/actions/16/node-delete.svg
  change: delete icons/actions/24/games-config-custom.svg
  change: add breeze-dark/actions/16/favorite-genres-amarok.svg
  change: delete icons-dark/actions/16/edit-clear.svg
  change: add breeze-dark/actions/16/edit-find.svg
  change: add breeze-dark/actions/16/atmosphere.svg
  change: delete icons-dark/actions/16/go-home.svg
  change: add breeze-dark/actions/16/gtk-add.svg
  change: add breeze-dark/actions/16/filename-bpm-amarok.svg
  change: add breeze-dark/actions/16/edit-undo-history.svg
  change: add breeze-dark/actions/16/markasblank.svg
  change: add breeze-dark/actions/16/distribute-horizontal-margin.svg
  change: add breeze-dark/actions/12/transform-affect-gradient.svg
  change: add breeze-dark/actions/16/align-horizontal-left-to-anchor.svg
  change: delete icons-dark/actions/16/meeting-participant-no-response.svg
  change: delete icons-dark/actions/16/edit-clone.svg
  change: add breeze-dark/actions/16/format-text-code.svg
  change: add breeze-dark/actions/16/draw-ellipse-arc.svg
  change: delete icons-dark/actions/16/path-exclusion.svg
  change: delete icons-dark/actions/16/go-last.svg
  change: delete icons-dark/actions/16/project-development-new-template.svg
  change: add breeze-dark/actions/16/document-save.svg
  change: add breeze-dark/actions/16/media-album-cover-manager-amarok.svg
  change: delete icons-dark/actions/16/edit-find-replace.svg
  change: add breeze-dark/actions/16/folder-new.svg
  change: add breeze-dark/actions/16/add-placemark.svg
  change: delete icons-dark/actions/16/im-ban-kick-user.svg
  change: delete 

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 344 - Fixed!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/344/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 10:02:45 +
Build duration: 5 min 24 sec

CHANGE SET
Revision fd6fbc99b2846b8baa5f266a19ab2b0e906cd353 by alessandro.longo: (Updated 
CMakeLists.txt with new folders names)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 98/132 
(74%)CONDITIONAL 40/78 (51%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 56/75 (75%)CONDITIONAL 
26/52 (50%)

Jenkins-kde-ci: breeze-icons master stable-kf5-qt5 » Linux,gcc - Build # 344 - Fixed!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/344/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 10:02:45 +
Build duration: 5 min 24 sec

CHANGE SET
Revision fd6fbc99b2846b8baa5f266a19ab2b0e906cd353 by alessandro.longo: (Updated 
CMakeLists.txt with new folders names)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 98/132 
(74%)CONDITIONAL 40/78 (51%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 56/75 (75%)CONDITIONAL 
26/52 (50%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 346 - Fixed!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/346/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 10:02:45 +
Build duration: 5 min 7 sec

CHANGE SET
Revision fd6fbc99b2846b8baa5f266a19ab2b0e906cd353 by alessandro.longo: (Updated 
CMakeLists.txt with new folders names)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 98/132 
(74%)CONDITIONAL 40/78 (51%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 56/75 (75%)CONDITIONAL 
26/52 (50%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 346 - Fixed!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/346/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 10:02:45 +
Build duration: 5 min 7 sec

CHANGE SET
Revision fd6fbc99b2846b8baa5f266a19ab2b0e906cd353 by alessandro.longo: (Updated 
CMakeLists.txt with new folders names)
  change: edit CMakeLists.txt


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 5/5 (100%)CLASSES 5/5 (100%)LINE 98/132 
(74%)CONDITIONAL 40/78 (51%)

By packages
  
default>
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 42/57 (74%)CONDITIONAL 
14/26 (54%)
autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 56/75 (75%)CONDITIONAL 
26/52 (50%)

Jenkins-kde-ci: breeze-icons master kf5-qt5 » Linux,gcc - Build # 345 - Failure!

2016-10-25 Thread no-reply

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/breeze-icons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/345/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 25 Oct 2016 09:37:43 +
Build duration: 25 sec

CHANGE SET
Revision 44bee349abe50f57f799d0cb003347d48847caea by alessandro.longo: (Renamed 
iconsgt;breeze and icons-darkgt;breeze-dark to take advanted of)
  change: delete icons/actions/22/document-open-data.svg
  change: add breeze-dark/actions/16/format-justify-fill.svg
  change: add breeze-dark/actions/16/project-development-new-template.svg
  change: add breeze-dark/actions/16/align-horizontal-left-out.svg
  change: add breeze-dark/actions/16/object-fill.svg
  change: delete icons/actions/24/node-join-segment.svg
  change: delete icons-dark/actions/16/new-audio-alarm.svg
  change: add breeze-dark/actions/16/draw-arrow-forward.svg
  change: delete icons-dark/actions/16/debug-run.svg
  change: delete icons-dark/actions/16/filename-divider.svg
  change: delete icons/actions/24/gtk-cdrom.svg
  change: add breeze-dark/actions/16/go-last.svg
  change: add breeze-dark/actions/16/insert-table-row.svg
  change: delete icons-dark/actions/16/edit-table-insert-column-left.svg
  change: add breeze-dark/actions/16/password-generate.svg
  change: add breeze-dark/actions/16/flag-green.svg
  change: add breeze-dark/actions/16/format-precision-more.svg
  change: delete icons-dark/actions/12/object-stroke-style.svg
  change: add breeze-dark/actions/16/quickopen-class.svg
  change: delete icons-dark/actions/16/list-remove.svg
  change: delete icons-dark/actions/16/document-edit-encrypt.svg
  change: delete icons/actions/16/bqm-commit.svg
  change: add breeze-dark/actions/16/edit-rename.svg
  change: delete icons-dark/actions/16/draw-polyline.svg
  change: delete icons/actions/22/gpg.svg
  change: add breeze-dark/actions/16/check_constraint.svg
  change: add breeze-dark/actions/16/mail-invitation.svg
  change: add breeze-dark/actions/16/flash.svg
  change: delete icons/actions/24/bookmarks.svg
  change: delete icons/actions/24/password-show-off.svg
  change: delete icons/actions/22/box.svg
  change: add breeze-dark/actions/16/kdenlive-up.svg
  change: add breeze-dark/actions/16/resource-calendar-insert.svg
  change: add breeze-dark/actions/16/go-first-view-page.svg
  change: add breeze-dark/actions/16/layer-new.svg
  change: add breeze-dark/actions/16/document-print-preview.svg
  change: delete icons-dark/actions/16/code-typedef.svg
  change: delete icons/actions/16/format-list-unordered.svg
  change: delete icons-dark/actions/16/gtk-convert.svg
  change: add breeze-dark/actions/16/media-playlist-repeat.svg
  change: delete icons/actions/24/gtk-yes.svg
  change: add breeze-dark/actions/16/download-amarok.svg
  change: add breeze-dark/actions/16/distribute-vertical.svg
  change: delete icons-dark/actions/16/go-jump-declaration.svg
  change: delete icons-dark/actions/16/path-simplify.svg
  change: delete icons-dark/actions/16/edit-image-face-add.svg
  change: add breeze-dark/actions/16/escape-direction-all.svg
  change: delete icons/actions/16/colors-chromagreen.svg
  change: add breeze-dark/actions/16/geany-build.svg
  change: delete icons-dark/actions/16/media-album-cover-manager-amarok.svg
  change: delete icons-dark/actions/16/paint-unknown.svg
  change: delete icons/actions/22/object-align-vertical-top-calligra.svg
  change: add breeze-dark/actions/16/edit-bomb.svg
  change: add breeze-dark/actions/16/games-config-tiles.svg
  change: delete icons/actions/22/gps.svg
  change: delete icons/actions/16/port.svg
  change: delete icons-dark/actions/16/draw-triangle3.svg
  change: delete icons/actions/24/arrow-left.svg
  change: add breeze-dark/actions/16/kruler-west.svg
  change: delete icons-dark/actions/16/kruler-south.svg
  change: add breeze-dark/actions/16/document-open-folder.svg
  change: add breeze-dark/actions/16/arrow-up.svg
  change: add breeze-dark/actions/16/component.svg
  change: delete icons/actions/22/labplot-auto-scale-y.svg
  change: add breeze-dark/actions/16/mail-thread-watch.svg
  change: add breeze-dark/actions/16/node.svg
  change: delete icons/actions/22/presence_away.svg
  change: add breeze-dark/actions/16/addressbook-details.svg
  change: delete icons/actions/22/edit-map.svg
  change: add breeze-dark/actions/16/path-division.svg
  change: delete icons/actions/24/gtk-execute.svg
  change: add breeze-dark/actions/16/kdenlive-align-top.svg
  change: add breeze-dark/actions/16/kdenlive-show-video.svg
  change: add breeze-dark/actions/16/document-save-as.svg
  change: add breeze-dark/actions/16/edit-clear-locationbar-rtl.svg
  change: delete icons-dark/actions/16/go-down.svg
  change: delete icons/actions/24/im-irc.svg
  change: delete icons/actions/22/labplot-auto-scale-all.svg
  change: add breeze-dark/actions/16/draw-arrow-down.svg
  change: delete icons-dark/actions/16/join.svg
  change: delete icons/actions/24/entry-delete.svg
  change: delete