[Differential] [Commented On] D3616: [Lock Screen / Login] Add "reveal password button"

[broulik (Kai Uwe Broulik)]

broulik added a comment.


  One thing we perhaps should do is add a kiosk restriction to globally disable 
this button everywhere.

REPOSITORY
  R120 Plasma Workspace

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

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

To: broulik, #plasma:_design, #plasma, graesslin
Cc: cfeck, graesslin, subdiff, plasma-devel, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas

Re: Selecting a Plasma logo

[Ken Vermette]

I think this is likely the best and most expedient idea. Just list all the
potential logotypes and have everyone score every logo on a scale.
Whichever logo has the highest score becomes the Plasma logo. If there's a
tie the VDG serves as tiebreaker.

If everyone is O.K. with something like Google Forms (for this one-time
selection) I could have something up very quickly... Unless we already have
some very fast-and-easy internal form tool. I know some people have a thing
against Google, but it's the fastest way I can think of, it has
anti-favoritism feature (question shuffling) and we need to just get this
done without making it overcomplicated. We can also require email addresses
(but not require Google accounts) to verify people have only voted one time.

Here's my proposal: we get a form up tomorrow, put it on plasma-devel
mailing lists. We set the voting deadline to December 23rd midnight, giving
the vote just over two weeks. That gives us a time to commit the new logo
to Plasma 5.9 before freeze, and for those of us who celebrate the holidays
in December we can announce the new logo as a "Present" on Planet KDE.

Does that sound like a plan?

On Wed, Dec 7, 2016 at 2:58 PM, Martin Gräßlin  wrote:

> Am 2016-12-07 18:04, schrieb Marco Martin:
>
>> Hi Jens,
>> Thanks to make this rolling again!
>> and yes, is massively about time to decide something
>>
>> On Wednesday 07 December 2016 13:58:34 Jens Reuterberg wrote:
>>
>>> #1 means that we with a high level of chance will go to the Plasma logo
>>> we
>>> had before this started. There is zero criticism against it that has been
>>> valid except that the developers who didn't like it in the first place
>>> didn't like it. Which is relevant of course.
>>>
>>
>> I would be fine with that logo
>>
>> Unless something is posted here my assumption is that the design decision
>>> is
>>> up to the KDE Design Group/VDG and we will choose, reply and move on with
>>> this and our lives.
>>>
>>
>> As the current status goes, for me the best one is Uri's logo (I prefer
>> if is
>> always used monochrome tough)
>>
>
> I think there were a few issues with the selection process. I remember
> that it was very difficult to say which ones were up to discussion (the
> second version of the version provided by foo).
>
> And that made it really hard.
>
> Maybe go back a step and create a questionaire with all the icons and let
> the devs vote on it in a from 1 to 5 scale to figure out which ones are
> liked and which ones not.
>
> Personally I find it important that the developers have a say in what the
> logo is. I think we identify by it and the logo needs to work with us.
>
> Cheers
> Martin
>

Re: KDE 4 vs 5, regional settings and dolphin

[René J . V . Bertin]

Christoph Feck wrote:

> http://www.ivoras.net/blog/tree/2010-12-20.the-wonderful-en_dk-locale.html

Heh, more or less what I thought it was. The weird thing is that both Ireland 
and Malta are English-speaking EU countries that use the € and metric system. 

Anyway ... :)

[Differential] [Accepted] D3616: [Lock Screen / Login] Add "reveal password button"

[Martin Gräßlin]

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


  +1  from KScreenlocker maintainer. If you also want VDG input, please wait :-)

REPOSITORY
  R120 Plasma Workspace

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

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

To: broulik, #plasma:_design, #plasma, graesslin
Cc: graesslin, subdiff, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas

Re: Selecting a Plasma logo

[Martin Gräßlin]

Am 2016-12-07 18:04, schrieb Marco Martin:

Hi Jens,
Thanks to make this rolling again!
and yes, is massively about time to decide something

On Wednesday 07 December 2016 13:58:34 Jens Reuterberg wrote:
#1 means that we with a high level of chance will go to the Plasma 
logo we
had before this started. There is zero criticism against it that has 
been

valid except that the developers who didn't like it in the first place
didn't like it. Which is relevant of course.


I would be fine with that logo

Unless something is posted here my assumption is that the design 
decision is
up to the KDE Design Group/VDG and we will choose, reply and move on 
with

this and our lives.


As the current status goes, for me the best one is Uri's logo (I prefer 
if is

always used monochrome tough)


I think there were a few issues with the selection process. I remember 
that it was very difficult to say which ones were up to discussion (the 
second version of the version provided by foo).


And that made it really hard.

Maybe go back a step and create a questionaire with all the icons and 
let the devs vote on it in a from 1 to 5 scale to figure out which ones 
are liked and which ones not.


Personally I find it important that the developers have a say in what 
the logo is. I think we identify by it and the logo needs to work with 
us.


Cheers
Martin

[Differential] [Commented On] D3616: [Lock Screen / Login] Add "reveal password button"

[cfeck (Christoph Feck)]

cfeck added a comment.


  Using that argument, we would have to remove the 'reveal password' option 
from KPasswordDialog, too.

REPOSITORY
  R120 Plasma Workspace

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

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

To: broulik, #plasma:_design, #plasma, graesslin
Cc: cfeck, graesslin, subdiff, plasma-devel, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas

[Differential] [Commented On] D3616: [Lock Screen / Login] Add "reveal password button"

[subdiff (Roman Gilg)]

subdiff added a comment.


  On one hand: Yea, why not.
  
  On the other imagine the following situation: Two people sit in front of the 
PC, and one of them wants to login to the PC. After entering his password, he 
accidently hits the "show password" icon (since it's pretty near to the 
"Unlock"-Button. His password has been compromised in this moment and he needs 
to change it now. In a company setting it could get really ugly, if only an 
admin is able to. Or if the user is not able to (my mum). Login passwords are 
in general more undisclosed than for example Wlan passwords (which every second 
guy coming over for lunch would get from me ... I know it's bad).

REPOSITORY
  R120 Plasma Workspace

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

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

To: broulik, #plasma, #plasma:_design
Cc: subdiff, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

Re: Selecting a Plasma logo

[Marco Martin]

Hi Jens,
Thanks to make this rolling again!
and yes, is massively about time to decide something

On Wednesday 07 December 2016 13:58:34 Jens Reuterberg wrote:
> #1 means that we with a high level of chance will go to the Plasma logo we
> had before this started. There is zero criticism against it that has been
> valid except that the developers who didn't like it in the first place
> didn't like it. Which is relevant of course.

I would be fine with that logo

> Unless something is posted here my assumption is that the design decision is
> up to the KDE Design Group/VDG and we will choose, reply and move on with
> this and our lives.

As the current status goes, for me the best one is Uri's logo (I prefer if is 
always used monochrome tough)

-- 
Marco Martin

Re: KDE 4 vs 5, regional settings and dolphin

[Christoph Feck]

On 07.12.2016 14:41, René J. V. Bertin wrote:

Christoph Feck wrote:


See bug 340982.

KF5 applications do not use the customizable KLocale class, but use what
Qt offers (QLocale), which we hoped would soon get support for
customizations, but progress is slow, so no code has surfaced.


I just played with a full Plasma5 desktop (KaOS) and noticed that it has a
Regional Settings/Locale KCM I don't have on my own install, for as yet unclear
reasons. It seems it gives an additional step in the right direction though it
is still based on predefined locales.

It made me discover there's apparently a Danish-English flavour, strange :)


http://www.ivoras.net/blog/tree/2010-12-20.the-wonderful-en_dk-locale.html

[Differential] [Updated] D3617: [Touchpad KCM] New KWin Wayland version

[subdiff (Roman Gilg)]

subdiff updated the summary for this revision.

REPOSITORY
  R119 Plasma Desktop

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

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

To: subdiff, #kwin, #plasma_on_wayland, #plasma, #vdg
Cc: kwin, plasma-devel, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, eliasp, sebas

[Differential] [Updated] D3617: [Touchpad KCM] New KWin Wayland version

[subdiff (Roman Gilg)]

subdiff added a reviewer: VDG.

REPOSITORY
  R119 Plasma Desktop

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

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

To: subdiff, #kwin, #plasma_on_wayland, #plasma, #vdg
Cc: kwin, plasma-devel, lesliezhai, ali-mohamed, hardening, jensreuterberg, 
abetts, eliasp, sebas

[Differential] [Request, 2,415 lines] D3617: [Touchpad KCM] New KWin Wayland version

[subdiff (Roman Gilg)]

subdiff created this revision.
subdiff added reviewers: KWin, Plasma on Wayland, Plasma.
subdiff added a subscriber: plasma-devel.
subdiff set the repository for this revision to R119 Plasma Desktop.
subdiff added a project: Plasma.
Restricted Application edited projects, added Plasma on Wayland, KWin; removed 
Plasma.
Restricted Application added a subscriber: kwin.

REVISION SUMMARY
  In order to work under KWin Wayland the Touchpad KCM needed to be adjusted. 
In theory this should have meant only the creation of an additional backend. 
But since a libinput based touchpad configuration utility needs to be in many 
ways different than the legacy X version the decision was made to redesign the 
user interface aswell.
  
  Feature summary:
  
  
  - Changes the configuration of each connected touchpad individually
  - Saves changes per device (through the KWin libinput backend) in a config 
file.
  - Quick switch between devices via drop-down list.
  - Loads and removes devices on the fly on hotplugging events and informs the 
user with animated messages.
  - Visual indication if a property is not supported by a device
  - Tooltips give additional informations about available options
  
  Technical overview:
  ---
  
  The KCModule was redesigned as a container, which loads on opening a X or 
Wayland plugin dependent on the active windowing system. In the X case it loads 
the legacy QWidget, which was untouched besides integration work in the new 
plugin structure. In the Wayland case, it loads the new QML based user 
interface, which was written from scratch.
  
  The user interface then instantiates appropriate backend. In the X case it 
loads the old backend, which was also not changed. The Wayland backend was 
created aswell from scratch.
  
  **Backend:**
  `KWinWaylandBackend` queries available devices from KWin via D-Bus and 
creates `KWinWaylandTouchpad` instances for each available touchpad.
  
  `KWinWaylandTouchpad` gets via D-Bus all properties from KWin, which are 
relevant for a touchpad and saves them in property structs. This includes: 
Boolean if the property is supported by the specific touchpad. Default and 
reset values for the generic KCModule actions. And the D-Bus name in order to 
write changes back later on
  
  When requested by the KCModule, the backend sends all changed values back to 
KWin, which then forwards them to libinput and saves them in its config file. 
The backend also connect to KWin signals over D-Bus, which emit in case a 
touchpad gets disconnected or another one additionally connected.
  
  **Frontend:**
  Loads the device list from the backend and all properties of the selected 
touchpad. If a value gets changed in the ui, it writes directly back to the 
`KWinWaylandTouchpad` instance.
  
  If there is no touchpad available an info message is shown and the control 
elements get disabled. If a touchpad is then connected, it is automatically 
loaded and the message vanishes. A similar message is shown when disconnecting 
the touchpad with currently opened configuration.
  
  **Requests for help / future work:**
  I need in particular feedback on my QML coding. I hope it's fine in general 
but there is most certainly stuff to be improved. Also the option and tooltip 
texts need someone else to take a look on.
  
  The touchpad in my laptop doesn't support "Scroll-on-Button-Down". Since I 
would've needed to test the functionality somehow while coding, I didn't 
implement it yet and only did some ground work.
  
  The hot plug handling seems a bit overengineered for touchpads, which are 
normally permanently installed. But most functionality of this KCM in general 
could be transferred to a new Wayland based Mouse KCM, which also could needs 
an overhaul. Maybe this could be a project for a just starting contributer, 
since it would involve different areas of Plasma/KWin while there is already a 
similar example with the Touchpad KCM.
  
  F673982: 001-cut.png 

TEST PLAN
  Manually tested with a single touchpad in my laptop. In order to test the hot 
plugging I changed the reply value in `KWinWaylandBackend` to also gather other 
pointer devices. This way I could test it with multiple mice over USB.

REPOSITORY
  R119 Plasma Desktop

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

AFFECTED FILES
  kcms/touchpad/src/CMakeLists.txt
  kcms/touchpad/src/backends/kwin_wayland.cmake
  kcms/touchpad/src/backends/kwin_wayland/kwinwaylandbackend.cpp
  kcms/touchpad/src/backends/kwin_wayland/kwinwaylandbackend.h
  kcms/touchpad/src/backends/kwin_wayland/kwinwaylandtouchpad.cpp
  kcms/touchpad/src/backends/kwin_wayland/kwinwaylandtouchpad.h
  kcms/touchpad/src/backends/x11/xlibbackend.h
  kcms/touchpad/src/kcm/customconfigdialogmanager.cpp
  kcms/touchpad/src/kcm/customconfigdialogmanager.h
  kcms/touchpad/src/kcm/customslider.cpp
  kcms/touchpad/src/kcm/customslider.h
  kcms/touchpad/src/kcm/libinput/co

Re: status of kde/plasma kiosk framework in kf5

[David Edmundson]

>
>
> > i also kinda hacked my own secure environment where shell access is not
> allowed by placing a .desktop file in .local/share/kservices5/ServiceMenus/
> that allows me to open a terminal in the current folder ^^
> > dolphin shouldn't allow this.. right?
>
> Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that
> tells klauncher to refuse to start it when such restriction is in effect.
>
> I'll cc David Faure as KIO master whether he knows how to prevent the
> system from picking up custom applications and services in the user's home.
> I thought that the .desktop files needed to be marked executable but that
> doesn't seem to be the case. David? Maybe "run_desktop_files" restriction
> helps here?
>
> We have the key
run_desktop_files

This should prevent loading any .desktop files in .local

(in theory at least)
David

Re: KaOS locale KCM (KDE 4 vs 5, regional settings and dolphin)

[René J . V . Bertin]

René J. V. Bertin wrote:

> I just played with a full Plasma5 desktop (KaOS) and noticed that it has a
> Regional Settings/Locale KCM I don't have on my own install, for as yet
> unclear reasons. It seems it gives an additional step in the right direction

Clear now: https://github.com/KaOSx/user-kcm

HtH

R.

Re: status of kde/plasma kiosk framework in kf5

[Dennis Knorr]

Am 07.12.2016 um 10:46 schrieb Kai Uwe Broulik:
> Even if the entries still show up in the context menu when you restricted 
> them (which would be a bug you should report) kcmshell will still refuse to 
> open it, so it should be purely cosmetical then.
> 
> I *think* the network editor, not being a regular system settings module, 
> cannot currently be restricted. :/ Needs to be figured out.

If you talk about the network editor for the
networkmanagement-plasma/networkmanager, you can restrict the
networkmanager directly

Either with polkit, this is done like it is described in
https://ubuntuforums.org/showthread.php?t=2141331
or with networkmanager itself.

For this, You would have to define a network-connection and with "nmcli
general permissions" you can see the current configuration and restrict
modification to a connection (only stop/start/restart it for example).
This is than written down in
/etc/networkmanager/system-connection/connectionname where users and
groups are specified which are allowed to edit/start/stop connections :)

Re: Review Request 128038: [libtaskmanager] Stop highlighted window effect in group item

[Anthony Fieroni]

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



You not against i plan to ship this patch next week.

- Anthony Fieroni


On Dec. 4, 2016, 1:07 p.m., Anthony Fieroni wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128038/
> ---
> 
> (Updated Dec. 4, 2016, 1:07 p.m.)
> 
> 
> Review request for Plasma, Kai Uwe Broulik, David Edmundson, and Eike Hein.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> 1. Enable highlighted window, tooltips and grouping
> 2. Open group item tasl by clicking left mouse button
> 3. Move mouse cursor over item in group
> 
> Before:
> 1. Items are samll and tough readable
> 2. Items aren't visible cause a highligthWindow effect
> 3. Clicking on tooltip close button case highlightWindow effect to not stop
> 
> After:
> 1. Items are proof readable
> 2. Items are visible
> 3. HighlightWdindow effect is stopped
> 
> 
> Diffs
> -
> 
>   applets/taskmanager/package/contents/ui/GroupDialog.qml 829fcf0 
>   applets/taskmanager/package/contents/ui/Task.qml 0a59d53 
>   applets/taskmanager/package/contents/ui/ToolTipWindowMouseArea.qml e3551df 
>   applets/taskmanager/package/contents/ui/main.qml e53b194 
>   applets/taskmanager/plugin/backend.h a3788b0 
>   applets/taskmanager/plugin/backend.cpp 4ef5b88 
> 
> Diff: https://git.reviewboard.kde.org/r/128038/diff/
> 
> 
> Testing
> ---
> 
> Screenshot with expected behavior by clicking left button on group item.
> 
> 
> File Attachments
> 
> 
> Vertical panel
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/35dd438c-fae2-4daa-ba30-09f70ea3b920__Screenshot_20161203_210914.png
> Horizontal panel
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/fe7c9cab-bb2a-4d17-85de-1934c81a33dc__Screenshot_20161203_211120.png
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

Re: KDE 4 vs 5, regional settings and dolphin

[René J . V . Bertin]

Christoph Feck wrote:

> See bug 340982.
> 
> KF5 applications do not use the customizable KLocale class, but use what
> Qt offers (QLocale), which we hoped would soon get support for
> customizations, but progress is slow, so no code has surfaced. 

I just played with a full Plasma5 desktop (KaOS) and noticed that it has a 
Regional Settings/Locale KCM I don't have on my own install, for as yet unclear 
reasons. It seems it gives an additional step in the right direction though it 
is still based on predefined locales.

It made me discover there's apparently a Danish-English flavour, strange :)

R.

Re: Selecting a Plasma logo

[Jens Reuterberg]

About half a year ago this thread started and so far no actual change has 
happened. 

The background is that the past logo for Plasma Desktop was disagreed upon by 
the Plasma developer team and they wanted a new one. Thomas created a 
competition of sorts which had a lot of suggestions in it.

Currently, no final decision has been made on this which leaves us with three 
options:
1) VDG decides.
2) The developers decide
3) We use the KDE logo 

Now 

#1 means that we with a high level of chance will go to the Plasma logo we had 
before this started. There is zero criticism against it that has been valid 
except that the developers who didn't like it in the first place didn't like 
it. Which is relevant of course.
#2 means this thread needs a choice. This WILL NOT continue in any structured 
form where people are egged on to make "suggestions" and then a round table 
debate. It has taken work time from VDG contributors, caused meaningless 
arguments and bikeshedding and has been the kind of work we can all see will 
never end. I honestly regret not having the courage to say "No" when it was 
first debated.
(if some designer wants to work with the Plasma Developers on this, go for it, 
no one will stop you of course. But the VDG will not supply designers to this 
task formally or make any further efforts which has been so far a half a year 
of throwing manhours into a pit)
#3 Means that we take the work on seperating KDE the community from Plasma the 
desktop and pretend it didn't happen. Which sounds dramatic but its 
essentially leaving it as a status quo.

Now this is Open Source and KDE, none of us have the right to dictate to 
others what to do with their spare time.
But as a designer I can assure you that what we are doing with this is wasting 
our collective time. 
There is NO perfect solution. No perfect logo for a project which out of the 
blue will summarize everyones expectations and hopes. Nothing that can't be 
shredded in a round session of bikeshedding and "uhms" and "ehrs". There will 
never be a choice made.
The reason why the old icon was the one we stuck with has parts to do with no 
one actually speaking up at the time when it was thrown in there. But that is 
not relevant. 
It is good because it is different from the K, clearly different. It is good 
because it played on the shape of the cashew symbol but using the design 
guides formed in the beginning of Plasma 5. It is good because it is so 
absolutely abstract as to not clash with any other symbolism out there. It is 
a blank slate to be loaded with meaning instead of an heraldic symbol where 
the meaning and statements we feel we are part of need to be presented. 
This is also BAD as it needs to be used and reused to gain meaning. If we 
don't use it it is JUST a bit of abstract scribble. 

None of this means that the suggestions in the thread Thomas posted are bad, 
or worse than, or subpar or anything. It just means that if the choice was 
mine - if we where picking one thing to present to a client in a professional 
setting. I would pick the original logo without a second hesitation. 

Unless something is posted here my assumption is that the design decision is 
up to the KDE Design Group/VDG and we will choose, reply and move on with this 
and our lives.


On Monday, 25 July 2016 20:54:14 CET Thomas Pfeiffer wrote:
> Dear Plasma development team, dear VDG,
> the official deadline for the Plasma logo contest has passed yesterday.
> We have five entries into the contest, with one actually consisting of five
> different mash-ups and modifications of the other entries, and one being
> Plasma's current logo.
> You can find all the proposals here:
> https://forum.kde.org/viewtopic.php?f=285&t=133836
> I think we have quite a good selection here, and hope that we can find
> something here which we can agree on.
> In the contest thread, I promised a jury consisting of VDG members and
> Plasma team members.
> Now I've decided that since the whole Plasma team has to be able to identify
> themselves with the logo, and all VDG members should have the possibility
> to chip in as well, everyone who participates in the discussion is part of
> the jury. There won't be a voting process. Either we can agree on a logo,
> or everything stays like it is (the official Plasma logo still being what
> we have now, and the K logo being used for the launchers).
> I'd give us a discussion period until Sunday, unless a clear agreement can
> be reached before that.
> Please refer to the logo proposals by the creator's forum name (remember
> that our current logo is Uri's, not mine ;) ), and for Ken's just say e.g.
> "Ken's fourth logo".
> Happy discussions, here is to us finding a logo we can all (at least more or
> less) identify with!
> 
> Thomas
> ___
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

plasma-nm build failure

[Jonathan Riddell]

plasma-nm has a build failure in stable today

http://build.neon.kde.org/job/xenial_stable_plasma_plasma-nm_bin_amd64/56/console

bug is
https://bugs.kde.org/show_bug.cgi?id=363917

https://cgit.kde.org/plasma-nm.git/commit/?h=Plasma/5.8&id=a51e9c5c2a2c32ef8d2f354af33532cbc35bfa9e

It doesn't seem to fail in build.kde.org

Jonathan

[Differential] [Closed] D3603: Option to show percentage charge in the icon

[mart (Marco Martin)]

This revision was automatically updated to reflect the committed changes.
Closed by commit R120:27ac0b760855: Option to show percentage charge in the 
icon (authored by mart).

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3603?vs=8843&id=8844

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

AFFECTED FILES
  applets/batterymonitor/package/contents/config/config.qml
  applets/batterymonitor/package/contents/config/main.xml
  applets/batterymonitor/package/contents/ui/BadgeOverlay.qml
  applets/batterymonitor/package/contents/ui/CompactRepresentation.qml
  applets/batterymonitor/package/contents/ui/ConfigGeneral.qml
  applets/batterymonitor/package/contents/ui/batterymonitor.qml

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

To: mart, broulik, #plasma
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Updated, 177 lines] D3603: Option to show percentage charge in the icon

[mart (Marco Martin)]

mart updated this revision to Diff 8843.
mart added a comment.


  - use anchors

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3603?vs=8840&id=8843

BRANCH
  phab/batterypercent

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

AFFECTED FILES
  applets/batterymonitor/package/contents/config/config.qml
  applets/batterymonitor/package/contents/config/main.xml
  applets/batterymonitor/package/contents/ui/BadgeOverlay.qml
  applets/batterymonitor/package/contents/ui/CompactRepresentation.qml
  applets/batterymonitor/package/contents/ui/ConfigGeneral.qml
  applets/batterymonitor/package/contents/ui/batterymonitor.qml

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

To: mart, broulik, #plasma
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Accepted] D3603: Option to show percentage charge in the icon

[broulik (Kai Uwe Broulik)]

broulik accepted this revision.
broulik added a reviewer: broulik.
broulik added inline comments.
This revision is now accepted and ready to land.

INLINE COMMENTS

> BadgeOverlay.qml:31
> +id: badgeRect
> +x: Qt.application.layoutDirection === Qt.RightToLeft ? 0 : 
> parent.width - width
> +y: parent.height - height

just use anchors?

REPOSITORY
  R120 Plasma Workspace

BRANCH
  phab/batterypercent

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

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

To: mart, #plasma, broulik
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Request, 2 lines] D3616: [Lock Screen / Login] Add "reveal password button"

[broulik (Kai Uwe Broulik)]

broulik created this revision.
broulik added reviewers: Plasma, Plasma: Design.
broulik set the repository for this revision to R120 Plasma Workspace.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Allows to show the password on click, similar to how it's done in most other 
password fields throughout the workspace.

TEST PLAN
  F672029: Screenshot_20161207_125143.png 

REPOSITORY
  R120 Plasma Workspace

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

AFFECTED FILES
  lookandfeel/contents/lockscreen/MainBlock.qml
  sddm-theme/Login.qml

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

To: broulik, #plasma, #plasma:_design
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas

[Differential] [Updated, 175 lines] D3603: Option to show percentage charge in the icon

[mart (Marco Martin)]

mart updated this revision to Diff 8840.
mart added a comment.


  - add missing file

REPOSITORY
  R120 Plasma Workspace

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D3603?vs=8802&id=8840

BRANCH
  phab/batterypercent

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

AFFECTED FILES
  applets/batterymonitor/package/contents/config/config.qml
  applets/batterymonitor/package/contents/config/main.xml
  applets/batterymonitor/package/contents/ui/BadgeOverlay.qml
  applets/batterymonitor/package/contents/ui/CompactRepresentation.qml
  applets/batterymonitor/package/contents/ui/ConfigGeneral.qml
  applets/batterymonitor/package/contents/ui/batterymonitor.qml

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

To: mart, #plasma
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Commented On] D3603: Option to show percentage charge in the icon

[mart (Marco Martin)]

mart added a comment.


  F672027: Spectacle.T21326.png 

REPOSITORY
  R120 Plasma Workspace

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

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

To: mart, #plasma
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

[Differential] [Commented On] D3603: Option to show percentage charge in the icon

[broulik (Kai Uwe Broulik)]

broulik added a comment.


  You forgot BadgeOverlay.qml

INLINE COMMENTS

> ConfigGeneral.qml:28
> +
> +signal configurationChanged
> +

Unused

> ConfigGeneral.qml:30-31
> +
> +width: childrenRect.width
> +height: childrenRect.height
> +implicitWidth: pageColumn.implicitWidth

Not needed since we have implicitWidth?

> ConfigGeneral.qml:37
> +
> +SystemPalette {
> +id: palette

Unused

REPOSITORY
  R120 Plasma Workspace

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

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

To: mart, #plasma
Cc: broulik, plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas

Re: status of kde/plasma kiosk framework in kf5

[Marco Martin]

On Wednesday 07 December 2016 10:46:29 Kai Uwe Broulik wrote:
> Even if the entries still show up in the context menu when you restricted
> them (which would be a bug you should report) kcmshell will still refuse to
> open it, so it should be purely cosmetical then.
> 
> I *think* the network editor, not being a regular system settings module,
> cannot currently be restricted. :/ Needs to be figured out.

iirc it was recently ported to a kcm, so in future versions this shouldn't be 
a problem?


-- 
Marco Martin

Re: status of kde/plasma kiosk framework in kf5

[Kai Uwe Broulik]

Hi Thomas,

good to hear back from you!

> - Menu for "Edit Applications"  in the launcher called "Anwendungsübersicht" 
> and "Anwendungsmenü" (its working in "Anwendungs-Starter")

That was an oversight, I just uploaded a patch to fix this :)

The others are just shortcuts to system settings modules. You can use the [KDE 
Control Module Restrictions] section in kdeglobals, for instance:

device_automounter_kcm.desktop=false

(You can use kcmshell5 --list to find out the names, there's no extensive 
documented list on what applet uses which, unfortunately)

Even if the entries still show up in the context menu when you restricted them 
(which would be a bug you should report) kcmshell will still refuse to open it, 
so it should be purely cosmetical then.

I *think* the network editor, not being a regular system settings module, 
cannot currently be restricted. :/ Needs to be figured out.

> libreoffice (even when using the kde file open dialogs - libreoffice kde 
> integration ) still allows to enter any folder you like..

This is somewhat to be expected as KIOSK only operates on KIO (KDE's own IO 
Layer). I think you need to use SELinux or AppArmor for that? I'm not an expert 
in that, though. 

> i also kinda hacked my own secure environment where shell access is not 
> allowed by placing a .desktop file in .local/share/kservices5/ServiceMenus/ 
> that allows me to open a terminal in the current folder ^^
> dolphin shouldn't allow this.. right?

Konsole's desktop file has a key X-KDE-AuthorizeAction=shell_access that tells 
klauncher to refuse to start it when such restriction is in effect.

I'll cc David Faure as KIO master whether he knows how to prevent the system 
from picking up custom applications and services in the user's home. I thought 
that the .desktop files needed to be marked executable but that doesn't seem to 
be the case. David? Maybe "run_desktop_files" restriction helps here?

Also, I bet a user can still launch xterm even with shell_access. Problem about 
KIOSK is that it's really only enforced be KDE stuff, so again: perhaps have a 
look at SELinux / AppArmor to make sure everyone plays well ;)

> Getting "dolphins" places panel locked too when other toolbars are locked - 
> is this a featurerequest or a bugreport?

I don't fully understand, which restriction does what exactly to the panel in 
Dolphin?

> if i'm done with it i'm definitely going to write an extensive howto and a 
> little program :-)

Looking forward to it!

> PS: i am working on a plasma based "secure exam environment" (for austrian 
> schools) which i'm going to present at the "day of digital education" at 
> klagenfurt's university in 2 months.

Sounds interesting, looking forward to hearing your report how it went. We're 
glad you've chosen Plasma for this challenge! 

> most of it is kdialog for now

We could surely help you make it prettier than that :)

Thanks slot for your stress tests and feedback,
Kai Uwe 

[Differential] [Request, 4 lines] D3615: [Kicker] Hide "Edit Applications..." context menu entry if system immutable

[broulik (Kai Uwe Broulik)]

broulik created this revision.
broulik added reviewers: Plasma, hein.
broulik set the repository for this revision to R119 Plasma Desktop.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  We don't want users in a locked-down environment to mess with applications.
  This makes it consistent with Kickoff.

TEST PLAN
  Reported in 
https://mail.kde.org/pipermail/enterprise/2016-December/35.html
  
  Placed the following in kdeglobals:
  
[KDE Action Restrictions]
plasma/plasmashell/unlockedDesktop=false
  
  No longer got "Edit Applications..." entry in Kickoff and kickerdash. Without 
it behaves like before.

REPOSITORY
  R119 Plasma Desktop

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

AFFECTED FILES
  applets/kicker/package/contents/ui/main.qml

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

To: broulik, #plasma, hein
Cc: plasma-devel, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas