Re: Review Request 126131: Don't delete gl texture twice in thumbnail

2016-07-15 Thread Mindaugas Baranauskas


> On Nov. 22, 2015, 1:24 p.m., Alex Merry wrote:
> > Ship It!
> 
> Mindaugas Baranauskas wrote:
> Seems that with this patch KDE Plasma crash more often: 
> https://bugs.kde.org/show_bug.cgi?id=357895#c22
> 
> David Edmundson wrote:
> @Mindaugas 
> 
> Can you try this patch now that 1e196fdfb2a6eaf1664e1155c086616d55c6712b 
> which fixes the bug you mentioned is merged. It's an unrelated change.

I would be happpy if someone else could test.


- Mindaugas


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


On Nov. 22, 2015, 1:57 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126131/
> ---
> 
> (Updated Nov. 22, 2015, 1:57 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> The QSGTextures are created with
> 
> window()->createTextureFromId(m_texture, QSize(w,h),
> QuickWindow::TextureOwnsGLTexture));
> 
> this means we don't want to be deleting textures ourselves too, it will
> be deleted when we delete the QSGTexture, which is a scoped pointer
> inside our QSGNode.
> 
> BUG: 355644
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.cpp 
> 2b09657e8ce6bd1cca1acc323d5955b2f1a1efb2 
> 
> Diff: https://git.reviewboard.kde.org/r/126131/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 128464: Allow scrolling in config windows for small screens

2016-07-15 Thread Olivier Churlaud

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



Same patch should be applied to Konversation.

- Olivier Churlaud


On July 16, 2016, 2:52 a.m., Olivier Churlaud wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128464/
> ---
> 
> (Updated July 16, 2016, 2:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 360260 and 362234
> https://bugs.kde.org/show_bug.cgi?id=360260
> https://bugs.kde.org/show_bug.cgi?id=362234
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Often I cannot reach the validation buttons of config windows. With this fix 
> I can.
> 
> The config page has now scroll bars when needed.
> 
> 
> Diffs
> -
> 
>   src/kconfigdialog.cpp 83c96b6 
> 
> Diff: https://git.reviewboard.kde.org/r/128464/diff/
> 
> 
> Testing
> ---
> 
> Compile and tested: Good behavior
> 
> 
> Thanks,
> 
> Olivier Churlaud
> 
>

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


Need help: Use of KConfig

2016-07-15 Thread Olivier Churlaud

Hi,

I spent a lot of time tonight, trying to port a config dialog out of 
KButtonGroup (in Okular). I read that I should instead use QButtonGroup 
+ QGroupBox. I did this, and this part works.


The problem I have is that the KConfig-thing doesn't write/read from 
this QButtonGroup. And indeed, this is commented in 
https://api.kde.org/frameworks/kconfigwidgets/html/kconfigdialogmanager_8cpp_source.html#l00153.


How should I do to have several radio buttons to select one system 
configuration?


Thank you

Olivier


--
Olivier CHURLAUD
Engineer Student at Ecole Centrale de Lyon
in Dual Degree at TU Berlin, M.Sc. Elektrotechnik
@: oliv...@churlaud.com
tel: +49 (0)1575-2931348
in:  http://linkedin.com/in/olivierchurlaud
web: http://olivier.churlaud.com



Jenkins-kde-ci: plasma-framework master kf5-qt5 » Linux,All,gcc - Build # 101 - Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/101/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Fri, 15 Jul 2016 20:12:52 +
Build duration: 6 min 22 sec

CHANGE SET
Revision bb9c50d25feb2608b2ef0ec1ed52430f89b2f4a3 by kainz.a: (update wifi 
networks available icon)
  change: edit src/desktoptheme/breeze/icons/network.svgz


JUNIT RESULTS

Name: (root) Failed: 6 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 
15 test(s)Failed: TestSuite.coronatestFailed: TestSuite.dialognativetestFailed: 
TestSuite.plasma-configmodeltestFailed: 
TestSuite.plasma-sortfiltermodeltestFailed: TestSuite.plasma-storagetestFailed: 
TestSuite.plasma-themetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 5/7 (71%)FILES 48/98 (49%)CLASSES 48/98 (49%)LINE 3012/10219 
(29%)CONDITIONAL 1570/7265 (22%)

By packages
  
autotests
FILES 16/16 (100%)CLASSES 16/16 (100%)LINE 559/587 
(95%)CONDITIONAL 306/630 (49%)
src.declarativeimports.core
FILES 9/18 (50%)CLASSES 9/18 (50%)LINE 499/2096 
(24%)CONDITIONAL 196/1292 (15%)
src.plasma
FILES 9/20 (45%)CLASSES 9/20 (45%)LINE 1042/3641 
(29%)CONDITIONAL 635/2728 (23%)
src.plasma.private
FILES 9/26 (35%)CLASSES 9/26 (35%)LINE 519/1802 
(29%)CONDITIONAL 218/1080 (20%)
src.plasma.scripting
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/181 (0%)CONDITIONAL 0/106 
(0%)
src.plasmaquick
FILES 5/12 (42%)CLASSES 5/12 (42%)LINE 393/1799 
(22%)CONDITIONAL 215/1407 (15%)
src.plasmaquick.private
FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/113 (0%)CONDITIONAL 0/22 
(0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 103 - Still Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/103/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Fri, 15 Jul 2016 20:12:52 +
Build duration: 6 min 21 sec

CHANGE SET
Revision bb9c50d25feb2608b2ef0ec1ed52430f89b2f4a3 by kainz.a: (update wifi 
networks available icon)
  change: edit src/desktoptheme/breeze/icons/network.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 
15 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 79/117 (68%)CLASSES 79/117 (68%)LINE 4912/11782 
(42%)CONDITIONAL 2633/8791 (30%)

By packages
  
autotests
FILES 28/28 (100%)CLASSES 28/28 (100%)LINE 981/1024 
(96%)CONDITIONAL 614/1194 (51%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 646/2096 
(31%)CONDITIONAL 296/1292 (23%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1682/3641 
(46%)CONDITIONAL 956/2728 (35%)
src.plasma.private
FILES 16/26 (62%)CLASSES 16/26 (62%)LINE 968/1802 
(54%)CONDITIONAL 441/1080 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 556/1799 
(31%)CONDITIONAL 304/1407 (22%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 103 - Still Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/103/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Fri, 15 Jul 2016 20:12:52 +
Build duration: 8 min 19 sec

CHANGE SET
Revision bb9c50d25feb2608b2ef0ec1ed52430f89b2f4a3 by kainz.a: (update wifi 
networks available icon)
  change: edit src/desktoptheme/breeze/icons/network.svgz


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 13 test(s), Skipped: 0 test(s), Total: 
14 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 76/113 (67%)CLASSES 76/113 (67%)LINE 4504/11311 
(40%)CONDITIONAL 2359/8437 (28%)

By packages
  
autotests
FILES 26/26 (100%)CLASSES 26/26 (100%)LINE 934/977 
(96%)CONDITIONAL 598/1162 (51%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 559/1868 
(30%)CONDITIONAL 213/1142 (19%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1680/3641 
(46%)CONDITIONAL 951/2728 (35%)
src.plasma.private
FILES 15/24 (63%)CLASSES 15/24 (63%)LINE 924/1729 
(53%)CONDITIONAL 421/1034 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 328/1676 
(20%)CONDITIONAL 154/1281 (12%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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

2016-07-15 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/51/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 15 Jul 2016 17:57:09 +
Build duration: 2 min 44 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 63/135 (47%)CLASSES 63/135 (47%)LINE 3297/13448 
(25%)CONDITIONAL 1243/6991 (18%)

By packages
  
autotests
FILES 23/23 (100%)CLASSES 23/23 (100%)LINE 1103/1105 
(100%)CONDITIONAL 548/1068 (51%)
src
FILES 40/112 (36%)CLASSES 40/112 (36%)LINE 2194/12343 
(18%)CONDITIONAL 695/5923 (12%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


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

2016-07-15 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/51/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 15 Jul 2016 17:57:09 +
Build duration: 2 min 44 sec

CHANGE SET
No changes


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 63/135 (47%)CLASSES 63/135 (47%)LINE 3297/13448 
(25%)CONDITIONAL 1243/6991 (18%)

By packages
  
autotests
FILES 23/23 (100%)CLASSES 23/23 (100%)LINE 1103/1105 
(100%)CONDITIONAL 548/1068 (51%)
src
FILES 40/112 (36%)CLASSES 40/112 (36%)LINE 2194/12343 
(18%)CONDITIONAL 695/5923 (12%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Jenkins-kde-ci: kwidgetsaddons master kf5-qt5 » Linux,gcc - Build # 50 - Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/50/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 15 Jul 2016 16:31:02 +
Build duration: 3 min 47 sec

CHANGE SET
Revision 981585082d2a6a79fc8c9cceb2d8cacb324930b9 by Ragnar Thomsen: 
(KCollapsibleGroupBox: Stop animation in destructor if still running)
  change: edit src/kcollapsiblegroupbox.cpp
  change: edit autotests/CMakeLists.txt
  change: add autotests/kcollapsiblegroupbox_test.cpp
  change: add autotests/kcollapsiblegroupbox_test.h


JUNIT RESULTS

Name: (root) Failed: 7 test(s), Passed: 5 test(s), Skipped: 0 test(s), Total: 
12 test(s)Failed: TestSuite.kmessagewidgetautotestFailed: 
TestSuite.knewpasswordwidgettestFailed: TestSuite.kpagedialogautotestFailed: 
TestSuite.kselectaction_unittestFailed: 
TestSuite.ksplittercollapserbuttontestFailed: 
TestSuite.ktimecomboboxtestFailed: TestSuite.kwidgetsaddons-kcolumnresizertest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 28/123 (23%)CLASSES 28/123 (23%)LINE 1836/12858 
(14%)CONDITIONAL 667/6483 (10%)

By packages
  
autotests
FILES 11/11 (100%)CLASSES 11/11 (100%)LINE 513/515 
(100%)CONDITIONAL 287/560 (51%)
src
FILES 17/112 (15%)CLASSES 17/112 (15%)LINE 1323/12343 
(11%)CONDITIONAL 380/5923 (6%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 128406: KCollapsibleGroupBox: Stop animation if still running in destructor

2016-07-15 Thread Ragnar Thomsen

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

(Updated July 15, 2016, 4:30 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Kai Uwe Broulik, David Edmundson, and Elvis 
Angelaccio.


Changes
---

Submitted with commit 981585082d2a6a79fc8c9cceb2d8cacb324930b9 by Ragnar 
Thomsen to branch master.


Repository: kwidgetsaddons


Description
---

We are using KCollapsibleGroupBox in Ark and stumbled upon a segfault in an 
autotest involving this widget (see backtrace 
[here](https://paste.kde.org/pwcohd64z)). It looks like QTimeLine::stop() gets 
called after KCollapsibleGroupBox is deleted. This causes 
QTimeLine::stateChanged to get emitted which then calls 
KCollapsibleGroupBox::updateChildrenVisibility() that causes the crash.

To see the crash, clone the newAddDialog branch of Ark and run the autotests.

This diff calls QTimeLine::stop() in the KCollapsibleGroupBox dtor if it is 
running, before deleting the d pointer.


Diffs
-

  autotests/CMakeLists.txt 4be2eaf 
  autotests/kcollapsiblegroupbox_test.h PRE-CREATION 
  autotests/kcollapsiblegroupbox_test.cpp PRE-CREATION 
  src/kcollapsiblegroupbox.cpp 0c3f866 

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


Testing
---

The autotests in newAddDialog branch of Ark pass with this diff.


Thanks,

Ragnar Thomsen

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


Re: Review Request 128406: KCollapsibleGroupBox: Stop animation if still running in destructor

2016-07-15 Thread Ragnar Thomsen

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

(Updated July 15, 2016, 6:13 p.m.)


Review request for KDE Frameworks, Kai Uwe Broulik, David Edmundson, and Elvis 
Angelaccio.


Changes
---

Connect to deleteLater() directly, instead of using lambda function. Thanks 
Broulik :)


Repository: kwidgetsaddons


Description
---

We are using KCollapsibleGroupBox in Ark and stumbled upon a segfault in an 
autotest involving this widget (see backtrace 
[here](https://paste.kde.org/pwcohd64z)). It looks like QTimeLine::stop() gets 
called after KCollapsibleGroupBox is deleted. This causes 
QTimeLine::stateChanged to get emitted which then calls 
KCollapsibleGroupBox::updateChildrenVisibility() that causes the crash.

To see the crash, clone the newAddDialog branch of Ark and run the autotests.

This diff calls QTimeLine::stop() in the KCollapsibleGroupBox dtor if it is 
running, before deleting the d pointer.


Diffs (updated)
-

  autotests/CMakeLists.txt 4be2eaf 
  autotests/kcollapsiblegroupbox_test.h PRE-CREATION 
  autotests/kcollapsiblegroupbox_test.cpp PRE-CREATION 
  src/kcollapsiblegroupbox.cpp 0c3f866 

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


Testing
---

The autotests in newAddDialog branch of Ark pass with this diff.


Thanks,

Ragnar Thomsen

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


Re: Review Request 125830: Read protocol info from plugin metadata

2016-07-15 Thread David Faure


> On July 15, 2016, 8:35 a.m., David Faure wrote:
> > The problem with this change is that klauncher no longer recognizes freshly 
> > installed kioslaves.
> > 
> > Testcase:
> > $ git clone g...@github.com:shortstheory/staging-kioslave
> > $ compile and install
> > $ kioclient5 list stash:/
> > KIO::ProtoQueue::createSlave: couldn't create slave: "Unable to create 
> > io-slave:\nklauncher said: Unknown protocol 'stash'.\n"
> > 
> > Either we need to compare directory mtimes, or we need to refill the cache 
> > in case we hit an unknown protocol, hopefully this doesn't happen in tight 
> > loops.
> > I implemented the latter. https://git.reviewboard.kde.org/r/128458/
> 
> Christoph Cullmann wrote:
> Hmm, actually, the old code did use the cache, too, once is was filled. 
> Was that codepath never triggered?

Ah indeed, maybe it's an older problem then, not a regression from this commit. 
I don't test new kioslaves every day :-)


- David


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


On Oct. 29, 2015, 10:58 a.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 29, 2015, 10:58 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> 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 128458: KProtocolInfo: refill cache to find newly installed protocols

2016-07-15 Thread Christoph Cullmann

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



Given we refill the cache now if some protocol is not found, this for sure 
fixes my regression.
If that has a very bad performance impact: I doubt it, beside your really have 
tight loops always using not known protocols.

- Christoph Cullmann


On July 15, 2016, 8:35 a.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128458/
> ---
> 
> (Updated July 15, 2016, 8:35 a.m.)
> 
> 
> Review request for KDE Frameworks and Christoph Cullmann.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> KProtocolInfo: refill cache to find newly installed protocols
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfofactory.cpp 1329b6b98bb42be27f06aaacf29d51157290bbb4 
> 
> Diff: https://git.reviewboard.kde.org/r/128458/diff/
> 
> 
> Testing
> ---
> 
> $ git clone g...@github.com:shortstheory/staging-kioslave
> $ compile and install
> $ kioclient5 list stash:/
> 
> Now works, using a klauncher with this fix.
> 
> 
> Thanks,
> 
> David Faure
> 
>

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


Re: Review Request 125830: Read protocol info from plugin metadata

2016-07-15 Thread Christoph Cullmann


> On July 15, 2016, 8:35 a.m., David Faure wrote:
> > The problem with this change is that klauncher no longer recognizes freshly 
> > installed kioslaves.
> > 
> > Testcase:
> > $ git clone g...@github.com:shortstheory/staging-kioslave
> > $ compile and install
> > $ kioclient5 list stash:/
> > KIO::ProtoQueue::createSlave: couldn't create slave: "Unable to create 
> > io-slave:\nklauncher said: Unknown protocol 'stash'.\n"
> > 
> > Either we need to compare directory mtimes, or we need to refill the cache 
> > in case we hit an unknown protocol, hopefully this doesn't happen in tight 
> > loops.
> > I implemented the latter. https://git.reviewboard.kde.org/r/128458/

Hmm, actually, the old code did use the cache, too, once is was filled. Was 
that codepath never triggered?


- Christoph


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


On Oct. 29, 2015, 10:58 a.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 29, 2015, 10:58 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> 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 128398: Fix KDescendantsProxyModel::setSourceModel(...) to reset internal data

2016-07-15 Thread David Faure

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



I'd recommend making a new unittest with simply a QStandardItemModel as source 
model (and switching to another one).
Use text-based comparisons to check the contents of the proxy model. You can 
use kextracolumnsproxymodeltest.cpp as an example.

I don't really understand kdescendantsproxymodel_smoketest.cpp either, but it 
seems to mostly monitor for signals, not really for actual expected outcome of 
the proxymodel.

- David Faure


On July 8, 2016, 2:58 a.m., Friedrich W. H. Kossebau wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128398/
> ---
> 
> (Updated July 8, 2016, 2:58 a.m.)
> 
> 
> Review request for KDE Frameworks, Stephen  Kelly and Stephen Kelly.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> KDescendantsProxyModel currently does not reset its internal data when a 
> (new) source model is set.
> 
> Not sure the provided patch is the most correct one, but it works with the 
> current unit tests and for the use case where this bug was hit.
> I am still confused why 
> `KDescendantsProxyModelPrivate::synchronousMappingRefresh()` loops over 
> `while (!m_pendingParents.isEmpty())` on calling `processPendingParents();` 
> while `KDescendantsProxyModelPrivate::scheduleProcessPendingParents()` does 
> not.
> Especially when the `KDescendantsProxyModelPrivate::sourceModelReset()` 
> handler also only calls the latter.
> The sourceModelReset handler should be surely similar to what is done on 
> setting a new source model, so the patch for now copies that code. But from 
> what I understood by reading the code both of them should rather do a full 
> loop perhaps?
> 
> And `m_relayouting` should get a better name now, but no idea yet what would 
> be nice.
> 
> I have yet to grasp the proxymodeltest system to also write a matching unit 
> test, any proposal where I should start?
> 
> 
> Diffs
> -
> 
>   src/kdescendantsproxymodel.cpp 477cd96 
> 
> Diff: https://git.reviewboard.kde.org/r/128398/diff/
> 
> 
> Testing
> ---
> 
> Existing kitemmodels unit tests still pass.
> 
> 
> Thanks,
> 
> Friedrich W. H. Kossebau
> 
>

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


Re: Review Request 128406: KCollapsibleGroupBox: Stop animation if still running in destructor

2016-07-15 Thread Kai Uwe Broulik

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




autotests/kcollapsiblegroupbox_test.cpp (line 54)


connect(dlg, ::finished, dlg, ::deleteLater);



src/kcollapsiblegroupbox.cpp (line 67)


Too bad we can't use "d" as context object instead of "this", so it would 
auto-disconnect and this would not have happened.


- Kai Uwe Broulik


On Juli 9, 2016, 11:55 vorm., Ragnar Thomsen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128406/
> ---
> 
> (Updated Juli 9, 2016, 11:55 vorm.)
> 
> 
> Review request for KDE Frameworks, David Edmundson and Elvis Angelaccio.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> We are using KCollapsibleGroupBox in Ark and stumbled upon a segfault in an 
> autotest involving this widget (see backtrace 
> [here](https://paste.kde.org/pwcohd64z)). It looks like QTimeLine::stop() 
> gets called after KCollapsibleGroupBox is deleted. This causes 
> QTimeLine::stateChanged to get emitted which then calls 
> KCollapsibleGroupBox::updateChildrenVisibility() that causes the crash.
> 
> To see the crash, clone the newAddDialog branch of Ark and run the autotests.
> 
> This diff calls QTimeLine::stop() in the KCollapsibleGroupBox dtor if it is 
> running, before deleting the d pointer.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt 4be2eaf 
>   autotests/kcollapsiblegroupbox_test.h PRE-CREATION 
>   autotests/kcollapsiblegroupbox_test.cpp PRE-CREATION 
>   src/kcollapsiblegroupbox.cpp 0c3f866 
> 
> Diff: https://git.reviewboard.kde.org/r/128406/diff/
> 
> 
> Testing
> ---
> 
> The autotests in newAddDialog branch of Ark pass with this diff.
> 
> 
> Thanks,
> 
> Ragnar Thomsen
> 
>

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


Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,All,gcc - Build # 102 - Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=All,compiler=gcc/102/
Project: PLATFORM=Linux,Variation=All,compiler=gcc
Date of build: Fri, 15 Jul 2016 10:52:23 +
Build duration: 6 min 22 sec

CHANGE SET
Revision 2c6dacea3883aec7f9160cc8505e240202325b66 by hein: (Fix the infamous 
#039;dialogs show up on the Task Manager#039; bug once more.)
  change: edit autotests/CMakeLists.txt
  change: edit src/plasmaquick/dialog.cpp
  change: add autotests/dialogstatetest.h
  change: add autotests/dialogstatetest.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 14 test(s), Skipped: 0 test(s), Total: 
15 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 79/117 (68%)CLASSES 79/117 (68%)LINE 4887/11782 
(41%)CONDITIONAL 2611/8791 (30%)

By packages
  
autotests
FILES 28/28 (100%)CLASSES 28/28 (100%)LINE 968/1024 
(95%)CONDITIONAL 603/1194 (51%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 644/2096 
(31%)CONDITIONAL 292/1292 (23%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1682/3641 
(46%)CONDITIONAL 956/2728 (35%)
src.plasma.private
FILES 16/26 (62%)CLASSES 16/26 (62%)LINE 968/1802 
(54%)CONDITIONAL 441/1080 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 546/1799 
(30%)CONDITIONAL 297/1407 (21%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Jenkins-kde-ci: plasma-framework master stable-kf5-qt5 » Linux,NoX11,gcc - Build # 102 - Unstable!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-framework%20master%20stable-kf5-qt5/PLATFORM=Linux,Variation=NoX11,compiler=gcc/102/
Project: PLATFORM=Linux,Variation=NoX11,compiler=gcc
Date of build: Fri, 15 Jul 2016 10:52:23 +
Build duration: 8 min 23 sec

CHANGE SET
Revision 2c6dacea3883aec7f9160cc8505e240202325b66 by hein: (Fix the infamous 
#039;dialogs show up on the Task Manager#039; bug once more.)
  change: edit autotests/CMakeLists.txt
  change: edit src/plasmaquick/dialog.cpp
  change: add autotests/dialogstatetest.h
  change: add autotests/dialogstatetest.cpp


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 13 test(s), Skipped: 0 test(s), Total: 
14 test(s)Failed: TestSuite.plasma-dialogstatetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 8/8 (100%)FILES 76/113 (67%)CLASSES 76/113 (67%)LINE 4504/11311 
(40%)CONDITIONAL 2359/8437 (28%)

By packages
  
autotests
FILES 26/26 (100%)CLASSES 26/26 (100%)LINE 934/977 
(96%)CONDITIONAL 598/1162 (51%)
src.declarativeimports.core
FILES 10/18 (56%)CLASSES 10/18 (56%)LINE 559/1868 
(30%)CONDITIONAL 213/1142 (19%)
src.plasma
FILES 14/20 (70%)CLASSES 14/20 (70%)LINE 1680/3641 
(46%)CONDITIONAL 951/2728 (35%)
src.plasma.private
FILES 15/24 (63%)CLASSES 15/24 (63%)LINE 924/1729 
(53%)CONDITIONAL 421/1034 (41%)
src.plasma.scripting
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 37/181 (20%)CONDITIONAL 
14/106 (13%)
src.plasmaquick
FILES 6/12 (50%)CLASSES 6/12 (50%)LINE 328/1676 
(20%)CONDITIONAL 154/1281 (12%)
src.plasmaquick.private
FILES 1/3 (33%)CLASSES 1/3 (33%)LINE 31/113 (27%)CONDITIONAL 
6/22 (27%)
src.scriptengines.qml.plasmoid
FILES 2/7 (29%)CLASSES 2/7 (29%)LINE 11/1126 (1%)CONDITIONAL 
2/962 (0%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: The situation of KWallet, and what to do about it?

2016-07-15 Thread Kevin Krammer
On Wednesday, 2016-07-13, 11:41:14, Thomas Pfeiffer wrote:
> On 11.07.2016 22:29, Mark Gaiser wrote:

> > As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper
> > around platform specific keychains that provides a unified interface for
> > keychain functionality. It itself doesn't implement a keychain (or it does
> > on windows?).
> 
> Yes, QtKeychain wraps available keychains from the platform it runs on.
> However: "Since Windows does not provide a service for secure storage
> QtKeychain uses the Windows API function CryptProtectData to encrypt the
> password with the user’s logon credentials. The encrypted data is then
> persisted via QSettings."
> 
> On Linux we could use GNOME Keyring, but if we don't want that, we'd of
> course still have to implement our own backend. The advantage would be that
> it would be much easier to replace that at any point without having to
> adapt applications.

If QtKeychain, or any other multiplatform API, can use the SecretService API 
on Linux, then we could just require such an implementation to be available 
and let the distributors decide whether they want to fulfill that with gnome-
keyring (assuming it is-a SecretService daemon).

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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


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

2016-07-15 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/135/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 15 Jul 2016 09:28:43 +
Build duration: 11 min

CHANGE SET
Revision e45e48c8a9512319e55277a9f4ca25102c20e7e6 by David Faure: 
(KIO::CopyJob: port to qCDebug (with its own area, since this can be)
  change: edit src/core/copyjob.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/340 (76%)CLASSES 260/340 (76%)LINE 26815/50986 
(53%)CONDITIONAL 14995/37671 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7533/7852 
(96%)CONDITIONAL 4184/8156 (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 7726/14115 
(55%)CONDITIONAL 4202/9039 (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 2265/7562 
(30%)CONDITIONAL 912/4405 (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/3783 
(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 723/1155 (63%)CONDITIONAL 
384/753 (51%)
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 382/594 (64%)CONDITIONAL 
284/580 (49%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 239/268 (89%)CONDITIONAL 
333/414 (80%)
src.widgets
FILES 29/64 (45%)CLASSES 29/64 (45%)LINE 2674/10869 
(25%)CONDITIONAL 1334/6898 (19%)___
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 # 135 - Fixed!

2016-07-15 Thread no-reply

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kio%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/135/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Fri, 15 Jul 2016 09:28:43 +
Build duration: 11 min

CHANGE SET
Revision e45e48c8a9512319e55277a9f4ca25102c20e7e6 by David Faure: 
(KIO::CopyJob: port to qCDebug (with its own area, since this can be)
  change: edit src/core/copyjob.cpp


JUNIT RESULTS

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

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 21/21 (100%)FILES 260/340 (76%)CLASSES 260/340 (76%)LINE 26815/50986 
(53%)CONDITIONAL 14995/37671 (40%)

By packages
  
autotests
FILES 65/65 (100%)CLASSES 65/65 (100%)LINE 7533/7852 
(96%)CONDITIONAL 4184/8156 (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 7726/14115 
(55%)CONDITIONAL 4202/9039 (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 2265/7562 
(30%)CONDITIONAL 912/4405 (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/3783 
(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 723/1155 (63%)CONDITIONAL 
384/753 (51%)
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 382/594 (64%)CONDITIONAL 
284/580 (49%)
src.kpasswdserver.autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 283/286 (99%)CONDITIONAL 
146/256 (57%)
src.urifilters.fixhost
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 25/34 (74%)CONDITIONAL 
36/54 (67%)
src.urifilters.ikws
FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 240/725 (33%)CONDITIONAL 
146/542 (27%)
src.urifilters.localdomain
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 19/26 (73%)CONDITIONAL 
14/22 (64%)
src.urifilters.shorturi
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 239/268 (89%)CONDITIONAL 
333/414 (80%)
src.widgets
FILES 29/64 (45%)CLASSES 29/64 (45%)LINE 2674/10869 
(25%)CONDITIONAL 1334/6898 (19%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel


Re: Review Request 125830: Read protocol info from plugin metadata

2016-07-15 Thread David Faure

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



The problem with this change is that klauncher no longer recognizes freshly 
installed kioslaves.

Testcase:
$ git clone g...@github.com:shortstheory/staging-kioslave
$ compile and install
$ kioclient5 list stash:/
KIO::ProtoQueue::createSlave: couldn't create slave: "Unable to create 
io-slave:\nklauncher said: Unknown protocol 'stash'.\n"

Either we need to compare directory mtimes, or we need to refill the cache in 
case we hit an unknown protocol, hopefully this doesn't happen in tight loops.
I implemented the latter. https://git.reviewboard.kde.org/r/128458/

- David Faure


On Oct. 29, 2015, 10:58 a.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125830/
> ---
> 
> (Updated Oct. 29, 2015, 10:58 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Extends the protocol factory and co. to allow reading of protocol data from 
> embedded json.
> Allows to deploy io slaves without anything else than the io slave itself in 
> librarypath kf5/kio.
> 
> I changed to factory to ALWAYS fill its cache for any request, as now the 
> determination which protocols are around is more expensive than just some 
> directory traversal.
> 
> If this preview is ok, I will do that for all other shipped slaves and update 
> this request.
> 
> 
> Diffs
> -
> 
>   src/core/kprotocolinfo.cpp 8a02f7a 
>   src/core/kprotocolinfo_p.h c3dea6b 
>   src/core/kprotocolinfofactory.cpp 29ba8f4 
>   src/core/kprotocolinfofactory_p.h aa79fc5 
>   src/ioslaves/http/http.cpp 1727d41 
>   src/ioslaves/http/http.json PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/125830/diff/
> 
> 
> Testing
> ---
> 
> http slave still seems to be found and work.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

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


Review Request 128458: KProtocolInfo: refill cache to find newly installed protocols

2016-07-15 Thread David Faure

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

Review request for KDE Frameworks and Christoph Cullmann.


Repository: kio


Description
---

KProtocolInfo: refill cache to find newly installed protocols


Diffs
-

  src/core/kprotocolinfofactory.cpp 1329b6b98bb42be27f06aaacf29d51157290bbb4 

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


Testing
---

$ git clone g...@github.com:shortstheory/staging-kioslave
$ compile and install
$ kioclient5 list stash:/

Now works, using a klauncher with this fix.


Thanks,

David Faure

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


Re: The situation of KWallet, and what to do about it?

2016-07-15 Thread Martin Graesslin
On Friday, July 15, 2016 10:22:32 AM CEST Elvis Angelaccio wrote:
> 2016-07-14 1:11 GMT+02:00 Albert Astals Cid :
> > El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> > 
> > escriure:
> >> Hi,
> >> thanks for raising this topic!
> >> 
> >> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
> >> > Hi everyone,
> >> > I'm addressing both the Plasma team and kde-devel because this issue
> >> > affects Plasma as well as many applications, and Valentin as the
> >> > current
> >> > maintainer of KWallet as well as KSecretService, a potential
> >> > replacement
> >> > for it.
> >> > 
> >> > KWallet plays a central role in Plasma and many KDE applications as the
> >> > central password storage. However, it being very old and not having
> >> > been
> >> > actively developed for a long time, it has lots of problems, including:
> >> > 
> >> > - It has weak security, as it does not restrict applications accessing
> >> > it
> >> > by default, and even when it does, it does so simply based on
> >> > application
> >> > name which allows any malicious process to impersonate an allowed one
> >> > - The initial setup has huge usability problems, as it forces users to
> >> > make
> >> > a choice on a very advanced technical level (encryption methods, no
> >> > less!),
> >> > and the option it suggests (GPG) is a nightmare to set up for ordinary
> >> > users - It does support unlocking via PAM, but does not tell users what
> >> > they need to do to make that work, which results in most users having
> >> > to
> >> > enter the KWallet password at each system start, which many find very
> >> > annoying (we get lots of negative feedback for that)
> >> > - It works only with KDE Frameworks-based applications
> >> > - One cannot easily write a QML GUI for it, making it unsuitable for
> >> > mobile
> >> > 
> >> > Valentin has been working on KSecretService for quite a while, which is
> >> > based on the freedesktop Secrets API [1] that is also supported in
> >> > GNOME
> >> > Keyring, and would solve many (and ideally all) of the above problems.
> >> > However, Valentin told me he does not have the time to work on
> >> > KSecretService any more.
> >> > 
> >> > This means we have to find a solution to these problems. The options I
> >> > see
> >> > currently are
> >> > - Improve KWallet (unlikely to fix all the problems without massive
> >> > changes
> >> > in it, though)
> >> > - Find someone to finish and maintain KSecretService
> >> > - Build a wrapper around one of the other existing keyring technologies
> >> > - Each application (and each Plasma component that stores passwords)
> >> > implements its own encrypted password storage
> >> > 
> >> > 
> >> > - We make encrypted password storage optional and non-default (easiest
> >> > solution, but not exactly in line with KDE's vision)
> >> 
> >> I disagree on this point. Even if KWallet were free of usability
> >> issues, it would still provide a false sense of security. The user
> >> thinks that his/her passwords are safe, while in fact they are not.
> > 
> > How exactly the passwords are not safe?
> 
> The default behavior is to keep wallets "open" once they have been
> decrypted. If a wallet is open, any process can trivially retrieve
> clear-text passwords from it using the KWallet API. I wanted to back my
> claim with some code, so I created a small PoC in [1]. All an attacker has
> to do is to guess the name of a wallet (and only if the default
> 'kdewallet' name is not used!).
> 
> I could also mention that KWallet accepts an empty master password,
> which alone is already bad enough.

yeah, once the wallet is open it's as secure as a simple plain-text file on an 
encrypted home. If the home is not encrypted kwallet does offer an advantage 
over a simple plain-text file.

If we assume that "if it runs, it's trusted" then everything is fine as well. I 
can see ways how this can be secure with containerized apps and e.g. dedicated 
privs the user has to acknowledge to have it read wallets. E.g. that a 
containerized app has to ask for password for application foo. This could 
offer a user a good and informed decision on whether to grant it or not.

Cheers
Martin

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


Re: The situation of KWallet, and what to do about it?

2016-07-15 Thread Elvis Angelaccio
2016-07-14 1:11 GMT+02:00 Albert Astals Cid :
> El dijous, 7 de juliol de 2016, a les 18:43:57 CEST, Elvis Angelaccio va
> escriure:
>> Hi,
>> thanks for raising this topic!
>>
>> 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer :
>> > Hi everyone,
>> > I'm addressing both the Plasma team and kde-devel because this issue
>> > affects Plasma as well as many applications, and Valentin as the current
>> > maintainer of KWallet as well as KSecretService, a potential replacement
>> > for it.
>> >
>> > KWallet plays a central role in Plasma and many KDE applications as the
>> > central password storage. However, it being very old and not having been
>> > actively developed for a long time, it has lots of problems, including:
>> >
>> > - It has weak security, as it does not restrict applications accessing it
>> > by default, and even when it does, it does so simply based on application
>> > name which allows any malicious process to impersonate an allowed one
>> > - The initial setup has huge usability problems, as it forces users to
>> > make
>> > a choice on a very advanced technical level (encryption methods, no
>> > less!),
>> > and the option it suggests (GPG) is a nightmare to set up for ordinary
>> > users - It does support unlocking via PAM, but does not tell users what
>> > they need to do to make that work, which results in most users having to
>> > enter the KWallet password at each system start, which many find very
>> > annoying (we get lots of negative feedback for that)
>> > - It works only with KDE Frameworks-based applications
>> > - One cannot easily write a QML GUI for it, making it unsuitable for
>> > mobile
>> >
>> > Valentin has been working on KSecretService for quite a while, which is
>> > based on the freedesktop Secrets API [1] that is also supported in GNOME
>> > Keyring, and would solve many (and ideally all) of the above problems.
>> > However, Valentin told me he does not have the time to work on
>> > KSecretService any more.
>> >
>> > This means we have to find a solution to these problems. The options I see
>> > currently are
>> > - Improve KWallet (unlikely to fix all the problems without massive
>> > changes
>> > in it, though)
>> > - Find someone to finish and maintain KSecretService
>> > - Build a wrapper around one of the other existing keyring technologies
>> > - Each application (and each Plasma component that stores passwords)
>> > implements its own encrypted password storage
>> >
>> >
>> > - We make encrypted password storage optional and non-default (easiest
>> > solution, but not exactly in line with KDE's vision)
>>
>> I disagree on this point. Even if KWallet were free of usability
>> issues, it would still provide a false sense of security. The user
>> thinks that his/her passwords are safe, while in fact they are not.
>
> How exactly the passwords are not safe?

The default behavior is to keep wallets "open" once they have been decrypted.
If a wallet is open, any process can trivially retrieve clear-text
passwords from it using the KWallet API. I wanted to back my claim
with some code, so I created a small PoC in [1]. All an attacker has
to do is to guess the name of a wallet (and only if the default
'kdewallet' name is not used!).

I could also mention that KWallet accepts an empty master password,
which alone is already bad enough.

[1]: 
https://quickgit.kde.org/?p=scratch%2Felvisangelaccio%2Fkwalletleak-poc.git=tree

Cheers
Elvis

>
> Cheers,
>   Albert
>
>> If we don't have enough manpower to develop and mantain a proper
>> keychain in Plasma, we should tell our users. This way they can make
>> sure that, for example, the unsafely stored Wi-Fi passphrase is not
>> used for other accounts. This is already closer to our vision than the
>> current situation.
>>
>> My vote is: we either do it right, or we give up. If someone steps up
>> to fix this problem, great. Otherwise we should start to slowly port
>> away from KWallet.
>>
>> > So, what do we do?
>> >
>> > Cheers,
>> > Thomas
>>
>> Cheers,
>> Elvis
>>
>> > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secret
>> > s-api-0.1.html
>
>


Reminder: Please update kde-build-metadata when making changes to repository branch use

2016-07-15 Thread Ben Cooksley
Hi all,

Currently there are a series of build breakages on build.kde.org due
to out of date build metadata.
Just a reminder: before beginning ports of projects from Qt 4 to KF5,
you need to:

a) Ensure there is a Qt 4 branch (last stable release will do)
b) Update kde-build-metadata appropriately

This involves updating the "logical-module-structure" file to contain
the correct branch information, and the appropriate dependency-data-*
files to cover the dependencies for the newly ported project as
needed.

The names "kf5-qt5", "stable-kf5-qt5" refer to the latest / stable
development branches for KF5, while "latest-qt4" and "stable-qt4" are
the Qt 4 counterparts to those two for the logical-module-structure
file.

NOTE: If you are porting a library, then under no circumstances should
you leave the "latest-qt4" and "stable-qt4" branch groups marked as
empty ("") as this will break the Qt 4 builds of any application which
depends on the library. This is why it is essential a branch is
created if one does not already exist (the CI system cannot reference
tags).

Thanks,
Ben


Reminder: Please update kde-build-metadata when making changes to repository branch use

2016-07-15 Thread Ben Cooksley
Hi all,

Currently there are a series of build breakages on build.kde.org due
to out of date build metadata.
Just a reminder: before beginning ports of projects from Qt 4 to KF5,
you need to:

a) Ensure there is a Qt 4 branch (last stable release will do)
b) Update kde-build-metadata appropriately

This involves updating the "logical-module-structure" file to contain
the correct branch information, and the appropriate dependency-data-*
files to cover the dependencies for the newly ported project as
needed.

The names "kf5-qt5", "stable-kf5-qt5" refer to the latest / stable
development branches for KF5, while "latest-qt4" and "stable-qt4" are
the Qt 4 counterparts to those two for the logical-module-structure
file.

NOTE: If you are porting a library, then under no circumstances should
you leave the "latest-qt4" and "stable-qt4" branch groups marked as
empty ("") as this will break the Qt 4 builds of any application which
depends on the library. This is why it is essential a branch is
created if one does not already exist (the CI system cannot reference
tags).

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


Reminder: Please update kde-build-metadata when making changes to repository branch use

2016-07-15 Thread Ben Cooksley
Hi all,

Currently there are a series of build breakages on build.kde.org due
to out of date build metadata.
Just a reminder: before beginning ports of projects from Qt 4 to KF5,
you need to:

a) Ensure there is a Qt 4 branch (last stable release will do)
b) Update kde-build-metadata appropriately

This involves updating the "logical-module-structure" file to contain
the correct branch information, and the appropriate dependency-data-*
files to cover the dependencies for the newly ported project as
needed.

The names "kf5-qt5", "stable-kf5-qt5" refer to the latest / stable
development branches for KF5, while "latest-qt4" and "stable-qt4" are
the Qt 4 counterparts to those two for the logical-module-structure
file.

NOTE: If you are porting a library, then under no circumstances should
you leave the "latest-qt4" and "stable-qt4" branch groups marked as
empty ("") as this will break the Qt 4 builds of any application which
depends on the library. This is why it is essential a branch is
created if one does not already exist (the CI system cannot reference
tags).

Thanks,
Ben


Re: Review Request 128056: Provide a style-selection menu as in KDenlive (WIP)

2016-07-15 Thread René J . V . Bertin


> On July 14, 2016, 1:14 p.m., Hannah von Reth wrote:
> > sublime/kwidgetstyleselector.cpp, line 43
> > 
> >
> > Dont fall back to Windows.
> > Windows is the win3.11 like style.
> > I guess the current one is Windows Vista?
> 
> René J.V. Bertin wrote:
> I have no idea and no way to check (except through trying to understand 
> the MSWin-specific Qt sources). It has to be an appropriate style that's 
> always available because part of Qt.
> 
> Hannah von Reth wrote:
> From the Windows qpa.
> ```
> static inline QStringList styleNames()
> {
> QStringList result;
> if (QSysInfo::WindowsVersion >= QSysInfo::WV_VISTA)
> result.append(QStringLiteral("WindowsVista"));
> if (QSysInfo::WindowsVersion >= QSysInfo::WV_XP)
> result.append(QStringLiteral("WindowsXP"));
> result.append(QStringLiteral("Windows"));
> return result;
> }
> ```

Annoying that they didn't consider making the style adaptive to the OS version 
it is being used on. Apparently we cannot simply evoke a single style as 
fallback, but I'll have to copy that snippet. Thanks for pointing me to it.
Do you know how those specific styles turn out if the user configured his 
desktop to use the "classic" look, something that was possible and that I did 
up to and including Win7?


- René J.V.


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


On June 14, 2016, 7:20 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128056/
> ---
> 
> (Updated June 14, 2016, 7:20 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> ---
> 
> I filed a bug report recently that raises an issue about the QTabBar widget 
> for the tabbed document interface  
> (https://bugs.kde.org/show_bug.cgi?id=363473). On OS X, that widget is 
> rendered like the native tab bar widget that should only be used in dialogs 
> and comparable views where the number of tabs is preferably fixed and 
> limited. There are also other rendering issues which probably stem from 
> presumptions KDevelop makes about the tab layout in the extensions it 
> implements.
> Qt does provide a `documentMode` which changes the look to suit use for 
> document tabs better, but this mode doesn't work well with KDevelop's 
> extensions either.
> 
> For lack of a better solution or workaround I would thus like to explore the 
> idea to provide a widget style picker, like KDenlive does (presumably not 
> without reason either). The underlying idea is that it allows users to find 
> an style that works better for them if they feel a reason to do so. This 
> option works regardless of whether a platform theme plugin is available.
> 
> For now the patch is a proof-of-concept and work in progress. It is still 
> lacking a mechanism to make the style choice persistent across restarts; I 
> think I'll need a hand in determining how to do that correctly (it should be 
> a global setting, not a session-specific setting I think).
> 
> 
> Diffs
> -
> 
>   sublime/CMakeLists.txt 2144087 
>   sublime/kwidgetstyleselector.h PRE-CREATION 
>   sublime/kwidgetstyleselector.cpp PRE-CREATION 
>   sublime/mainwindow_p.cpp 74ef494 
> 
> Diff: https://git.reviewboard.kde.org/r/128056/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 and Linux, both with fw. (5.20.0 and) 5.22.0 and Qt 5.6.0
> 
> 
> File Attachments
> 
> 
> diff for kdevelopui.rc
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/cb07a061-aef5-42f5-bc83-68ca7ce2ce3b__patch-kdevplatform-add-style-menu-uirc.diff
> This screenshot shows where the menu item appears with the kdevelopui.rc 
> patch in another attachment. This KDevelop instance was running with my 
> platform theme plugin and my OS X palette and config for the QtCurve style. 
> Only the UI fonts change when the p
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/543bffc8-26fd-44f8-8bd8-372a24c9b01f__Screen_Shot_2016-05-30_at_15.47.14.png
> 
> 
> 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 128056: Provide a style-selection menu as in KDenlive (WIP)

2016-07-15 Thread Hannah von Reth


> On July 14, 2016, 11:14 a.m., Hannah von Reth wrote:
> > sublime/kwidgetstyleselector.cpp, line 43
> > 
> >
> > Dont fall back to Windows.
> > Windows is the win3.11 like style.
> > I guess the current one is Windows Vista?
> 
> René J.V. Bertin wrote:
> I have no idea and no way to check (except through trying to understand 
> the MSWin-specific Qt sources). It has to be an appropriate style that's 
> always available because part of Qt.

>From the Windows qpa.
```
static inline QStringList styleNames()
{
QStringList result;
if (QSysInfo::WindowsVersion >= QSysInfo::WV_VISTA)
result.append(QStringLiteral("WindowsVista"));
if (QSysInfo::WindowsVersion >= QSysInfo::WV_XP)
result.append(QStringLiteral("WindowsXP"));
result.append(QStringLiteral("Windows"));
return result;
}
```


- Hannah


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


On June 14, 2016, 5:20 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128056/
> ---
> 
> (Updated June 14, 2016, 5:20 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Frameworks and KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> ---
> 
> I filed a bug report recently that raises an issue about the QTabBar widget 
> for the tabbed document interface  
> (https://bugs.kde.org/show_bug.cgi?id=363473). On OS X, that widget is 
> rendered like the native tab bar widget that should only be used in dialogs 
> and comparable views where the number of tabs is preferably fixed and 
> limited. There are also other rendering issues which probably stem from 
> presumptions KDevelop makes about the tab layout in the extensions it 
> implements.
> Qt does provide a `documentMode` which changes the look to suit use for 
> document tabs better, but this mode doesn't work well with KDevelop's 
> extensions either.
> 
> For lack of a better solution or workaround I would thus like to explore the 
> idea to provide a widget style picker, like KDenlive does (presumably not 
> without reason either). The underlying idea is that it allows users to find 
> an style that works better for them if they feel a reason to do so. This 
> option works regardless of whether a platform theme plugin is available.
> 
> For now the patch is a proof-of-concept and work in progress. It is still 
> lacking a mechanism to make the style choice persistent across restarts; I 
> think I'll need a hand in determining how to do that correctly (it should be 
> a global setting, not a session-specific setting I think).
> 
> 
> Diffs
> -
> 
>   sublime/CMakeLists.txt 2144087 
>   sublime/kwidgetstyleselector.h PRE-CREATION 
>   sublime/kwidgetstyleselector.cpp PRE-CREATION 
>   sublime/mainwindow_p.cpp 74ef494 
> 
> Diff: https://git.reviewboard.kde.org/r/128056/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9.5 and Linux, both with fw. (5.20.0 and) 5.22.0 and Qt 5.6.0
> 
> 
> File Attachments
> 
> 
> diff for kdevelopui.rc
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/cb07a061-aef5-42f5-bc83-68ca7ce2ce3b__patch-kdevplatform-add-style-menu-uirc.diff
> This screenshot shows where the menu item appears with the kdevelopui.rc 
> patch in another attachment. This KDevelop instance was running with my 
> platform theme plugin and my OS X palette and config for the QtCurve style. 
> Only the UI fonts change when the p
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/05/30/543bffc8-26fd-44f8-8bd8-372a24c9b01f__Screen_Shot_2016-05-30_at_15.47.14.png
> 
> 
> 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: kolourpaint now KF5 based

2016-07-15 Thread Martin Koller
On Thursday 14 July 2016 19:26:42 Ragnar Thomsen wrote:
> On Thu, Jul 14, 2016 at 8:12 AM, Martin Koller  wrote:
> 
> > On Wednesday 13 July 2016 20:51:24 Christoph Feck wrote:
> > > On Wednesday 13 July 2016 20:12:46 Martin Koller wrote:
> > > > just wanted to let you know that I have now completed the
> > > > kolourpaint port to KF5 and this is now in its master branch. I
> > > > have also updated kde-build-metadata Hope I did all correct.
> > >
> > > The about dialog says it is version 5.25.0 (=frameworks version). I
> > > guess this is not intended.
> >
> > Hmm ... it was like that since 2008
> > Changed that now.
> >
> 
> I propose that you instead follow KDE Applications version. This way you
> can get automatic update of version number. See e.g. this commit:
> https://quickgit.kde.org/?p=gwenview.git=commit=a992a8cdbe41db2c8869c79d42ff9cd09dfaf66b

Thanks for the hint.
Done that now like this.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at