Re: Review Request 128263: Don't include embedded contrainers in containmentAt(pos) - fix crash when adding a system tray.

2016-06-21 Thread David Edmundson 

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

(Updated June 21, 2016, 12:54 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Do to so means the System Tray applet ends up being placed inside the
system tray container. This causes a recursive parent loop, creating a stack
overflow every time parent() is called recursively

This happens whenever one drags a sys tray on the desktop or simply adds
a new system tray whilst running.

BUG: 361777

We also need to do a hack for Plasma/5.7 in plasma-desktop somehow in
all cases where this is used as this is a huge bug.


Diffs
-

  src/scriptengines/qml/plasmoid/containmentinterface.cpp 
db77db9abeafa508dd26c23710a657584ad1ef0b 

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


Testing
---


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 128263: Don't include embedded contrainers in containmentAt(pos) - fix crash when adding a system tray.

2016-06-21 Thread Marco Martin 

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


Ship it!




Ship It!

- Marco Martin


On June 20, 2016, 8:08 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128263/
> ---
> 
> (Updated June 20, 2016, 8:08 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Do to so means the System Tray applet ends up being placed inside the
> system tray container. This causes a recursive parent loop, creating a stack
> overflow every time parent() is called recursively
> 
> This happens whenever one drags a sys tray on the desktop or simply adds
> a new system tray whilst running.
> 
> BUG: 361777
> 
> We also need to do a hack for Plasma/5.7 in plasma-desktop somehow in
> all cases where this is used as this is a huge bug.
> 
> 
> Diffs
> -
> 
>   src/scriptengines/qml/plasmoid/containmentinterface.cpp 
> db77db9abeafa508dd26c23710a657584ad1ef0b 
> 
> Diff: https://git.reviewboard.kde.org/r/128263/diff/
> 
> 
> Testing
> ---
> 
> 
> 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 127912: Add 2 methods to gain more info about a mimetype or protocol

2016-06-21 Thread Martin Kostolný 


> On May 14, 2016, 1:59 p.m., David Faure wrote:
> > But how is the app supposed to then choose which protocol to use?
> > 
> > If it needs its own setting for the preferred kioslave, then what's the 
> > point of the query that returns a list?
> > 
> > In other words, if you know you want to prefer krarc, why not just query 
> > whether krarc is available and use it if yes?
> 
> Martin Kostolný wrote:
> I'm sorry, it is very well possible that I don't know the required API 
> for these queries. It is as You said: basically I need to test whether 
> krarc:/ is available and I also need to test if given mimetype can be handled 
> by krarc protocol. Is there a way to achieve that with current KIO API? 
> Thanks!
> 
> David Faure wrote:
> To find if krarc is available, use 
> KProtocolInfo::isKnownProtocol("krarc").
> 
> To find which archive mimetypes "krarc" can support, hmm, there was no 
> API for it, so I just added it. KProtocolInfo::archiveMimeTypes("krarc"), 
> requires KF 5.23 (released next month).
> See http://commits.kde.org/kio/a60c6c437067c9daa2b5bbe6638ba4080342dacf
> 
> Martin Kostolný wrote:
> Perfect, thanks a lot! :-)
> 
> Martin Kostolný wrote:
> Sorry for bothering again. The new 
> KProtocolManager::protocolsForArchiveMimetype(...) is not included in final 
> KF 5.23 package. I'm saying that only to let you know. I'm not sure how 
> exactly version tagging workflow works - should I inform somebody else who 
> e.g. picks commits to created version tags?
> 
> David Faure wrote:
> As I wrote, I added KProtocolInfo::archiveMimeTypes, not 
> KProtocolManager::protocolsForArchiveMimetype.

Apologies for my ignorance, You are right. Thanks again!


- Martin


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


On May 23, 2016, 4:49 a.m., Martin Kostolný wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127912/
> ---
> 
> (Updated May 23, 2016, 4:49 a.m.)
> 
> 
> Review request for KDE Frameworks, Krusader, David Edmundson, David Faure, 
> and Marco Martin.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> KProtocolManager has a method called protocolForArchiveMimetype. It gives one 
> protocol for given mimetype even if there exist more then one protocol 
> capable of handling this mimetype.
> 
> I suggest adding a method called protocolsForArchiveMimetype (note the "s") 
> which would give us all protocols that can handle given mimetype. I also 
> suggest to add a method for giving all archive mimetypes for given protocol.
> 
> This request is based on a potential need of some apps to prioritize one 
> protocol over others (specifically krarc:/ from Krusader over other 
> archive-handling protocols).
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolmanager.h 13b8c07 
>   src/core/kprotocolmanager.cpp 9a0a96f 
> 
> Diff: https://git.reviewboard.kde.org/r/127912/diff/
> 
> 
> Testing
> ---
> 
> I've tested both methods through Krusader code. Partially covered in this 
> phabricator task: https://phabricator.kde.org/T2401
> 
> 
> Thanks,
> 
> Martin Kostolný
> 
>

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

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

2016-06-21 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kparts%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/116/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 21 Jun 2016 10:54:06 +
Build duration: 2 min 8 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 20/46 (43%)CLASSES 20/46 (43%)LINE 602/2603 
(23%)CONDITIONAL 198/1422 (14%)

By packages
  
autotests
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 175/186 (94%)CONDITIONAL 
77/156 (49%)
src
FILES 17/43 (40%)CLASSES 17/43 (40%)LINE 427/2417 
(18%)CONDITIONAL 121/1266 (10%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

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

2016-06-21 Thread no-reply 

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kparts%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/116/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 21 Jun 2016 10:54:06 +
Build duration: 2 min 8 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 20/46 (43%)CLASSES 20/46 (43%)LINE 602/2603 
(23%)CONDITIONAL 198/1422 (14%)

By packages
  
autotests
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 175/186 (94%)CONDITIONAL 
77/156 (49%)
src
FILES 17/43 (40%)CLASSES 17/43 (40%)LINE 427/2417 
(18%)CONDITIONAL 121/1266 (10%)___
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 # 111 - Still Unstable!

2016-06-21 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/111/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 21 Jun 2016 10:40:51 +
Build duration: 11 min

CHANGE SET
Revision 5bfd8cd7b2b62c95f66871c1f049650a52975379 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/urifilters/ikws/searchproviders/soundcloud.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 49 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/340 (76%)CLASSES 260/340 (76%)LINE 26775/50739 
(53%)CONDITIONAL 14934/37493 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7549/7862 
(96%)CONDITIONAL 4195/8168 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(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 95/117 (81%)CLASSES 95/117 (81%)LINE 7678/14041 
(55%)CONDITIONAL 4147/8907 (47%)
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 2271/7565 
(30%)CONDITIONAL 914/4407 (21%)
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 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1754/3781 
(46%)CONDITIONAL 1249/3434 (36%)
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 684/760 (90%)CONDITIONAL 
435/916 (47%)
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 359/385 (93%)CONDITIONAL 
102/138 (74%)
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 
327/408 (80%)
src.widgets
FILES 29/64 (45%)CLASSES 29/64 (45%)LINE 2675/10685 
(25%)CONDITIONAL 1336/6844 (20%)___
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 # 111 - Still Unstable!

2016-06-21 Thread no-reply 

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/111/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Tue, 21 Jun 2016 10:40:51 +
Build duration: 8 min 19 sec

CHANGE SET
Revision 5bfd8cd7b2b62c95f66871c1f049650a52975379 by scripty: (SVN_SILENT made 
messages (.desktop file) - always resolve ours)
  change: edit src/urifilters/ikws/searchproviders/soundcloud.desktop


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 49 test(s), Skipped: 0 test(s), Total: 
50 test(s)Failed: TestSuite.kiowidgets-kurifiltertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/340 (76%)CLASSES 260/340 (76%)LINE 26736/50720 
(53%)CONDITIONAL 14920/37469 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7530/7843 
(96%)CONDITIONAL 4183/8144 (51%)
autotests.http
FILES 9/9 (100%)CLASSES 9/9 (100%)LINE 529/530 
(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 95/117 (81%)CLASSES 95/117 (81%)LINE 7656/14041 
(55%)CONDITIONAL 4140/8907 (46%)
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 2268/7565 
(30%)CONDITIONAL 914/4407 (21%)
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 428/833 (51%)CONDITIONAL 
318/719 (44%)
src.ioslaves.http
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 1761/3781 
(47%)CONDITIONAL 1255/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 684/760 (90%)CONDITIONAL 
435/916 (47%)
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 359/385 (93%)CONDITIONAL 
102/138 (74%)
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 
327/408 (80%)
src.widgets
FILES 29/64 (45%)CLASSES 29/64 (45%)LINE 2673/10685 
(25%)CONDITIONAL 1333/6844 (19%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127912: Add 2 methods to gain more info about a mimetype or protocol

2016-06-21 Thread David Faure 


> On May 14, 2016, 1:59 p.m., David Faure wrote:
> > But how is the app supposed to then choose which protocol to use?
> > 
> > If it needs its own setting for the preferred kioslave, then what's the 
> > point of the query that returns a list?
> > 
> > In other words, if you know you want to prefer krarc, why not just query 
> > whether krarc is available and use it if yes?
> 
> Martin Kostolný wrote:
> I'm sorry, it is very well possible that I don't know the required API 
> for these queries. It is as You said: basically I need to test whether 
> krarc:/ is available and I also need to test if given mimetype can be handled 
> by krarc protocol. Is there a way to achieve that with current KIO API? 
> Thanks!
> 
> David Faure wrote:
> To find if krarc is available, use 
> KProtocolInfo::isKnownProtocol("krarc").
> 
> To find which archive mimetypes "krarc" can support, hmm, there was no 
> API for it, so I just added it. KProtocolInfo::archiveMimeTypes("krarc"), 
> requires KF 5.23 (released next month).
> See http://commits.kde.org/kio/a60c6c437067c9daa2b5bbe6638ba4080342dacf
> 
> Martin Kostolný wrote:
> Perfect, thanks a lot! :-)
> 
> Martin Kostolný wrote:
> Sorry for bothering again. The new 
> KProtocolManager::protocolsForArchiveMimetype(...) is not included in final 
> KF 5.23 package. I'm saying that only to let you know. I'm not sure how 
> exactly version tagging workflow works - should I inform somebody else who 
> e.g. picks commits to created version tags?

As I wrote, I added KProtocolInfo::archiveMimeTypes, not 
KProtocolManager::protocolsForArchiveMimetype.


- David


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


On May 23, 2016, 4:49 a.m., Martin Kostolný wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127912/
> ---
> 
> (Updated May 23, 2016, 4:49 a.m.)
> 
> 
> Review request for KDE Frameworks, Krusader, David Edmundson, David Faure, 
> and Marco Martin.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> KProtocolManager has a method called protocolForArchiveMimetype. It gives one 
> protocol for given mimetype even if there exist more then one protocol 
> capable of handling this mimetype.
> 
> I suggest adding a method called protocolsForArchiveMimetype (note the "s") 
> which would give us all protocols that can handle given mimetype. I also 
> suggest to add a method for giving all archive mimetypes for given protocol.
> 
> This request is based on a potential need of some apps to prioritize one 
> protocol over others (specifically krarc:/ from Krusader over other 
> archive-handling protocols).
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolmanager.h 13b8c07 
>   src/core/kprotocolmanager.cpp 9a0a96f 
> 
> Diff: https://git.reviewboard.kde.org/r/127912/diff/
> 
> 
> Testing
> ---
> 
> I've tested both methods through Krusader code. Partially covered in this 
> phabricator task: https://phabricator.kde.org/T2401
> 
> 
> Thanks,
> 
> Martin Kostolný
> 
>

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

Re: Review Request 127912: Add 2 methods to gain more info about a mimetype or protocol

2016-06-21 Thread Martin Kostolný 


> On May 14, 2016, 1:59 p.m., David Faure wrote:
> > But how is the app supposed to then choose which protocol to use?
> > 
> > If it needs its own setting for the preferred kioslave, then what's the 
> > point of the query that returns a list?
> > 
> > In other words, if you know you want to prefer krarc, why not just query 
> > whether krarc is available and use it if yes?
> 
> Martin Kostolný wrote:
> I'm sorry, it is very well possible that I don't know the required API 
> for these queries. It is as You said: basically I need to test whether 
> krarc:/ is available and I also need to test if given mimetype can be handled 
> by krarc protocol. Is there a way to achieve that with current KIO API? 
> Thanks!
> 
> David Faure wrote:
> To find if krarc is available, use 
> KProtocolInfo::isKnownProtocol("krarc").
> 
> To find which archive mimetypes "krarc" can support, hmm, there was no 
> API for it, so I just added it. KProtocolInfo::archiveMimeTypes("krarc"), 
> requires KF 5.23 (released next month).
> See http://commits.kde.org/kio/a60c6c437067c9daa2b5bbe6638ba4080342dacf
> 
> Martin Kostolný wrote:
> Perfect, thanks a lot! :-)

Sorry for bothering again. The new 
KProtocolManager::protocolsForArchiveMimetype(...) is not included in final KF 
5.23 package. I'm saying that only to let you know. I'm not sure how exactly 
version tagging workflow works - should I inform somebody else who e.g. picks 
commits to created version tags?


- Martin


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


On May 23, 2016, 4:49 a.m., Martin Kostolný wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127912/
> ---
> 
> (Updated May 23, 2016, 4:49 a.m.)
> 
> 
> Review request for KDE Frameworks, Krusader, David Edmundson, David Faure, 
> and Marco Martin.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> KProtocolManager has a method called protocolForArchiveMimetype. It gives one 
> protocol for given mimetype even if there exist more then one protocol 
> capable of handling this mimetype.
> 
> I suggest adding a method called protocolsForArchiveMimetype (note the "s") 
> which would give us all protocols that can handle given mimetype. I also 
> suggest to add a method for giving all archive mimetypes for given protocol.
> 
> This request is based on a potential need of some apps to prioritize one 
> protocol over others (specifically krarc:/ from Krusader over other 
> archive-handling protocols).
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolmanager.h 13b8c07 
>   src/core/kprotocolmanager.cpp 9a0a96f 
> 
> Diff: https://git.reviewboard.kde.org/r/127912/diff/
> 
> 
> Testing
> ---
> 
> I've tested both methods through Krusader code. Partially covered in this 
> phabricator task: https://phabricator.kde.org/T2401
> 
> 
> Thanks,
> 
> Martin Kostolný
> 
>

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

Re: Review Request 128249: Add switch to disable KParts' handling of window titles

2016-06-21 Thread David Faure 

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



Would it be better to just have a setter and a member bool for this? It's 
unlikely that we need some calls to set the title and some to not set it, so 
this way the setting is set once and for all (and the purpose of the bool is 
readable from the method name) - and this typically scales better than methods 
with many args.

- David Faure


On June 19, 2016, 12:35 p.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128249/
> ---
> 
> (Updated June 19, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Kevin Funk.
> 
> 
> Repository: kparts
> 
> 
> Description
> ---
> 
> Applications that use several KParts, like KDevelop, want to do the
> window title settings themselves. To enable that without causing a
> flickering of the KParts' title and the application's title, an
> explicit switch is required, since simply removing the setWindowTitle
> connection after executing a KParts::MainWindow::createGUI(...) call still
> causes an initial flickering, when the GUIActivateEvent is sent in
> the createGUI method. Sending such an event should stay in the createGUI
> method, though.
> 
> 
> Diffs
> -
> 
>   src/mainwindow.h 61a92e32e638c187253ba9e2cf0d8a410e9966af 
>   src/mainwindow.cpp be0b7ddc637d509f4c8191134096e365616ab38a 
> 
> Diff: https://git.reviewboard.kde.org/r/128249/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

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

Re: Review Request 128249: Add switch to disable KParts' handling of window titles

2016-06-21 Thread Kevin Funk 

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



Rest LGTM


src/mainwindow.cpp (line 81)


Turn boolean parameter into enum maybe?

E.g.:

```
enum CreationFlag
{
ManageWindowTitle = 0 << 1
}
Q_DECLARE_FLAGS(CreationFlag, CreationFlags)

void createGUI(Part*, CreationFlags flags);
```

Makes the user code a bit easier to read.


- Kevin Funk


On June 19, 2016, 12:35 p.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128249/
> ---
> 
> (Updated June 19, 2016, 12:35 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Kevin Funk.
> 
> 
> Repository: kparts
> 
> 
> Description
> ---
> 
> Applications that use several KParts, like KDevelop, want to do the
> window title settings themselves. To enable that without causing a
> flickering of the KParts' title and the application's title, an
> explicit switch is required, since simply removing the setWindowTitle
> connection after executing a KParts::MainWindow::createGUI(...) call still
> causes an initial flickering, when the GUIActivateEvent is sent in
> the createGUI method. Sending such an event should stay in the createGUI
> method, though.
> 
> 
> Diffs
> -
> 
>   src/mainwindow.h 61a92e32e638c187253ba9e2cf0d8a410e9966af 
>   src/mainwindow.cpp be0b7ddc637d509f4c8191134096e365616ab38a 
> 
> Diff: https://git.reviewboard.kde.org/r/128249/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

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