date:20160707


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/241/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 21:47:36 +
Build duration: 22 min

CHANGE SET
Revision f631964f2d119493968a23a38dd053f2c57a8197 by hein: (Don#039;t 
recurse.)
  change: edit libtaskmanager/tasksmodel.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: 
TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 11/11 (100%)FILES 50/67 (75%)CLASSES 50/67 (75%)LINE 1973/5299 
(37%)CONDITIONAL 1382/5446 (25%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 
37/92 (40%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3024 (5%)CONDITIONAL 
88/3173 (3%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.7 stable-kf5-qt5 » Linux,gcc - Build # 29 - Still Failing!


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.7%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/29/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 21:47:06 +
Build duration: 42 sec

CHANGE SET
Revision f631964f2d119493968a23a38dd053f2c57a8197 by hein: (Don#039;t 
recurse.)
  change: edit libtaskmanager/tasksmodel.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 240 - Still Unstable!


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/240/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 20:36:29 +
Build duration: 12 min

CHANGE SET
Revision 313aede08506b87358e0d770911c562d3ac6f234 by hein: (Return 
LegacyWinIdList for groups in final proxy sort order.)
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.h


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: 
TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 11/11 (100%)FILES 50/67 (75%)CLASSES 50/67 (75%)LINE 1973/5300 
(37%)CONDITIONAL 1382/5448 (25%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 
37/92 (40%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3025 (5%)CONDITIONAL 
88/3175 (3%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

2016-07-07 Thread Marco Martin

On Thursday 07 July 2016 11:29:15 Ivan Čukić wrote:
> I also find Cantata a strange choice (even though I do use it :) ).
> Was Clementine-qt5 considered?

i liked the proposal as i consider it as the only qt based music player that 
has a kida good UI, but yeah, it does have problems underneath

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.7 stable-kf5-qt5 » Linux,gcc - Build # 28 - Still Failing!


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.7%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/28/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 20:35:19 +
Build duration: 42 sec

CHANGE SET
Revision 313aede08506b87358e0d770911c562d3ac6f234 by hein: (Return 
LegacyWinIdList for groups in final proxy sort order.)
  change: edit libtaskmanager/tasksmodel.cpp
  change: edit libtaskmanager/tasksmodel.h
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-07-07 Thread valentin rusu

Hello,

Thanks for including this address in this thead. I'm curently on the go and 
I'll try to quicly reply here.

I confirm that I do not curently have lots of time and also there are all these 
KWallet problems that are built-in and require rewriting. You did a great job 
enumerating them here. Also, these last years we saw lots of others options 
out-there, questioning the very idea of implementing something like 
ksecretservice. I won't enumerate the options here but those listed by Kevin 
are only a subset of them. So, yeah, we should ask ourselves if we need a 
special password handling utility, and force users of some web-compatible 
solution out-there to adopt ours in addition to their preferred one.


On July 7, 2016 8:50:08 PM GMT+03:00, Kevin Ottens  wrote:
>Hello,
>
>On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:
>> 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)
>> 
>> So, what do we do?
>
>There's two sides to that problem in fact, use from applications and
>the 
>service provided by our workspace.
>
>I think that for applications the answer is neither KSecretService nor 
>KWallet, etc. For the goal of making it easier for our applications to
>be 
>shipped on more platforms, what we want in fact is to port them away
>from 
>anything platform specific to something like QtKeyChain:
>https://inqlude.org/libraries/qtkeychain.html
>
>This way, the actual storage becomes a workspace decision. That could
>keep 
>being KWallet if improved, or KSecretService, or a simple D-Bus service
>
>wrapping libsecret... For sure it would at least simplify things on the
>
>KWallet/KSecretService side, they wouldn't need to be frameworks
>anymore 
>(QtKeyChain or equivalent would play that role) just to expose a D-Bus
>API 
>(likely the Secret Service one in the end).
>
>>
>https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets->
>api-0.1.html
>
>0.1 being outdated, you probably want to link that one:
>https://standards.freedesktop.org/secret-service/
>
>Hope that somewhat made sense and helps.
>
>Regards.
>-- 
>Kévin Ottens, http://ervin.ipsquad.net
>
>KDAB - proud supporter of KDE, http://www.kdab.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 239 - Still Unstable!


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/239/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 20:12:04 +
Build duration: 9 min 17 sec

CHANGE SET
Revision e2b07027de7cb15171a35aa59e8b90397b5c47b7 by hein: (Avoid 
side-channeling through shared static source models.)
  change: edit libtaskmanager/tasksmodel.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: 
TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 11/11 (100%)FILES 50/67 (75%)CLASSES 50/67 (75%)LINE 1973/5292 
(37%)CONDITIONAL 1382/5438 (25%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 
37/92 (40%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3017 (5%)CONDITIONAL 
88/3165 (3%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.7 stable-kf5-qt5 » Linux,gcc - Build # 27 - Still Failing!


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.7%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/27/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 20:11:24 +
Build duration: 54 sec

CHANGE SET
Revision e2b07027de7cb15171a35aa59e8b90397b5c47b7 by hein: (Avoid 
side-channeling through shared static source models.)
  change: edit libtaskmanager/tasksmodel.cpp
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-07-07 Thread Kevin Ottens

Hello,

On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:
> 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)
> 
> So, what do we do?

There's two sides to that problem in fact, use from applications and the 
service provided by our workspace.

I think that for applications the answer is neither KSecretService nor 
KWallet, etc. For the goal of making it easier for our applications to be 
shipped on more platforms, what we want in fact is to port them away from 
anything platform specific to something like QtKeyChain:
https://inqlude.org/libraries/qtkeychain.html

This way, the actual storage becomes a workspace decision. That could keep 
being KWallet if improved, or KSecretService, or a simple D-Bus service 
wrapping libsecret... For sure it would at least simplify things on the 
KWallet/KSecretService side, they wouldn't need to be frameworks anymore 
(QtKeyChain or equivalent would play that role) just to expose a D-Bus API 
(likely the Secret Service one in the end).

> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> 
> api-0.1.html

0.1 being outdated, you probably want to link that one:
https://standards.freedesktop.org/secret-service/

Hope that somewhat made sense and helps.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 128392: [kickoff] kickoff should use icons from icon theme

2016-07-07 Thread Andrey Bondrov


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

Review request for Plasma and Eike Hein.


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


Repository: plasma-desktop


Description
---

Likely kickoff should use icons from icon theme, not from plasma theme. 

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


Diffs
-

  applets/kickoff/package/contents/ui/KickoffButton.qml 6b3a2b7 

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


Testing
---

1. Added kickoff applet to desktop
2. Swicthed from Breeze LAF to Oxygen
3. Rebooted
4. Kickoff got mixed Breeze and Oxygen icons (see screenshot in #365204)
5. Applied the patch
6. Rebooted
7. All Kickoff icons are properly set to Oxygen


Thanks,

Andrey Bondrov

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace master kf5-qt5 » Linux,gcc - Build # 238 - Still Unstable!


GENERAL INFO

BUILD UNSTABLE
Build URL: 
https://build.kde.org/job/plasma-workspace%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/238/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 16:32:35 +
Build duration: 12 min

CHANGE SET
Revision 6adba6315275f4ef6ebf8879c851830c268f7a51 by Marco Martin: (make the 
systray work with scripting shell again)
  change: edit applets/systemtray/container/systemtraycontainer.h
  change: edit applets/systemtray/container/systemtraycontainer.cpp


JUNIT RESULTS

Name: (root) Failed: 2 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 
10 test(s)Failed: TestSuite.org.kde.plasma.analogclock-testFailed: 
TestSuite.org.kde.plasma.kickoff-test

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 11/11 (100%)FILES 50/67 (75%)CLASSES 50/67 (75%)LINE 1973/5286 
(37%)CONDITIONAL 1382/5432 (25%)

By packages
  
drkonqi.parser
FILES 6/10 (60%)CLASSES 6/10 (60%)LINE 303/423 (72%)CONDITIONAL 
478/616 (78%)
drkonqi.tests.backtraceparsertest
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 74/74 (100%)CONDITIONAL 
33/50 (66%)
kioslave.desktop
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 113/168 (67%)CONDITIONAL 
37/92 (40%)
kioslave.desktop.tests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 66/66 (100%)CONDITIONAL 
26/50 (52%)
klipper
FILES 12/13 (92%)CLASSES 12/13 (92%)LINE 256/384 
(67%)CONDITIONAL 109/210 (52%)
klipper.autotests
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 630/693 (91%)CONDITIONAL 
377/820 (46%)
libtaskmanager
FILES 5/16 (31%)CLASSES 5/16 (31%)LINE 139/3011 (5%)CONDITIONAL 
88/3159 (3%)
libtaskmanager.autotests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 150/150 
(100%)CONDITIONAL 85/170 (50%)
runners.bookmarks
FILES 8/8 (100%)CLASSES 8/8 (100%)LINE 89/159 (56%)CONDITIONAL 
34/96 (35%)
runners.bookmarks.browsers
FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 88/93 (95%)CONDITIONAL 
84/107 (79%)
runners.bookmarks.tests
FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 65/65 (100%)CONDITIONAL 
31/62 (50%)___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-07-07 Thread Elvis Angelaccio

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.
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/secrets-api-0.1.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-workspace Plasma-5.7 stable-kf5-qt5 » Linux,gcc - Build # 26 - Still Failing!


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-workspace%20Plasma-5.7%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/26/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 16:31:50 +
Build duration: 51 sec

CHANGE SET
Revision 6adba6315275f4ef6ebf8879c851830c268f7a51 by Marco Martin: (make the 
systray work with scripting shell again)
  change: edit applets/systemtray/container/systemtraycontainer.cpp
  change: edit applets/systemtray/container/systemtraycontainer.h
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2110: Create a Colors page in the Gallery

2016-07-07 Thread colomar (Thomas Pfeiffer)

colomar added a comment.


  Ok. Not spectacularly pretty, of course, but it does the job.
  Good to go from my side!

REPOSITORY
  rKIRIGAMI Kirigami

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: colomar, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2110: Create a Colors page in the Gallery

2016-07-07 Thread apol (Aleix Pol Gonzalez)

apol added a comment.


  Screenshot: http://i.imgur.com/7agXRFB.png

REPOSITORY
  rKIRIGAMI Kirigami

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: colomar, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

2016-07-07 Thread R.Harish Navnit

On Thu, Jul 7, 2016 at 5:04 PM, Sebastian Kügler  wrote:
> On donderdag 7 juli 2016 11:29:15 CEST Ivan Čukić wrote:
>> As for the browser, while I do agree with Martin regarding the slow Qt
>> security updates, I do not think we should actively discourage their
>> use.
>
> Agree. Let's keep the recommendations positive.
That's generally good, but from a user's POV, I'm glad Martin
highlighted those issues.
I think it would be nice if we could give a positive spin to our
recommendation whilst still highlighting potential hazards.

Thanks,
Harish
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2112: Add a shortcut for Meta+P

graesslin accepted this revision.
graesslin added a comment.


  > Not sure why ... ?
  
  I think the KCM doesn't support that. Alternatives are new in 5.x and I doubt 
anybody extended the KCM for it

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/365147

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, davidedmundson, graesslin
Cc: plasma-devel, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2112: Add a shortcut for Meta+P

2016-07-07 Thread Sebastian Kügler

sebas added a comment.


  Forgot to add: the alternate doesn't show up in my Global Shortcuts / KDE 
Daemon list of shortcuts this way. Not sure why ... ?

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/365147

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, graesslin, #plasma, davidedmundson
Cc: plasma-devel, jensreuterberg, abetts, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2112: Add a shortcut for Meta+P

2016-07-07 Thread davidedmundson (David Edmundson)

davidedmundson accepted this revision.
davidedmundson added a reviewer: davidedmundson.
This revision is now accepted and ready to land.

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/365147

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, graesslin, #plasma, davidedmundson
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 4 lines] D2112: Add a shortcut for Meta+P

2016-07-07 Thread Sebastian Kügler

sebas created this revision.
sebas added reviewers: Plasma, graesslin.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Also relevant: http://mjg59.livejournal.com/121851.html
  
  BUG:365147

REPOSITORY
  rKSCREEN KScreen

BRANCH
  sebas/365147

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

AFFECTED FILES
  kcm/kcm_kscreen.desktop.cmake
  kded/daemon.cpp

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: sebas, #plasma, graesslin
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D2111: User interface for adding launchers as global shortcuts

2016-07-07 Thread mart (Marco Martin)

mart added a reviewer: graesslin.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart, graesslin
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 183 lines] D2111: User interface for adding launchers as global shortcuts

2016-07-07 Thread mart (Marco Martin)

mart created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  add a menu to pick applications from the start menu structure to
  add launchers to be usable as shortcuts.
  If an application has jumplist options they will be available as actions.
  
  still need a dbus action to tell the daemon to reload
  and probably launchers vs runtime actions will have to be
  separed in the ui as well, that may influence the daemon api

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

BRANCH
  mart/kserviceaction

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

AFFECTED FILES
  kcms/keys/CMakeLists.txt
  kcms/keys/kglobalshortcutseditor.cpp
  kcms/keys/select_application.ui

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: mart
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Customizing KDE

2016-07-07 Thread Kai Uwe Broulik


> > 6. Remove "New Session" feature (from all the places: menu, screen
> > locker, etc)
>
> also this may be supported by kiosk?

Yes, there's a action/switch_user and action/start_new_session kiosk 
restriction one can set.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Customizing KDE

2016-07-07 Thread Marco Martin

On Wednesday 29 June 2016 15:19:40 Marek Marczykowski-Górecki wrote:
> 4. Set default menu style to "Application Menu"
> 5. Remove section "Places" from "Computer" tab, or even remove
> "Computer" tab completely in Application Launcher
> 6. Remove "New Session" feature (from all the places: menu, screen
> locker, etc)
> 7. Place some applications as "Favorites" by default
> 8. Remove "device notifier" and some other applets

for the panel creation, you can use as inspiration this (that i stolen and 
adapted from netrunner)
https://paste.kde.org/p84qkssu7

and yes, the distributions list is a good place to ask

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Customizing KDE

2016-07-07 Thread Marco Martin

On Wednesday 29 June 2016 15:19:40 Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I'd like to setup some defaults for all users (at package level),
> including some customizations:
> 
> 1. Setup default theme
> 2. Setup default wallpaper
> 3. Set custom menu icon (application launcher?)
> 4. Set default menu style to "Application Menu"
> 5. Remove section "Places" from "Computer" tab, or even remove
> "Computer" tab completely in Application Launcher

this  may be something for kiosk?

> 6. Remove "New Session" feature (from all the places: menu, screen
> locker, etc)

also this may be supported by kiosk?

> 7. Place some applications as "Favorites" by default
> 8. Remove "device notifier" and some other applets

Hi,
I think all of this can be done by providing a custom "look and feel" package,
with a layout.js script. Even if the details of it are not complete yet, 
should already be possible to set the theme, plasma and widgets, wallpaper, 
and menu icon

Like
https://quickgit.kde.org/?p=plasma-workspace.git=tree=39b9af963eeb5ecea0a00c23280bef20aeeec840=312f1e250202f705b8a216b86a4c320ec33b16a9=lookandfeel

(discarding all the subdirectories containing qml files)

> 
> Any idea how to do (any of) that? Preferably without patching existing
> programs (but if no other option - this will also do).
> 
> I've tried using scripts:
> https://userbase.kde.org/KDE_System_Administration/PlasmaTwoDesktopScripting
> but failed. For example I see no way to remove
> entries/applets/plasmoids. Also debugging is quite painful, because I

on first startup when the layout.js gets executed you don't have to remove 
plasmoids: you have an empty setup in which you only add what you need.

> have no idea where to looks for logs (like what entry was loaded, what
> was ignored at all etc), I can only guess looking at the result. And
> frequently wondering why my script wasn't launched at all...

in order to do tests, is convenient to use the interactive scripting console 
by launching

qdbus org.kde.plasmashell /PlasmaShell showInteractiveConsole

even tough it will be a slightly different situation as you have a complete 
setup already.

(in order to make this sort of things easier i'm making a tool that will 
create a look and feel package based on the current plasma layout, but will be 
available from 5.8)

-- 
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins-kde-ci: plasma-desktop Plasma-5.7 stable-kf5-qt5 » Linux,gcc - Build # 22 - Still Failing!


GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/plasma-desktop%20Plasma-5.7%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/22/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Thu, 07 Jul 2016 11:54:10 +
Build duration: 5 min 23 sec

CHANGE SET
Revision e30a37a514026fc52c0b8ff7aa479d5b955ebf3e by kde: ([Task Manager] 
Reject wheel event if switching windows by mouse wheel is)
  change: edit applets/taskmanager/package/contents/ui/Task.qml
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Closed] D2106: [Task Manager] Reject wheel event if switching windows by mouse wheel is disabled

2016-07-07 Thread broulik (Kai Uwe Broulik)

This revision was automatically updated to reflect the committed changes.
Closed by commit rPLASMADESKTOPe30a37a51402: [Task Manager] Reject wheel event 
if switching windows by mouse wheel is… (authored by broulik).

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2106?vs=4996=5004

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

AFFECTED FILES
  applets/taskmanager/package/contents/ui/Task.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: broulik, hein, #plasma
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-07-07 Thread Luca Beltrame

In data giovedì 7 luglio 2016 13:17:12 CEST, Martin Graesslin ha scritto:

Hello Martin,

> Adding some more:
[...]

I think we should not forget that there's kwallet (the framework) and 
kwallet{manager} (the frontend).

I also think that Kwallet is very much ingrained in a lot of KDE software, so 
that rules out (IMO) the option for a drastic change there. I do believe, as 
Thomas stated, that we *need* to have a wallet available in the workspace. 

That said, some review would be in order in particular with regards to the 
encryption used (see the recent breakage that occurred "just" fixing a compiler 
warning).

(FYI, I'm using Kwallet with a GPG-based YubiKey, but I agree this is *not* an 
acceptable, or easy enough, solution for our userbase),

> - if one doesn't unlock the wallet fast enough applications start asking for
> the password. So getting a coffee while desktop starts results in thousands

This is no longer the case, IIRC dfaure has raised the timeout to 45 minutes.

> For Plasma I would like to see unlocking the wallet integrated into the
> desktop shell in some way. That would fix problems like the incorrect

That would mean probably having Plasma providing a sort of "frontend" to the 
framework? To be honest, I have no idea if there's any separation of GUI and 
wallet layers in the kwallet-framework code.


-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

2016-07-07 Thread Sebastian Kügler

On donderdag 7 juli 2016 11:29:15 CEST Ivan Čukić wrote:
> As for the browser, while I do agree with Martin regarding the slow Qt
> security updates, I do not think we should actively discourage their
> use.

Agree. Let's keep the recommendations positive.
-- 
sebas

http://www.kde.org | http://vizZzion.org
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Commented On] D2110: Create a Colors page in the Gallery

2016-07-07 Thread colomar (Thomas Pfeiffer)

colomar added a comment.


  Screenshot, please?

REPOSITORY
  rKIRIGAMI Kirigami

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: colomar, plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 68 lines] D2110: Create a Colors page in the Gallery

2016-07-07 Thread apol (Aleix Pol Gonzalez)

apol created this revision.
apol added reviewers: Kirigami, mart.
Restricted Application added a project: Kirigami.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Will list all available colors and show them in a rectangle, so that
  the user can see what we're talking about.

REPOSITORY
  rKIRIGAMI Kirigami

BRANCH
  master

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

AFFECTED FILES
  examples/android/resources.qrc
  examples/gallery/contents/ui/MainPage.qml
  examples/gallery/contents/ui/gallery/ColorsGallery.qml

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: apol, #kirigami, mart
Cc: plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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

2016-07-07 Thread Martin Graesslin

On Thursday, July 7, 2016 12:36:26 PM CEST Thomas Pfeiffer wrote:
> 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

Adding some more:
- kwallet dialog allows keyloggers on X11 (in defence of KWallet, I only know 
of pinentry which handles this properly at the cost of severely degraded user 
experience)
- kwallet does not protect against ptrace (I didn't add the protection, due to 
the keylogger rendering it point less)
- kwallet dialog windows sometimes are placed at the bottom of the stack due 
to focus stealing prevention (this happens for example with akonadi/other 
daemons)
- kwallet shows total giberish like "kded requested to open the wallet"
- if one doesn't unlock the wallet fast enough applications start asking for 
the password. So getting a coffee while desktop starts results in thousands of 
password windows.

> 
> 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

how much work is still needed?

> - 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)

For Plasma I would like to see unlocking the wallet integrated into the 
desktop shell in some way. That would fix problems like the incorrect stacking 
order and we can easily protect against keyloggers, etc. Especially on Wayland 
I would like KWin having more control of entering passwords (KWin should know 
that a password is entered and make it impossible to steal focus then).

Cheers
Martin

Now going to use the secure pinentry, by clicking send

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?


On 05.07.2016 13:23, Martin Graesslin wrote:

The problems as I see it, is that I don't trust Qt to update when there are
security issues. That's based on how long we had to wait for Qt 5.6.1. I just
tried to figure out which issues in QtWebEngine were fixed in 5.6.1, but that's
not possible. The changelog ( https://code.qt.io/cgit/qt/qtwebengine.git/tree/
dist/changes-5.6.1?h=5.6.1 ) does not list them. It only says it's up to ...
2704.63. So are the issues mentioned in https://
googlechromereleases.blogspot.de/2016/06/stable-channel-update_16.html fixed or
not? And what about those in https://googlechromereleases.blogspot.de/2016/06/
stable-channel-update.html ?

That's the problem I see with Qt based browsers - I don't think the Qt team is
up to the task of doing timely security fixes for their software. Also caused
by Qt's release model of releasing all together. QtWebEngine would need
updates whenever chromium updates.

I'm writing that with my security hat on and not with my I would like to see
Qt applications hat.



This is a very valid point, but wouldn't it be in our as well as Qt's best 
interest
to figure out a solution for it together with the Qt community, instead of just 
saying

"Anything using QtWebEngine is a security risk and therefore should not be 
used?"

I suppose we all want our favorite toolkit to be usable to securely browse the 
web,
don't we? I'd be very surprised if the Qt Company simply did not care about the
security of QtWebEngine, so if we approach them with our concerns, they should
be responsive to them.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Accepted] D2106: [Task Manager] Reject wheel event if switching windows by mouse wheel is disabled

2016-07-07 Thread hein (Eike Hein)

hein accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  rPLASMADESKTOP Plasma Desktop

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: broulik, hein, #plasma
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Customizing KDE

2016-07-07 Thread Martin Graesslin

On Wednesday, June 29, 2016 3:19:40 PM CEST Marek Marczykowski-Górecki wrote:
> Hi,
> 
> I'd like to setup some defaults for all users (at package level),
> including some customizations:
> 
> 1. Setup default theme
> 2. Setup default wallpaper
> 3. Set custom menu icon (application launcher?)
> 4. Set default menu style to "Application Menu"
> 5. Remove section "Places" from "Computer" tab, or even remove
> "Computer" tab completely in Application Launcher
> 6. Remove "New Session" feature (from all the places: menu, screen
> locker, etc)
> 7. Place some applications as "Favorites" by default
> 8. Remove "device notifier" and some other applets
> 
> 
> Any idea how to do (any of) that? Preferably without patching existing
> programs (but if no other option - this will also do).

I'm not an expert in that area, so I cannot really help. But as nobody else 
replied so far, I better answer with my half knowledge ;-)

Did you consider asking on the new distributions mailing list at https://
mail.kde.org/mailman/listinfo/distributions. If you are not yet subscribed you 
should ;-) It's also meant as a way to exchange knowledge and their are 
distributions doing that. Almost every distribution exchanges e.g. the 
wallpaper, so the knowledge is there.

Concerning points 3-5, 7: Eike, is that possible at all? If yes could you 
please tell Marek?

Concerning point 6: I suggest to use KIOSK for that. See https://
userbase.kde.org/KDE_System_Administration/Kiosk/Introduction

Point 8 might also be doable with KIOSK, but not 100 % sure. I assume your 
idea is not to hide the device notifier but make it impossible to mount devices 
as a user, right?

> 
> I've tried using scripts:
> https://userbase.kde.org/KDE_System_Administration/PlasmaTwoDesktopScripting
> but failed. For example I see no way to remove
> entries/applets/plasmoids. Also debugging is quite painful, because I
> have no idea where to looks for logs (like what entry was loaded, what
> was ignored at all etc), I can only guess looking at the result. And
> frequently wondering why my script wasn't launched at all...

Concerning testing of the script: did you try to run the snippets from the 
Plasma-Scripting console? That way you at least get instant feedback.

Cheers,
Martin

signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

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


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)


So, what do we do?

Cheers,
Thomas


https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ideas to improve activities/desktop automation

2016-07-07 Thread Pierangelo Terzulli

hi Thomas,

Actually I'm aware of that option and is the way I use the rules too.

I apologize for the lack of clarity, I should have stated my use cases better.
What I'm trying to achieve basically is to have different rules for
different *instances* of application runs: I usually run chromium
browser with two different profiles, like this:

$ chromium-browser --profile-directory="Personal"
$ chromium-browser --profile-directory="Work"

Now, each chromium-browser launch will set WM_CLASS to
"chromium-browser-chromium" in my case, making both instances
indistinguishable from one another. This is because, in my
understanding, currently there are only X window related rules, and
not per-process rules.

Consider another use case: within dolphin, you open in a new window
different folders: ~user/work and ~/user/music. There's no way,
currently, to tell plasma that each dolphin instance should belong to
different activities/desktops.

Yet another, more general: having different launchers for chromium
(one for each profile) in, say, quicklaunch plasmoid (the
configuration I actually use, to be honest): there still no way for
kwinrules to distinguish the two instances.

Generally, you can't indicate on what particular activity/desktop an
application should run at launch time, you only can have preconfigured
matching rules, and the matching rules are only X window related, not
process related (say, PID, cmd arguments, user, working folder...).

I hope to have clarified it better now.

I'm not sure if this kind of ability should be kwin responsibility at
all, I think is more related to Task Management. KWin should only be
provided some "hints" to where to put a particular window.

What do you think?

2016-07-07 11:31 GMT+02:00 Thomas Pfeiffer :
> On 07.07.2016 10:50, Pierangelo Terzulli wrote:
>>
>> hi everyone!
>
> Hi Pierangelo,
>>
>> argument like a path for a file manager or a url for a browser).
>>
>> At the moment (please correct me if wrong) such ability is provided by
>> the kwinrules kcm module, but the criteria it provides are related to
>> X window properties only, no application name can be specified, nor a
>> command argument.
>
> I have to correct you, actually ;) The KWin rules can match to an
> application
> name (in fact that's the only way I use them).
> You just enter the application name in the "Window class (application)"
> field and
> you have a rule for an application.
> Actually the clearer way to define application rules is to click the menu
> icon in the
> application's window (the one with the application's icon) or right-click
> the title bar
> and in the menu choose "More Actions -> Special Application settings". This
> creates
> a KWin rule for the application.
> That means that we do not need a new feature, KWin does what you need
> perfectly
> fine.
> The fact that you were not aware of this possibility (and apparently nobody
> in
> #plasma was able to help you, either) points to a usability problem,
> however.
> I know that Martin considers the KWin rules an advanced feature targeting
> users
> which can figure it out themselves, but now we know there is at least one
> person
> who is advanced enough to want such a feature, but not advanced enough to
> understand its UI. Maybe we should work on its usability, after all...
>
> If you have any ideas for how to make it more clear how to set up rules for
> applications, they're welcome!
>
> Cheers,
> Thomas
>
>>
>> How would you solve such a problem? Is it possible at all with the
>> current technology (X11, wayland, TaskManager)? What changes are
>> required to provide such functionality?
>>
>> Here are some links that have dealt with some aspect of this scenario:
>>
>>
>> http://unix.stackexchange.com/questions/46621/what-process-created-this-window-with-no-pid-associated
>>
>>
>> http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window
>>
>> https://www.x.org/releases/X11R7.7/doc/resourceproto/resproto.txt
>> ___
>> Plasma-devel mailing list
>> Plasma-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: ideas to improve activities/desktop automation

On 07.07.2016 10:50, Pierangelo Terzulli wrote:

hi everyone!

Hi Pierangelo,

argument like a path for a file manager or a url for a browser).

At the moment (please correct me if wrong) such ability is provided by
the kwinrules kcm module, but the criteria it provides are related to
X window properties only, no application name can be specified, nor a
command argument.

I have to correct you, actually ;) The KWin rules can match to an application
name (in fact that's the only way I use them).
You just enter the application name in the "Window class (application)" field
and
you have a rule for an application.
Actually the clearer way to define application rules is to click the menu icon
in the
application's window (the one with the application's icon) or right-click the
title bar

and in the menu choose "More Actions -> Special Application settings". This
creates
a KWin rule for the application.
That means that we do not need a new feature, KWin does what you need perfectly
fine.
The fact that you were not aware of this possibility (and apparently nobody in
#plasma was able to help you, either) points to a usability problem, however.
I know that Martin considers the KWin rules an advanced feature targeting users
which can figure it out themselves, but now we know there is at least one person
who is advanced enough to want such a feature, but not advanced enough to
understand its UI. Maybe we should work on its usability, after all...

If you have any ideas for how to make it more clear how to set up rules for
applications, they're welcome!

Cheers,
Thomas

How would you solve such a problem? Is it possible at all with the
current technology (X11, wayland, TaskManager)? What changes are
required to provide such functionality?

Here are some links that have dealt with some aspect of this scenario:

http://unix.stackexchange.com/questions/46621/what-process-created-this-window-with-no-pid-associated

http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window

https://www.x.org/releases/X11R7.7/doc/resourceproto/resproto.txt
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?

2016-07-07 Thread Ivan Čukić

I also find Cantata a strange choice (even though I do use it :) ).
Was Clementine-qt5 considered?

I do not think VLC is a suitable replacement for a proper music
player. (if we took that claim, we could easily say everything here is
irrelevant since the web browser is all the user needs...)

As for the browser, while I do agree with Martin regarding the slow Qt
security updates, I do not think we should actively discourage their
use.

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

[Differential] [Updated] D2108: Add support for xdg-shell version 5 interface

graesslin added a dependency: D2102: Add support for xdg-shell.

REPOSITORY
  rKWIN KWin

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, hardening, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated] D2102: Add support for xdg-shell

graesslin added a dependent revision: D2108: Add support for xdg-shell version 
5 interface.

REPOSITORY
  rKWAYLAND KWayland

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Request, 534 lines] D2108: Add support for xdg-shell version 5 interface

graesslin created this revision.
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added subscribers: kwin, plasma-devel.
Restricted Application added projects: Plasma on Wayland, KWin.

REVISION SUMMARY
  The WaylandServer creates the XdgShellV5 interface and hooks it up
  to create a ShellSurface whenever an xdg surface or xdg popup is created.
  
  ShellClient gains some new ctors for the different variants and is
  adjusted to delegate to xdg surface respectively.
  
  With this change KWin mostly supports xdg-shell protocol. Still missing
  is support for the "geometry" request which is rather difficult to
  implement in KWin.

REPOSITORY
  rKWIN KWin

BRANCH
  xdg-shell

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

AFFECTED FILES
  autotests/integration/debug_console_test.cpp
  autotests/integration/decoration_input_test.cpp
  autotests/integration/dont_crash_no_border.cpp
  autotests/integration/input_stacking_order.cpp
  autotests/integration/kwin_wayland_test.h
  autotests/integration/scene_qpainter_test.cpp
  autotests/integration/shell_client_test.cpp
  autotests/integration/test_helpers.cpp
  shell_client.cpp
  shell_client.h
  wayland_server.cpp
  wayland_server.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #kwin, #plasma_on_wayland
Cc: plasma-devel, kwin, hardening, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Differential] [Updated, 3,913 lines] D2102: Add support for xdg-shell

graesslin updated this revision to Diff 5000.
graesslin added a comment.


  - renamed the server files to have them named like client files
  - renamed some methods on client side to have them like Shell

REPOSITORY
  rKWAYLAND KWayland

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D2102?vs=4983=5000

BRANCH
  xdg-shell

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

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_wayland_registry.cpp
  autotests/client/test_xdg_shell.cpp
  src/client/CMakeLists.txt
  src/client/protocols/xdg-shell-unstable-v5.xml
  src/client/registry.cpp
  src/client/registry.h
  src/client/xdgshell.cpp
  src/client/xdgshell.h
  src/client/xdgshell_p.h
  src/client/xdgshell_v5.cpp
  src/server/CMakeLists.txt
  src/server/display.cpp
  src/server/display.h
  src/server/generic_shell_surface_p.h
  src/server/shell_interface.cpp
  src/server/shell_interface.h
  src/server/xdgshell_interface.cpp
  src/server/xdgshell_interface.h
  src/server/xdgshell_interface_p.h
  src/server/xdgshell_v5_interface.cpp
  src/server/xdgshell_v5_interface_p.h
  src/tools/mapping.txt

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: graesslin, #plasma_on_wayland
Cc: plasma-devel, jensreuterberg, sebas
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Which applications does the Plasma team recommend to use with Plasma?