Re: Review Request 126403: Get rid of QApplication dependency

[David Faure]

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



src/platforms/xcb/kwindowsystem.cpp (line 59)


move into the if() to save some work if isDirty==false?



src/platforms/xcb/kwindowsystem.cpp (line 890)


isn't that "return displayGeometry()?"

If not, then at least something like QRect(QPoint(0,0), 
displayGeometry().size()) (encapsulated in a convenience function) would avoid 
calling displayGeometry() twice.


- David Faure


On Dec. 17, 2015, 3:38 p.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated Dec. 17, 2015, 3:38 p.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

On Friday January 01 2016 20:24:59 Christoph Cullmann wrote:

>I think the Qt support is already ok enough, the application just needs to 
>handle it.
>That should just be a few lines of code, not sure if any more wrapping will 
>make this less work.

You're probably right. Would be nice though if there were some kind of unified 
interface that presents standard file open requests to the application, 
regardless of whether they came in over DBus, LaunchServices or whatever 
mechanism might exist on other platforms.

>I think the one with the QString is atm the thing Kate can easily support.

OK. The one returning a QUrl is probably the same, for local files at least.

>Then that is all fine, as long as Qt handles all right with the QFileOpenEvent 
>each app
>that wants to have support just needs 5 lines of handling this event.
>
>Guess I should add the handling to Kate/KWrite ;=)

Keep me posted if you get around to it, or if not :) You'd also have to figure 
out what additional information to add to the Info.plist, about the filetypes 
the applications can handle. If Kate handles RTF too you can just copy that 
from TextEdit, I guess.

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

Re: Review Request 126403: Get rid of QApplication dependency

[Thomas Lübking]

> On Jan. 1, 2016, 7:47 p.m., David Faure wrote:
> > src/platforms/xcb/kwindowsystem.cpp, line 891
> > 
> >
> > isn't that "return displayGeometry()?"
> > 
> > If not, then at least something like QRect(QPoint(0,0), 
> > displayGeometry().size()) (encapsulated in a convenience function) would 
> > avoid calling displayGeometry() twice.

Yes, is. Patch evolution had displayWidth/Height from the root window before I 
figured we'd better clone the combined screen area approach. Thanks for the 
catch.


- Thomas


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


On Dec. 17, 2015, 3:38 p.m., Thomas Lübking wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126403/
> ---
> 
> (Updated Dec. 17, 2015, 3:38 p.m.)
> 
> 
> Review request for KDE Frameworks, kwin and Albert Astals Cid.
> 
> 
> Bugs: 354811
> https://bugs.kde.org/show_bug.cgi?id=354811
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> summarized, alternative to https://git.reviewboard.kde.org/r/126397/
> 
> NOTICE: this compiles but is otherwise *completely* untested!
> 
> 
> Diffs
> -
> 
>   src/platforms/xcb/kwindowsystem.cpp 9d28704 
> 
> Diff: https://git.reviewboard.kde.org/r/126403/diff/
> 
> 
> Testing
> ---
> 
> no, not the least. esp. not on the bug.
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

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

Re: Review Request 126587: Add option to build with gcov support

[Dāvis Mosāns]

> On Jan. 2, 2016, 1:56 a.m., Aleix Pol Gonzalez wrote:
> > That's provided by ecm, isn't it?

I don't know... I based this on KWin 
https://quickgit.kde.org/?p=kwin.git=blob=master=CMakeLists.txt#l249


- Dāvis


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


On Dec. 31, 2015, 11:13 p.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126587/
> ---
> 
> (Updated Dec. 31, 2015, 11:13 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kjsembed
> 
> 
> Description
> ---
> 
> Add option to build with gcov support
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 916970287c070c07a60f8dbcd5f0758ac602038e 
> 
> Diff: https://git.reviewboard.kde.org/r/126587/diff/
> 
> 
> Testing
> ---
> 
> Compiles
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

Re: Review Request 126507: Fix leaked file description and potential use-after-free in kdelibs4support

[Michael Pyne]

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

(Updated Jan. 2, 2016, 1:55 a.m.)


Review request for KDE Frameworks.


Changes
---

Revise the patch to match the original code's logic as noted in David's review.


Repository: kdelibs4support


Description
---

Fix a couple of Coverity issues:

1. CID 1175508; file descriptors used in KLockFile could be leaked in
error conditions. Even when KLockFile sets mustCloseFd, the dtor's impl
also checks that the lock has been taken, which is only considered true
if LockOK had been returned in our lock function. Instead close() the fd
ourselves unless we make it to LockOK.

2. CID 117; The standard mis-use of QCache. QCache::insert can, in
theory, delete our object as soon as we insert it into cache, so we have
to check for that. Even ::contains() and ::object() can be risky (the
pointers returned by object() have no lifetime guarantee), but since
this is GUI code I assume it's only used single-threaded and not
re-entrant. Otherwise we'd need even more paranoia...


Diffs (updated)
-

  src/kdecore/klockfile_unix.cpp 67283a5 
  src/kdeui/k4style.cpp a1a2ab1 

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


Testing
---

Everything builds and appears to still work, though it's hard to test K4Style 
as I'm not sure what uses it right at this point.


Thanks,

Michael Pyne

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

Re: Review Request 126453: Fix library order

[Kevin Funk]

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

(Updated Jan. 1, 2016, 11 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Heiko Becker and Jeremy Whiting.


Changes
---

Submitted with commit 38685ad63b08a6c1c4de2c2ecd525188aecd3e94 by Kevin Funk to 
branch master.


Repository: knewstuff


Description
---

Fixes issues leading to creation of QTBUG-47240


Diffs
-

  src/CMakeLists.txt cc606444e48b0e519551183c022ccecdac0aa62f 

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


Testing
---


Thanks,

Kevin Funk

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

Re: Review Request 126595: [KFileMetaData] Allow querying for a file's origin URL

[Kai Uwe Broulik]

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

(Updated Jan. 2, 2016, 1:32 vorm.)


Review request for KDE Frameworks and Vishesh Handa.


Changes
---

Add PropertyInfo stuff


Repository: kfilemetadata


Description
---

This attribute is set, for example by Chrome and newer versions of wget, and 
indicates the original URL this file was downloaded from.

https://wiki.freedesktop.org/www/CommonExtendedAttributes/


Diffs (updated)
-

  src/properties.h 64ba0be 
  src/propertyinfo.cpp 0b298b6 
  src/usermetadata.h ab58e16 
  src/usermetadata.cpp 51c87f8 

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


Testing
---

Works.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 126587: Add option to build with gcov support

[Aleix Pol Gonzalez]

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


Well, then it's implemented by `ECMCoverageOption.cmake` in ECM, and included 
by `KDECompilerSettings.cmake`. If anything, the proper fix would be to remove 
this kind of code from elsewhere.

- Aleix Pol Gonzalez


On Dec. 31, 2015, 10:13 p.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126587/
> ---
> 
> (Updated Dec. 31, 2015, 10:13 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kjsembed
> 
> 
> Description
> ---
> 
> Add option to build with gcov support
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 916970287c070c07a60f8dbcd5f0758ac602038e 
> 
> Diff: https://git.reviewboard.kde.org/r/126587/diff/
> 
> 
> Testing
> ---
> 
> Compiles
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/189/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:46:11 +
Build duration: 4 min 24 sec

CHANGE SET
Revision 4af8a6b3c49a02f42f4d48b92fc47f6742cebdbc by David Faure: (Repair 
renaming A to A2 (erroneous error cannot move into itself))
  change: edit src/core/copyjob.cpp
  change: edit autotests/jobtest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24914/50103 
(50%)CONDITIONAL 13467/20815 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7103/7320 
(97%)CONDITIONAL 3879/7129 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7440/14038 
(53%)CONDITIONAL 3908/5433 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2281/7586 
(30%)CONDITIONAL 907/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 
313/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2695/10634 
(25%)CONDITIONAL 1278/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/189/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:46:11 +
Build duration: 4 min 24 sec

CHANGE SET
Revision 4af8a6b3c49a02f42f4d48b92fc47f6742cebdbc by David Faure: (Repair 
renaming A to A2 (erroneous error cannot move into itself))
  change: edit src/core/copyjob.cpp
  change: edit autotests/jobtest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24914/50103 
(50%)CONDITIONAL 13467/20815 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7103/7320 
(97%)CONDITIONAL 3879/7129 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7440/14038 
(53%)CONDITIONAL 3908/5433 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2281/7586 
(30%)CONDITIONAL 907/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 
313/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2695/10634 
(25%)CONDITIONAL 1278/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/197/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:46:11 +
Build duration: 14 min

CHANGE SET
Revision 4af8a6b3c49a02f42f4d48b92fc47f6742cebdbc by David Faure: (Repair 
renaming A to A2 (erroneous error cannot move into itself))
  change: edit src/core/copyjob.cpp
  change: edit autotests/jobtest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 25020/50101 
(50%)CONDITIONAL 13527/20867 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7101/7318 
(97%)CONDITIONAL 3882/7129 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7499/14038 
(53%)CONDITIONAL 3941/5457 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7586 
(30%)CONDITIONAL 907/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 
284/412 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2695/10634 
(25%)CONDITIONAL 1280/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126587: Add option to build with gcov support

[Aleix Pol Gonzalez]

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


That's provided by ecm, isn't it?

- Aleix Pol Gonzalez


On Dec. 31, 2015, 10:13 p.m., Dāvis Mosāns wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126587/
> ---
> 
> (Updated Dec. 31, 2015, 10:13 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kjsembed
> 
> 
> Description
> ---
> 
> Add option to build with gcov support
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 916970287c070c07a60f8dbcd5f0758ac602038e 
> 
> Diff: https://git.reviewboard.kde.org/r/126587/diff/
> 
> 
> Testing
> ---
> 
> Compiles
> 
> 
> Thanks,
> 
> Dāvis Mosāns
> 
>

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

Review Request 126595: [KFileMetaData] Allow querying for a file's origin URL

[Kai Uwe Broulik]

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

Review request for KDE Frameworks and Vishesh Handa.


Repository: kfilemetadata


Description
---

This attribute is set, for example by Chrome and newer versions of wget, and 
indicates the original URL this file was downloaded from.

https://wiki.freedesktop.org/www/CommonExtendedAttributes/


Diffs
-

  src/usermetadata.h ab58e16 
  src/usermetadata.cpp 51c87f8 

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


Testing
---

Works.


Thanks,

Kai Uwe Broulik

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

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/197/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:46:11 +
Build duration: 14 min

CHANGE SET
Revision 4af8a6b3c49a02f42f4d48b92fc47f6742cebdbc by David Faure: (Repair 
renaming A to A2 (erroneous error cannot move into itself))
  change: edit src/core/copyjob.cpp
  change: edit autotests/jobtest.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 25020/50101 
(50%)CONDITIONAL 13527/20867 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7101/7318 
(97%)CONDITIONAL 3882/7129 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7499/14038 
(53%)CONDITIONAL 3941/5457 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7586 
(30%)CONDITIONAL 907/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 
284/412 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2695/10634 
(25%)CONDITIONAL 1280/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

On Friday January 01 2016 20:24:59 Christoph Cullmann wrote:

Hi,

> Guess I should add the handling to Kate/KWrite ;=)

I just made a quick attempt, not very successful. From what I understand, you 
either have to subclass QApplication in order to provide a dedicated ::event() 
method, or maybe you can use an event filter. That's what I tried. The filter 
gets loads of application events, but not the QEvent::FileOpen event we're 
interested in.

'night,
René
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana

[David Faure]

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


This is kdelibs4support, this code is doomed to disappear and apps are using 
kDebug less and less. Is it worth risking compilation breakages on some systems?

Also I found kBacktrace less and less useful over the years because with hidden 
visibility I get a lot of "???" for non-exported methods. gdb works much better.

- David Faure


On Dec. 10, 2015, 10:10 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126309/
> ---
> 
> (Updated Dec. 10, 2015, 10:10 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and 
> demangling support on OS X, FreeBSD and Solaris/OpenIndiana.
> The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/
> 
> It seems that change was never incorporated because of a single open issue 
> for which I never found the time (also given that it seemed a bit overkill).
> 
> My PC-BSD and Indiana VMs are no longer operational; it seems highly likely 
> that the current code still works but if further testing or polishing is 
> required I'll rather remove the specific parts than bring the VMs online 
> again.
> 
> 
> Diffs
> -
> 
>   src/kdecore/kdebug.cpp 6f04dce 
> 
> Diff: https://git.reviewboard.kde.org/r/126309/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with 
> gcc and clang, PC-BSD with clang and on Open Indiana. 
> 
> The KDE4 RR raises some doubts concerning checking for only an OS and not 
> compilers (in demangling). I think there is no reason for such doubts: 
> compilers are obliged to co-exist and be compatible nowadays, at least on 
> individual OS families (each platform will have its own default/dominant 
> compiler that is used to build the system libraries). In practice it turns 
> out that gcc and clang use the same C++ mangling scheme. The only difference 
> is in the way `backtrace_symbols()` formats the stack, and that indeed 
> appears to defined the OS rather than by the compiler used.
> (Then again I'm willing to stand corrected by someone who has a Linux system 
> built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :))
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 126313: Use an xcb for interaction with KStartupInfo

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Dec. 11, 2015, 2:08 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126313/
> ---
> 
> (Updated Dec. 11, 2015, 2:08 p.m.)
> 
> 
> Review request for KDE Frameworks and David Faure.
> 
> 
> Repository: kinit
> 
> 
> Description
> ---
> 
> By changing to xcb we can use NETRootInfo to get the current desktop
> and don't need to duplicate the logic. Also it means that more code
> is ported from XLib to xcb and might allow us to drop the XLib
> dependency in future.
> 
> 
> Diffs
> -
> 
>   src/kdeinit/kinit.cpp a18008a11bf00a35aa0cab450180926217cd58f5 
>   src/kdeinit/CMakeLists.txt f94db717f2403b602648286eac243837d8714069 
>   src/config-kdeinit.h.cmake cfcfc61a1bb560ff9a902b89bd3b8fb27273ebf2 
>   CMakeLists.txt eeecab775cfb5dfe12cf9c4991c658cc261ed727 
> 
> Diff: https://git.reviewboard.kde.org/r/126313/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/188/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 14:53:04 +
Build duration: 5 min 9 sec

CHANGE SET
Revision d5298d70cd16ea21987ab05ce7ecf2ccec069780 by David Faure: (Fix deadlock 
with Qt  5.6)
  change: edit src/kiod/kiod_main.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 45 test(s), Skipped: 0 test(s), Total: 
47 test(s)Failed: TestSuite.kiocore-jobtestFailed: 
TestSuite.kiowidgets-fileundomanagertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24899/50098 
(50%)CONDITIONAL 13466/20801 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7091/7319 
(97%)CONDITIONAL 3873/7109 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7438/14034 
(53%)CONDITIONAL 3915/5439 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2281/7586 
(30%)CONDITIONAL 908/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 430/843 (51%)CONDITIONAL 
313/459 (68%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 684/1182 (58%)CONDITIONAL 
358/495 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
433/820 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 384/600 (64%)CONDITIONAL 
280/408 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
144/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2694/10634 
(25%)CONDITIONAL 1277/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126149: [Icon widget] Bring back properties dialog

[David Faure]

> On Dec. 29, 2015, 6:07 p.m., Kai Uwe Broulik wrote:
> > I completely screwed up my Kate desktop files :( Would it help if I set 
> > NoDisplay or Hidden on the desktop file copy so it's there for the icon 
> > widget but not shown in the Open With dialogs and so on? Or, if I copied 
> > the desktop file elsewhere (eg. not into the local share applications)?
> > 
> > Also, I should probably delete the desktop file again if the widget is 
> > removed :)

If you set NoDisplay or Hidden in ~/.local/share/applications/kate.desktop then 
this will fully hide kate from your K menu. That's a local override.

Desktop files in the panel or on the desktop should probably be copies, yes (in 
other dirs than ~/.local/share/applications/)


- David


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


On Dec. 21, 2015, 11:31 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126149/
> ---
> 
> (Updated Dec. 21, 2015, 11:31 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Bugs: 349177
> https://bugs.kde.org/show_bug.cgi?id=349177
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This brings back the KPropertiesDialog to modify an icon's appearance. This 
> has been requested at multiple occasions. This has been adapted from the 
> Plasma 4 icon code.
> 
> 
> Diffs
> -
> 
>   applets/icon/package/contents/ui/main.qml 9286b94 
>   applets/icon/plugin/icon_p.h dd7963c 
>   applets/icon/plugin/icon_p.cpp e086870 
> 
> Diff: https://git.reviewboard.kde.org/r/126149/diff/
> 
> 
> Testing
> ---
> 
> Dropped a file from my home onto the desktop -> dialog from the actual file, 
> allowing to rename it. The applet reflected the changes.
> 
> Dropped an application from kickoff to the desktop -> dialog from a copy of 
> the desktop file, allowing to change its icon and description. The applet 
> reflected the changes.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

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

[no-reply]

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/196/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 14:53:04 +
Build duration: 13 min

CHANGE SET
Revision d5298d70cd16ea21987ab05ce7ecf2ccec069780 by David Faure: (Fix deadlock 
with Qt  5.6)
  change: edit src/kiod/kiod_main.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 45 test(s), Skipped: 0 test(s), Total: 
47 test(s)Failed: TestSuite.kiocore-jobtestFailed: 
TestSuite.kiowidgets-fileundomanagertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 20/20 (100%)FILES 253/331 (76%)CLASSES 253/331 (76%)LINE 24986/50096 
(50%)CONDITIONAL 13520/20843 (65%)

By packages
  
autotests
FILES 61/61 (100%)CLASSES 61/61 (100%)LINE 7089/7317 
(97%)CONDITIONAL 3873/7109 (54%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 475/476 
(100%)CONDITIONAL 166/272 (61%)
autotests.kcookiejar
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 182/199 (91%)CONDITIONAL 
60/90 (67%)
src.core
FILES 94/116 (81%)CLASSES 94/116 (81%)LINE 7478/14034 
(53%)CONDITIONAL 3941/5453 (72%)
src.core.kssl
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 35/93 (38%)CONDITIONAL 
3/6 (50%)
src.filewidgets
FILES 20/36 (56%)CLASSES 20/36 (56%)LINE 2286/7586 
(30%)CONDITIONAL 907/1399 (65%)
src.ioslaves.file
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 435/843 (52%)CONDITIONAL 
317/461 (69%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 750/3799 
(20%)CONDITIONAL 547/678 (81%)
src.ioslaves.http.kcookiejar
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 642/804 (80%)CONDITIONAL 
602/758 (79%)
src.ioslaves.trash
FILES 7/9 (78%)CLASSES 7/9 (78%)LINE 718/1182 (61%)CONDITIONAL 
373/515 (72%)
src.ioslaves.trash.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 690/768 (90%)CONDITIONAL 
434/822 (53%)
src.kioslave
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 14/26 (54%)CONDITIONAL 
5/10 (50%)
src.kntlm
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 302/388 (78%)CONDITIONAL 
86/108 (80%)
src.kpasswdserver
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 389/600 (65%)CONDITIONAL 
285/412 (69%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 280/285 (98%)CONDITIONAL 
146/254 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 32/35 (91%)CONDITIONAL 
42/52 (81%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 248/743 (33%)CONDITIONAL 
147/194 (76%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 20/27 (74%)CONDITIONAL 
14/18 (78%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 227/257 (88%)CONDITIONAL 
293/358 (82%)
src.widgets
FILES 29/62 (47%)CLASSES 29/62 (47%)LINE 2694/10634 
(25%)CONDITIONAL 1279/1874 (68%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126474: Port QRegExp to QRegularExpression in kshorturifilter

[David Faure]

> On Jan. 1, 2016, 5:15 p.m., David Faure wrote:
> > src/urifilters/shorturi/kshorturifilter.cpp, line 58
> > 
> >
> > "despite" sounds like the api docs say that it's not thread safe. 
> > AFAICS the docs don't say anything either way. I agree that one shouldn't 
> > assume thread-safety unless explicitly documented, but I think it's just an 
> > omission in the doc, the whole point of the QRegularExpression API is 
> > thread safety.

I talked to Giuseppe, he'll update the docu to mention thread safety.


- David


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


On Dec. 28, 2015, 2:20 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126474/
> ---
> 
> (Updated Dec. 28, 2015, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> A static QRegExp was used but it is not thread safe. QRegularExpression
> seems to be.
> 
> BUG: 352356
> 
> 
> Diffs
> -
> 
>   src/urifilters/shorturi/kshorturifilter.cpp 
> 6002ec6925c0acdd20a053f98baca46863f69fa6 
> 
> Diff: https://git.reviewboard.kde.org/r/126474/diff/
> 
> 
> Testing
> ---
> 
> I ran the autotests which includes urifilter and I've run krunner which uses 
> it extensively.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 125869: Convert all io slave .protocol data to json and embed it.

[Christoph Cullmann]

> On Jan. 1, 2016, 6:12 p.m., Alex Richardson wrote:
> > I added support for translating the ExtraNames key here: 
> > https://svn.reviewboard.kde.org/r/7154/

Cool ;=) Which nice new year present! Thanks!


- Christoph


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


On Dec. 28, 2015, 7:25 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125869/
> ---
> 
> (Updated Dec. 28, 2015, 7:25 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David 
> Faure, and Luigi Toscano.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Convert all io slave .protocol data to json and embed it.
> Allows easier deployment of the slaves.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 7bfb9ad 
>   src/protocoltojson/main.cpp 05b9364 
> 
> Diff: https://git.reviewboard.kde.org/r/125869/diff/
> 
> 
> Testing
> ---
> 
> Tests still work (one needed patching, as the exec line contains now the full 
> path).
> 
> Correction: Somehow the ./autotests/jobtest test is unstable for me here, 
> sometimes it works, sometimes not :/ but even without this change.
> 
> 
> File Attachments
> 
> 
> trash.json
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/28/6ab2cd95-b0bd-4347-80f2-6f753fa50425__trash.json
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: Review Request 125869: Convert all io slave .protocol data to json and embed it.

[Christoph Cullmann]

> On Oct. 30, 2015, 7:29 a.m., David Faure wrote:
> > src/ioslaves/trash/trash.json, line 6
> > 
> >
> > That doesn't look very English to me ;)
> > 
> > The original is:
> > 
> > ExtraNames=Original Path,Deletion Date
> > 
> > But this shows a problem: missing support for translating this field. 
> > We didn't realize there was a translatable field in these files. Please add 
> > support for translations, like was done for other json files (talk to e.g. 
> > Luigi Toscano).
> 
> Christoph Cullmann wrote:
> Hmm, then we have a problem: We can no longer convert the stuff and 
> remove the .protocol files, or?
> 
> Christoph Cullmann wrote:
> Ok, did read up a bit, ExtraNames seems to be the only translated thing 
> (at least if I read KProtocolInfo docs the right way).
> Can do the same trick as desktop2json does for that. Seems not that hard.
> But then we need CMake stuff for it, or? To convert on the fly to have 
> translations using the .protocol files like we have ATM in the .desktop files 
> for the plugin stuff.
> 
> David Faure wrote:
> I don't think you're looking in the right direction. AFAIK there is 
> support for translating json files directly in l10n (json -> po -> json) 
> these days. As I said, please ask Luigi or maybe Albert.
> 
> Christoph Cullmann wrote:
> Ok ;=)
> 
> Christoph Cullmann wrote:
> CC Luigi here, too.
> I looked again at what we have btw. in the other frameworks and I nowhere 
> really found any json -> po and back way, but that doesn't mean its not there 
> ;=)
> 
> David Faure wrote:
> I'm pretty sure this is all done in the l10n module, not in the other 
> frameworks.
> 
> Christoph Cullmann wrote:
> Any idea who else to ping? With that patch at least the shipped IO slaves 
> work perfect on Win/Lin without any hacks, I would really like to get that 
> in. Some .protocol -> json -> ... translation stuff should be easy to do, but 
> for translating the list inside JSON I am a bit lost ;=)
> 
> Luigi Toscano wrote:
> Generically, the i18n (or l10n, never rememeber) group. This specific 
> code (translation of json) was done by Burkhard Lueck. Now, I was out for 
> vacation and business, so give some time. It's too late anyway from the next 
> framework version, so there is one month.

Hi,

can I commit my changes to the converted + the i18n aware reading?

Will do a new review request for the actual conversion of the remaining 
.protocol files afterwards.


- Christoph


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


On Dec. 28, 2015, 7:25 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125869/
> ---
> 
> (Updated Dec. 28, 2015, 7:25 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David 
> Faure, and Luigi Toscano.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Convert all io slave .protocol data to json and embed it.
> Allows easier deployment of the slaves.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 7bfb9ad 
>   src/protocoltojson/main.cpp 05b9364 
> 
> Diff: https://git.reviewboard.kde.org/r/125869/diff/
> 
> 
> Testing
> ---
> 
> Tests still work (one needed patching, as the exec line contains now the full 
> path).
> 
> Correction: Somehow the ./autotests/jobtest test is unstable for me here, 
> sometimes it works, sometimes not :/ but even without this change.
> 
> 
> File Attachments
> 
> 
> trash.json
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/28/6ab2cd95-b0bd-4347-80f2-6f753fa50425__trash.json
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[Christoph Cullmann]

Hi,

> On Friday January 01 2016 17:47:17 Christoph Cullmann wrote:
> 
> Hi,
> 
> Apparently you already looked into this?
> 
>> I can tell you that this needs to be done at the application level, not at 
>> kpart
>> level.
> 
> Can you explain why? Does that mean it won't be possible to encapsulate the
> functionality in a framework?
I think the Qt support is already ok enough, the application just needs to 
handle it.
That should just be a few lines of code, not sure if any more wrapping will 
make this less work.

> 
>> E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus 
>> request
>> to open
>> a new file (atm I guess only the variant that has some url is feasible, the
>> other variant
>> won't work with the current interfaces to the editor part we have).
> 
> The QString QFE::file() variant, or the one that returns an opened QFile? I'm
> not sure that one would even be relevant (or even in what circumstances it has
> to be used).
I think the one with the QString is atm the thing Kate can easily support.

> 
>> 
>> Same for e.g. KWrite, just open a new windows with the file, like file open.
> 
> If memory serves me well, the old MacOS used to handle file open requests like
> that: it would more or less send the same even to the application that would 
> be
> sent when using the File/Open menu, and somehow shortcut the file selection
> dialog.
> At least, that's what the guy I shared my office with claimed, but he was
> usually right about this kind of thing :)
Then that is all fine, as long as Qt handles all right with the QFileOpenEvent 
each app
that wants to have support just needs 5 lines of handling this event.

Guess I should add the handling to Kate/KWrite ;=)

Greetings
Christoph

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

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

Re: Review Request 125158: add logic to use icons for default xdg user dirs

[Kai Uwe Broulik]

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


Would be cool if we could have something like this for KIO::iconNameForUrl as 
well

- Kai Uwe Broulik


On Okt. 22, 2015, 7:26 vorm., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125158/
> ---
> 
> (Updated Okt. 22, 2015, 7:26 vorm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 352498
> https://bugs.kde.org/show_bug.cgi?id=352498
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> this acts as an additional fallback to mimetype iconing and .directory
> overrides. xdg user dirs are relocatable and can change depending on user
> locale as well as user configuration and additionally are used in a range
> of different desktop environments making this a very runtime sort of
> decision.
> 
> BUG: 352498
> 
> 
> Diffs
> -
> 
>   autotests/kfileitemtest.h 615324f2b45fdc90a7841bdd0c8aa7f47cdf57a2 
>   autotests/kfileitemtest.cpp 5f728a411401fe3009924b66970d9ae6f12c60f2 
>   src/core/kfileitem.cpp 966d8626708a8f2672f1777c873f4e27e13023d6 
> 
> Diff: https://git.reviewboard.kde.org/r/125158/diff/
> 
> 
> Testing
> ---
> 
> maked
> autotested
> installed
> dolphin and file open dialogs now show icons
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

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

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/78/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:34:06 +
Build duration: 4 min 6 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21842/42932 
(51%)CONDITIONAL 14658/24875 (59%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11566/11817 
(98%)CONDITIONAL 8471/16536 (51%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9314/16971 
(55%)CONDITIONAL 5724/7617 (75%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 946/9794 
(10%)CONDITIONAL 460/716 (64%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2416 (1%)CONDITIONAL 
3/6 (50%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/0 
(100%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1713 (0%)CONDITIONAL 0/0 
(100%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/195 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kdelibs4support%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/78/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 01 Jan 2016 19:34:06 +
Build duration: 4 min 6 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 4/7 (57%)FILES 161/269 (60%)CLASSES 161/269 (60%)LINE 21842/42932 
(51%)CONDITIONAL 14658/24875 (59%)

By packages
  
autotests
FILES 64/64 (100%)CLASSES 64/64 (100%)LINE 11566/11817 
(98%)CONDITIONAL 8471/16536 (51%)
src.kdecore
FILES 75/94 (80%)CLASSES 75/94 (80%)LINE 9314/16971 
(55%)CONDITIONAL 5724/7617 (75%)
src.kdeui
FILES 18/70 (26%)CLASSES 18/70 (26%)LINE 946/9794 
(10%)CONDITIONAL 460/716 (64%)
src.kio
FILES 4/27 (15%)CLASSES 4/27 (15%)LINE 16/2416 (1%)CONDITIONAL 
3/6 (50%)
src.kparts
FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/26 (0%)CONDITIONAL 0/0 
(100%)
src.kssl
FILES 0/8 (0%)CLASSES 0/8 (0%)LINE 0/1713 (0%)CONDITIONAL 0/0 
(100%)
src.solid
FILES 0/5 (0%)CLASSES 0/5 (0%)LINE 0/195 (0%)CONDITIONAL 0/0 
(100%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126385: PartManager: stop tracking a widget even if it is no longer a top level window

[David Faure]

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

Ship it!


I agree -- except about the "aside" in the commit log:

"since all signal connections to 'this' are removed on destruction anyway". 
They are indeed, but *after* destroyed is emitted. So disconnecting does make a 
difference.

- David Faure


On Dec. 16, 2015, 1:33 p.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126385/
> ---
> 
> (Updated Dec. 16, 2015, 1:33 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 355711
> https://bugs.kde.org/show_bug.cgi?id=355711
> 
> 
> Repository: kparts
> 
> 
> Description
> ---
> 
> This appears to be the cause of a crash when exiting System Settings.  More 
> information in the bug report, but basically what happens is that the manager 
> keeps track of widgets that it is managing in d->m_managedTopLevelWidgets.  
> If a widget is a top level widget when it is added, but is no longer top 
> level when it is destroyed, it is not removed from the list which results in 
> an access-to-deleted-object in the destructor.
> 
> This change unconditionally removes the widget even if it is no longer top 
> level.  Removing the widget from the list has no ill effects, the list is 
> only actually used in Partmanager::eventFilter() which will never get an 
> event for a deleted widget anyway.
> 
> Aside:  The problematic 'foreach (const QWidget *w, 
> d->m_managedTopLevelWidgets)' loop in PartManager::PartManager() is really 
> superfluous, since all signal connections to 'this' are removed on 
> destruction anyway.
> 
> 
> Diffs
> -
> 
>   src/partmanager.cpp 81bf73f 
> 
> Diff: https://git.reviewboard.kde.org/r/126385/diff/
> 
> 
> Testing
> ---
> 
> Built KParts with this change, and also systemsettings5 with the associated 
> change (see associated review).  Observed no crash when exiting the 
> application.  Also checked correct operation of Konqueror and Kate.
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

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

new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

Hi,

Best wishes for 2016!

As hinted in the subject, I've dusted off a resolution from last year: finding 
a way to support opening files "the Mac way".
Some of you probably know that OS X doesn't hand off the documents to be opened 
in the standard argc,argv way when an application is started through the Finder 
(LaunchServices in general). Rather, a specific event is sent that contains a 
reference to the file; this mechanism is the same whether the application is 
already started or not.

Qt has had an interface to the underlying mechanism since at least v4.6, but 
KDE never used it. I see that KF5 applications already set the NSPrincipalClass 
to NSApplication; that is a requirement, but not a sufficient one for the 
mechanism to work.

When the system receives the request to open a file, Qt will send an instance 
of a QFileOpenEvent to the QApplication instance, which will need to take 
action on it. This event contains the filename, but also a function that is 
capable of opening files that cannot simply be opened by name.

I think it should be possible to connect (the filename from) this event to a 
central mechanism that signals applications that a file should be opened. But I 
am not so sure if such a mechanism exists. I would assume that KDE applications 
have been designed for the kind of desktop shell that is used on Linux and MS 
Windows, in which the GUI for opening a document with a given application 
spawns a new instance of that application which receives the filename through 
the argc,argv interface.
It should be relatively easy to write a handler for QFileOpenEvents that just 
spawns a new copy of the running process, something like

 fork()
 execvp(argv[0], qFileOpenEvent->file())

and let the child process decide whether it should continue to exist as a 
separate application or hand off the argument(s) to the running 
KUniqueApplication instance. Drawbacks: in the first case the separate child 
process will open somewhere behind the parent process; in the latter case we'd 
be taking a detour (but there may not be a standard way in which 
KUniqueApplications hand off documents to be opened to the running instance?).

So what are the options here to hook into the QFileOpenEvent feature in such a 
way that applications need to as little modification as possible to deploy the 
new functionality? It's likely though that they'd require a dedicated 
Info.plist file.

If multiple solutions exist, I'd prefer those which are easiest to backport to 
KDE4 (for local patching).

Anyway, I'd be interested in beginning to work on a proof of concept 
implementation using Kate (hopefully in the kpart so that all applications 
building on the Kate editor can benefit). Or should I rather aim for 
KTextEditor or even KXmlGui? Anyone care to think along with me on this one?

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

Re: Review Request 126426: Add a warning color to kwalletd's password dialogs

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Dec. 24, 2015, 5:55 p.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126426/
> ---
> 
> (Updated Dec. 24, 2015, 5:55 p.m.)
> 
> 
> Review request for KDE Frameworks, KDE Usability and Valentin Rusu.
> 
> 
> Repository: kwallet
> 
> 
> Description
> ---
> 
> Set a "background warning color" when password and its verification do not 
> match, in the KNewPasswordDialog run by kwalletd.
> This adds a new dependency (needed to avoid hardcoding colors), but I think 
> is a nice feature to have.
> See RR 125619 for a screenshot: 
> https://git.reviewboard.kde.org/r/125619/file/2515/
> 
> 
> Diffs
> -
> 
>   src/runtime/kwalletd/CMakeLists.txt 
> ba9e7ba508c74fed1d8101496583061245640aa7 
>   src/runtime/kwalletd/kwalletd.cpp 6da97031e13240a9630cfa7e0dc3cf42575819c4 
> 
> Diff: https://git.reviewboard.kde.org/r/126426/diff/
> 
> 
> Testing
> ---
> 
> Compiles fine.
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

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

Re: Review Request 126453: Fix library order

[David Faure]

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

Ship it!


Hmm, OK. It's really not obvious that order matters here (or what the right 
order would be). It all depends on what you have in /usr/include. But ok.

- David Faure


On Dec. 21, 2015, 4:06 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126453/
> ---
> 
> (Updated Dec. 21, 2015, 4:06 p.m.)
> 
> 
> Review request for KDE Frameworks, Heiko Becker and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Fixes issues leading to creation of QTBUG-47240
> 
> 
> Diffs
> -
> 
>   src/CMakeLists.txt cc606444e48b0e519551183c022ccecdac0aa62f 
> 
> Diff: https://git.reviewboard.kde.org/r/126453/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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

Re: Review Request 126474: Port QRegExp to QRegularExpression in kshorturifilter

[David Faure]

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

Ship it!



src/urifilters/shorturi/kshorturifilter.cpp (line 58)


"despite" sounds like the api docs say that it's not thread safe. AFAICS 
the docs don't say anything either way. I agree that one shouldn't assume 
thread-safety unless explicitly documented, but I think it's just an omission 
in the doc, the whole point of the QRegularExpression API is thread safety.


- David Faure


On Dec. 28, 2015, 2:20 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126474/
> ---
> 
> (Updated Dec. 28, 2015, 2:20 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> A static QRegExp was used but it is not thread safe. QRegularExpression
> seems to be.
> 
> BUG: 352356
> 
> 
> Diffs
> -
> 
>   src/urifilters/shorturi/kshorturifilter.cpp 
> 6002ec6925c0acdd20a053f98baca46863f69fa6 
> 
> Diff: https://git.reviewboard.kde.org/r/126474/diff/
> 
> 
> Testing
> ---
> 
> I ran the autotests which includes urifilter and I've run krunner which uses 
> it extensively.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Re: Review Request 126507: Fix leaked file description and potential use-after-free in kdelibs4support

[David Faure]

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



src/kdeui/k4style.cpp (line 1213)


this condition used to be evaluated when tiles was non-null (i.e. key in 
cache). In your patch, key-in-cache goes to the very first branch and not here 
anymore.


- David Faure


On Dec. 25, 2015, 12:16 a.m., Michael Pyne wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126507/
> ---
> 
> (Updated Dec. 25, 2015, 12:16 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> Fix a couple of Coverity issues:
> 
> 1. CID 1175508; file descriptors used in KLockFile could be leaked in
> error conditions. Even when KLockFile sets mustCloseFd, the dtor's impl
> also checks that the lock has been taken, which is only considered true
> if LockOK had been returned in our lock function. Instead close() the fd
> ourselves unless we make it to LockOK.
> 
> 2. CID 117; The standard mis-use of QCache. QCache::insert can, in
> theory, delete our object as soon as we insert it into cache, so we have
> to check for that. Even ::contains() and ::object() can be risky (the
> pointers returned by object() have no lifetime guarantee), but since
> this is GUI code I assume it's only used single-threaded and not
> re-entrant. Otherwise we'd need even more paranoia...
> 
> 
> Diffs
> -
> 
>   src/kdecore/klockfile_unix.cpp 67283a5 
>   src/kdeui/k4style.cpp a1a2ab1 
> 
> Diff: https://git.reviewboard.kde.org/r/126507/diff/
> 
> 
> Testing
> ---
> 
> Everything builds and appears to still work, though it's hard to test K4Style 
> as I'm not sure what uses it right at this point.
> 
> 
> Thanks,
> 
> Michael Pyne
> 
>

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

Re: Splitting KActivities, 2nd attempt...

[David Faure]

On Friday 01 January 2016 18:07:59 Ivan Čukić wrote:
> 
> So, applications that do link to activities will run and work
> uninterrupted even if the service is not present.

OK, sounds good to me. 

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana

[René J . V . Bertin]

> On Jan. 1, 2016, 4:04 p.m., David Faure wrote:
> > This is kdelibs4support, this code is doomed to disappear and apps are 
> > using kDebug less and less. Is it worth risking compilation breakages on 
> > some systems?
> > 
> > Also I found kBacktrace less and less useful over the years because with 
> > hidden visibility I get a lot of "???" for non-exported methods. gdb works 
> > much better.

I'd hope that we can avoid the compilation breakages and have no idea of the 
timescale of planned obsolescence.

I'm actually still getting pretty useful backtraces in KDE4 applications; I'd 
have to see how that works out for Qt5 apps (QtCurve uses kdelibs4support; I 
could use that to get kbacktraces from pretty "deep" places ;) ).

So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built on 
kdelibs4support itself?


- René J.V.


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


On Dec. 10, 2015, 11:10 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126309/
> ---
> 
> (Updated Dec. 10, 2015, 11:10 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and 
> demangling support on OS X, FreeBSD and Solaris/OpenIndiana.
> The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/
> 
> It seems that change was never incorporated because of a single open issue 
> for which I never found the time (also given that it seemed a bit overkill).
> 
> My PC-BSD and Indiana VMs are no longer operational; it seems highly likely 
> that the current code still works but if further testing or polishing is 
> required I'll rather remove the specific parts than bring the VMs online 
> again.
> 
> 
> Diffs
> -
> 
>   src/kdecore/kdebug.cpp 6f04dce 
> 
> Diff: https://git.reviewboard.kde.org/r/126309/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with 
> gcc and clang, PC-BSD with clang and on Open Indiana. 
> 
> The KDE4 RR raises some doubts concerning checking for only an OS and not 
> compilers (in demangling). I think there is no reason for such doubts: 
> compilers are obliged to co-exist and be compatible nowadays, at least on 
> individual OS families (each platform will have its own default/dominant 
> compiler that is used to build the system libraries). In practice it turns 
> out that gcc and clang use the same C++ mangling scheme. The only difference 
> is in the way `backtrace_symbols()` formats the stack, and that indeed 
> appears to defined the OS rather than by the compiler used.
> (Then again I'm willing to stand corrected by someone who has a Linux system 
> built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :))
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[Christoph Cullmann]

Hi,

> Hi,
> 
> Best wishes for 2016!
> 
> As hinted in the subject, I've dusted off a resolution from last year: 
> finding a
> way to support opening files "the Mac way".
> Some of you probably know that OS X doesn't hand off the documents to be 
> opened
> in the standard argc,argv way when an application is started through the 
> Finder
> (LaunchServices in general). Rather, a specific event is sent that contains a
> reference to the file; this mechanism is the same whether the application is
> already started or not.
> 
> Qt has had an interface to the underlying mechanism since at least v4.6, but 
> KDE
> never used it. I see that KF5 applications already set the NSPrincipalClass to
> NSApplication; that is a requirement, but not a sufficient one for the
> mechanism to work.
> 
> When the system receives the request to open a file, Qt will send an instance 
> of
> a QFileOpenEvent to the QApplication instance, which will need to take action
> on it. This event contains the filename, but also a function that is capable 
> of
> opening files that cannot simply be opened by name.
> 
> I think it should be possible to connect (the filename from) this event to a
> central mechanism that signals applications that a file should be opened. But 
> I
> am not so sure if such a mechanism exists. I would assume that KDE 
> applications
> have been designed for the kind of desktop shell that is used on Linux and MS
> Windows, in which the GUI for opening a document with a given application
> spawns a new instance of that application which receives the filename through
> the argc,argv interface.
> It should be relatively easy to write a handler for QFileOpenEvents that just
> spawns a new copy of the running process, something like
> 
> fork()
> execvp(argv[0], qFileOpenEvent->file())
> 
> and let the child process decide whether it should continue to exist as a
> separate application or hand off the argument(s) to the running
> KUniqueApplication instance. Drawbacks: in the first case the separate child
> process will open somewhere behind the parent process; in the latter case we'd
> be taking a detour (but there may not be a standard way in which
> KUniqueApplications hand off documents to be opened to the running instance?).
> 
> So what are the options here to hook into the QFileOpenEvent feature in such a
> way that applications need to as little modification as possible to deploy the
> new functionality? It's likely though that they'd require a dedicated
> Info.plist file.
> 
> If multiple solutions exist, I'd prefer those which are easiest to backport to
> KDE4 (for local patching).
> 
> Anyway, I'd be interested in beginning to work on a proof of concept
> implementation using Kate (hopefully in the kpart so that all applications
> building on the Kate editor can benefit). Or should I rather aim for
> KTextEditor or even KXmlGui? Anyone care to think along with me on this one?
I can tell you that this needs to be done at the application level, not at 
kpart level.

E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus request 
to open
a new file (atm I guess only the variant that has some url is feasible, the 
other variant
won't work with the current interfaces to the editor part we have).

Same for e.g. KWrite, just open a new windows with the file, like file open.

Greetings
Christoph

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

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

Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana

[David Faure]

> On Jan. 1, 2016, 3:04 p.m., David Faure wrote:
> > This is kdelibs4support, this code is doomed to disappear and apps are 
> > using kDebug less and less. Is it worth risking compilation breakages on 
> > some systems?
> > 
> > Also I found kBacktrace less and less useful over the years because with 
> > hidden visibility I get a lot of "???" for non-exported methods. gdb works 
> > much better.
> 
> René J.V. Bertin wrote:
> I'd hope that we can avoid the compilation breakages and have no idea of 
> the timescale of planned obsolescence.
> 
> I'm actually still getting pretty useful backtraces in KDE4 applications; 
> I'd have to see how that works out for Qt5 apps (QtCurve uses 
> kdelibs4support; I could use that to get kbacktraces from pretty "deep" 
> places ;) ).
> 
> So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built 
> on kdelibs4support itself?

My problems where in kde4 apps.

drkonqi attaches a debugger, it does not use a backtrace function.


- David


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


On Dec. 10, 2015, 10:10 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126309/
> ---
> 
> (Updated Dec. 10, 2015, 10:10 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and 
> demangling support on OS X, FreeBSD and Solaris/OpenIndiana.
> The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/
> 
> It seems that change was never incorporated because of a single open issue 
> for which I never found the time (also given that it seemed a bit overkill).
> 
> My PC-BSD and Indiana VMs are no longer operational; it seems highly likely 
> that the current code still works but if further testing or polishing is 
> required I'll rather remove the specific parts than bring the VMs online 
> again.
> 
> 
> Diffs
> -
> 
>   src/kdecore/kdebug.cpp 6f04dce 
> 
> Diff: https://git.reviewboard.kde.org/r/126309/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with 
> gcc and clang, PC-BSD with clang and on Open Indiana. 
> 
> The KDE4 RR raises some doubts concerning checking for only an OS and not 
> compilers (in demangling). I think there is no reason for such doubts: 
> compilers are obliged to co-exist and be compatible nowadays, at least on 
> individual OS families (each platform will have its own default/dominant 
> compiler that is used to build the system libraries). In practice it turns 
> out that gcc and clang use the same C++ mangling scheme. The only difference 
> is in the way `backtrace_symbols()` formats the stack, and that indeed 
> appears to defined the OS rather than by the compiler used.
> (Then again I'm willing to stand corrected by someone who has a Linux system 
> built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :))
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: Review Request 126429: Fixed all Clazy warnings level 1 and level 2

[David Faure]

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

Ship it!


Ship It!

- David Faure


On Dec. 23, 2015, 7:50 p.m., Artur Puzio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126429/
> ---
> 
> (Updated Dec. 23, 2015, 7:50 p.m.)
> 
> 
> Review request for KDE Frameworks, Aleix Pol Gonzalez and Sergio Martins.
> 
> 
> Repository: karchive
> 
> 
> Description
> ---
> 
> Fixed warning: Folder has dtor but not copy-ctor, copy-assignment 
> [-Wclazy-rule-of-three], by adding Q_DISABLE_COPY(Folder)
> Fixed warning: unused variable [-Wunused-const-variable], by commenting 
> unused variables
> 
> 
> Diffs
> -
> 
>   src/k7zip.cpp 7b5e6a3 
> 
> Diff: https://git.reviewboard.kde.org/r/126429/diff/
> 
> 
> Testing
> ---
> 
> Automated tests pass.
> 
> 
> Thanks,
> 
> Artur Puzio
> 
>

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

Re: Splitting KActivities, 2nd attempt...

[Ivan Čukić]

> Shouldn't the service be part of the framework?
> How usable is the framework without the service?
> Compiling is good, but running is even better :-)

This is the reason why the split has not happened before.

The purpose of the library is:
[1] - to report document/resource events to the service
[2] - to allow applications to see what activities exist, to see what
is the current activity, and to request activity creation, switching,
etc (these few latest features are generally intended to be used by
the workspace, not by the application, but it can be used by anyone).

If the service is not running [1] is ignorred (nowhere to send the
data to), [2] shows that there is only one activity present and
applications do not need to implement two different behaviours for
activity-enabled and activity-disabled environments.

So, applications that do link to activities will run and work
uninterrupted even if the service is not present.

Currently, more than a few apps have ifdefs for
kactivities-enabled/disabled, which is not the ideal situation.

At some point, somebody might want to implement the [1] for windows or
mac using the platform systems for usage tracking.

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

Re: KHolidays as Framework (redux)

[David Faure]

On Thursday 24 December 2015 12:28:13 John Layt wrote:
> Hi,
> 
> It's xmas holidays, so it must be time to poke a stick at KHolidays again
> for inclusion as a Framework. As far as I am aware there are no outstanding
> porting issues with KHolidays and it is ready for review to be included as
> a Tier 1 Framework in the next possible release. What's the next step?

Please make sure it passes all of the items in this checklist
https://community.kde.org/Frameworks/CreationGuidelines

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

Re: Review Request 126309: backtrace and demangle for OS X, FreeBSD and Solaris/OpenIndiana

[René J . V . Bertin]

> On Jan. 1, 2016, 4:04 p.m., David Faure wrote:
> > This is kdelibs4support, this code is doomed to disappear and apps are 
> > using kDebug less and less. Is it worth risking compilation breakages on 
> > some systems?
> > 
> > Also I found kBacktrace less and less useful over the years because with 
> > hidden visibility I get a lot of "???" for non-exported methods. gdb works 
> > much better.
> 
> René J.V. Bertin wrote:
> I'd hope that we can avoid the compilation breakages and have no idea of 
> the timescale of planned obsolescence.
> 
> I'm actually still getting pretty useful backtraces in KDE4 applications; 
> I'd have to see how that works out for Qt5 apps (QtCurve uses 
> kdelibs4support; I could use that to get kbacktraces from pretty "deep" 
> places ;) ).
> 
> So how does DrKonqi/KF5 work? Doesn't it use equivalent code if not built 
> on kdelibs4support itself?
> 
> David Faure wrote:
> My problems where in kde4 apps.
> 
> drkonqi attaches a debugger, it does not use a backtrace function.

Ah, hum, you're right. A debugger which doesn't always return control to 
drkonqi (when it's lldb), I knew that all too well ...


- René J.V.


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


On Dec. 10, 2015, 11:10 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126309/
> ---
> 
> (Updated Dec. 10, 2015, 11:10 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kdelibs4support
> 
> 
> Description
> ---
> 
> This is a "backport" of the patches to `kdebug.cpp` that enable backtrace and 
> demangling support on OS X, FreeBSD and Solaris/OpenIndiana.
> The KDE4 version was discussed here: https://git.reviewboard.kde.org/r/121213/
> 
> It seems that change was never incorporated because of a single open issue 
> for which I never found the time (also given that it seemed a bit overkill).
> 
> My PC-BSD and Indiana VMs are no longer operational; it seems highly likely 
> that the current code still works but if further testing or polishing is 
> required I'll rather remove the specific parts than bring the VMs online 
> again.
> 
> 
> Diffs
> -
> 
>   src/kdecore/kdebug.cpp 6f04dce 
> 
> Diff: https://git.reviewboard.kde.org/r/126309/diff/
> 
> 
> Testing
> ---
> 
> On Kubuntu 14.04 with various gcc versions and clang; OS X 10.6 - 10.9 with 
> gcc and clang, PC-BSD with clang and on Open Indiana. 
> 
> The KDE4 RR raises some doubts concerning checking for only an OS and not 
> compilers (in demangling). I think there is no reason for such doubts: 
> compilers are obliged to co-exist and be compatible nowadays, at least on 
> individual OS families (each platform will have its own default/dominant 
> compiler that is used to build the system libraries). In practice it turns 
> out that gcc and clang use the same C++ mangling scheme. The only difference 
> is in the way `backtrace_symbols()` formats the stack, and that indeed 
> appears to defined the OS rather than by the compiler used.
> (Then again I'm willing to stand corrected by someone who has a Linux system 
> built from scratch with clang and libc++, or possibly a Gnu/BSD set-up :))
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

Re: [KDE/Mac] new year's resolution: opening files "the Mac way" (TM)

[René J . V . Bertin]

On Friday January 01 2016 17:47:17 Christoph Cullmann wrote:

Hi,

Apparently you already looked into this?

> I can tell you that this needs to be done at the application level, not at 
> kpart level.

Can you explain why? Does that mean it won't be possible to encapsulate the 
functionality in a framework?

> E.g. in Kate, you would need to handle QFileOpenEvent just like a dbus 
> request to open
> a new file (atm I guess only the variant that has some url is feasible, the 
> other variant
> won't work with the current interfaces to the editor part we have).

The QString QFE::file() variant, or the one that returns an opened QFile? I'm 
not sure that one would even be relevant (or even in what circumstances it has 
to be used).

> 
> Same for e.g. KWrite, just open a new windows with the file, like file open.

If memory serves me well, the old MacOS used to handle file open requests like 
that: it would more or less send the same even to the application that would be 
sent when using the File/Open menu, and somehow shortcut the file selection 
dialog.
At least, that's what the guy I shared my office with claimed, but he was 
usually right about this kind of thing :)

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

Re: Review Request 125869: Convert all io slave .protocol data to json and embed it.

[Alex Richardson]

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


I added support for translating the ExtraNames key here: 
https://svn.reviewboard.kde.org/r/7154/

- Alex Richardson


On Dec. 28, 2015, 7:25 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125869/
> ---
> 
> (Updated Dec. 28, 2015, 7:25 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Alex Richardson, David 
> Faure, and Luigi Toscano.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Convert all io slave .protocol data to json and embed it.
> Allows easier deployment of the slaves.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 7bfb9ad 
>   src/protocoltojson/main.cpp 05b9364 
> 
> Diff: https://git.reviewboard.kde.org/r/125869/diff/
> 
> 
> Testing
> ---
> 
> Tests still work (one needed patching, as the exec line contains now the full 
> path).
> 
> Correction: Somehow the ./autotests/jobtest test is unstable for me here, 
> sometimes it works, sometimes not :/ but even without this change.
> 
> 
> File Attachments
> 
> 
> trash.json
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/28/6ab2cd95-b0bd-4347-80f2-6f753fa50425__trash.json
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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