Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[Martin Gräßlin]

> On Dec. 15, 2014, 11:45 p.m., Àlex Fiestas wrote:
> > Code looks good. 
> > 
> > Could you perhaps add an integration test for this? Since we are 
> > "abstracted" by the socket it should be possible. If it is too much work 
> > feel free to push it.

what do you want the integration test to test? I certainly can start the daemon 
but I'm not sure what it would give us as the only way to return from it 
requires a password. And that's what the test application in tests already does.


- Martin


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


On Dec. 15, 2014, 10:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated Dec. 15, 2014, 10:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[Àlex Fiestas]

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

Ship it!


Code looks good. 

Could you perhaps add an integration test for this? Since we are "abstracted" 
by the socket it should be possible. If it is too much work feel free to push 
it.

- Àlex Fiestas


On des. 15, 2014, 9:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated des. 15, 2014, 9:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121219: Load IconItem immediately upon componentComplete()

[Kai Uwe Broulik]

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

(Updated Dec. 15, 2014, 7:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-framework


Description
---

This makes the IconItem load the icon immediately after component creation and 
not wait 150ms there for no reason which prevents eg. flickering in the OSD 
when it shows up.


Diffs
-

  src/declarativeimports/core/iconitem.h 8aecd17 
  src/declarativeimports/core/iconitem.cpp ed3bb97 

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


Testing
---

Totally forgot about that, just took it for granted that the OSD wouldn't 
flicker anymore.
Resizing applets still has it scale the texture before re-rendering it.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 121219: Load IconItem immediately upon componentComplete()

[Kai Uwe Broulik]

> On Dez. 15, 2014, 5:49 nachm., David Edmundson wrote:
> > So is everything fixed now?
> 
> Kai Uwe Broulik wrote:
> Looks that way.
> 
> Eike Hein wrote:
> https://www.youtube.com/watch?v=k4onJ7Z2MLI

GEMA … but I get what you mean xd


- Kai Uwe


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


On Dez. 5, 2014, 9:20 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121219/
> ---
> 
> (Updated Dez. 5, 2014, 9:20 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This makes the IconItem load the icon immediately after component creation 
> and not wait 150ms there for no reason which prevents eg. flickering in the 
> OSD when it shows up.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 8aecd17 
>   src/declarativeimports/core/iconitem.cpp ed3bb97 
> 
> Diff: https://git.reviewboard.kde.org/r/121219/diff/
> 
> 
> Testing
> ---
> 
> Totally forgot about that, just took it for granted that the OSD wouldn't 
> flicker anymore.
> Resizing applets still has it scale the texture before re-rendering it.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 121219: Load IconItem immediately upon componentComplete()

[Eike Hein]

> On Dec. 15, 2014, 5:49 p.m., David Edmundson wrote:
> > So is everything fixed now?
> 
> Kai Uwe Broulik wrote:
> Looks that way.

https://www.youtube.com/watch?v=k4onJ7Z2MLI


- Eike


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


On Dec. 5, 2014, 9:20 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121219/
> ---
> 
> (Updated Dec. 5, 2014, 9:20 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This makes the IconItem load the icon immediately after component creation 
> and not wait 150ms there for no reason which prevents eg. flickering in the 
> OSD when it shows up.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 8aecd17 
>   src/declarativeimports/core/iconitem.cpp ed3bb97 
> 
> Diff: https://git.reviewboard.kde.org/r/121219/diff/
> 
> 
> Testing
> ---
> 
> Totally forgot about that, just took it for granted that the OSD wouldn't 
> flicker anymore.
> Resizing applets still has it scale the texture before re-rendering it.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 121219: Load IconItem immediately upon componentComplete()

[Kai Uwe Broulik]

> On Dez. 15, 2014, 5:49 nachm., David Edmundson wrote:
> > So is everything fixed now?

Looks that way.


- Kai Uwe


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


On Dez. 5, 2014, 9:20 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121219/
> ---
> 
> (Updated Dez. 5, 2014, 9:20 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This makes the IconItem load the icon immediately after component creation 
> and not wait 150ms there for no reason which prevents eg. flickering in the 
> OSD when it shows up.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 8aecd17 
>   src/declarativeimports/core/iconitem.cpp ed3bb97 
> 
> Diff: https://git.reviewboard.kde.org/r/121219/diff/
> 
> 
> Testing
> ---
> 
> Totally forgot about that, just took it for granted that the OSD wouldn't 
> flicker anymore.
> Resizing applets still has it scale the texture before re-rendering it.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 121219: Load IconItem immediately upon componentComplete()

[David Edmundson]

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

Ship it!


So is everything fixed now?

- David Edmundson


On Dec. 5, 2014, 9:20 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121219/
> ---
> 
> (Updated Dec. 5, 2014, 9:20 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> This makes the IconItem load the icon immediately after component creation 
> and not wait 150ms there for no reason which prevents eg. flickering in the 
> OSD when it shows up.
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/iconitem.h 8aecd17 
>   src/declarativeimports/core/iconitem.cpp ed3bb97 
> 
> Diff: https://git.reviewboard.kde.org/r/121219/diff/
> 
> 
> Testing
> ---
> 
> Totally forgot about that, just took it for granted that the OSD wouldn't 
> flicker anymore.
> Resizing applets still has it scale the texture before re-rendering it.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Jenkins build is back to normal : plasma-workspace_master_qt5 #1146

[KDE CI System]

See 

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

Build failed in Jenkins: plasma-workspace_master_qt5 #1145

[KDE CI System]

See 

Changes:

[bhush94] Register shortcuts for activities management

--
[...truncated 1712 lines...]
 ^
[ 28%] Building CXX object 
appmenu/CMakeFiles/kded_appmenu.dir/menuimporteradaptor.cpp.o
Linking CXX shared library libkworkspace5.so
[ 28%] Building CXX object 
libtaskmanager/CMakeFiles/taskmanager.dir/launcheritem.cpp.o
[ 29%] 
: In 
function ‘int main(int, char**)’:
:139:34:
 warning: unused variable ‘corona’ [-Wunused-variable]
 StandaloneAppCorona *corona = new 
StandaloneAppCorona(cliOptions.value(shellPluginOption));
  ^
Building CXX object 
plasma-windowed/CMakeFiles/plasmawindowed.dir/plasmawindowed_automoc.cpp.o
[ 29%] Built target kworkspace
[ 29%] Building CXX object 
libtaskmanager/CMakeFiles/taskmanager.dir/startup.cpp.o
[ 30%] Building CXX object 
components/shellprivate/CMakeFiles/plasmashellprivateplugin.dir/widgetexplorer/openwidgetassistant.cpp.o
Scanning dependencies of target plasma_packagestructure_layoutemplate
[ 30%] Building CXX object 
shell/packageplugins/layouttemplate/CMakeFiles/plasma_packagestructure_layoutemplate.dir/layouttemplate.cpp.o
[ 31%] Building CXX object 
shell/CMakeFiles/plasmashell.dir/currentcontainmentactionsmodel.cpp.o
[ 31%] [ 31%] Building CXX object 
shell/CMakeFiles/plasmashell.dir/desktopview.cpp.o
Building CXX object 
shell/packageplugins/layouttemplate/CMakeFiles/plasma_packagestructure_layoutemplate.dir/plasma_packagestructure_layoutemplate_automoc.cpp.o
[ 31%] Building CXX object 
shell/CMakeFiles/plasmashell.dir/kidenticongenerator.cpp.o
Scanning dependencies of target plasma_packagestructure_lookandfeel
[ 31%] Building CXX object 
shell/packageplugins/lookandfeel/CMakeFiles/plasma_packagestructure_lookandfeel.dir/lookandfeel.cpp.o
Linking CXX executable plasmawindowed
Linking CXX shared module plasma_packagestructure_layoutemplate.so
[ 31%] Building CXX object 
libtaskmanager/CMakeFiles/taskmanager.dir/strategies/activitysortingstrategy.cpp.o
[ 32%] Building CXX object 
appmenu/CMakeFiles/kded_appmenu.dir/appmenuadaptor.cpp.o
[ 32%] Built target plasma_packagestructure_layoutemplate
[ 32%] Building CXX object shell/CMakeFiles/plasmashell.dir/panelview.cpp.o
[ 32%] Built target plasmawindowed
[ 32%] Building CXX object 
shell/CMakeFiles/plasmashell.dir/panelconfigview.cpp.o
[ 32%] Building CXX object 
components/shellprivate/CMakeFiles/plasmashellprivateplugin.dir/widgetexplorer/widgetexplorer.cpp.o
:
 In member function ‘void CurrentContainmentActionsModel::showAbout(int)’:
:237:45:
 warning: ‘KAboutData& KAboutData::setProgramIconName(const QString&)’ is 
deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kcoreaddons/inst/include/KF5/KCoreAddons/kaboutdata.h:570)
 [-Wdeprecated-declarations]
 aboutData.setProgramIconName(info.icon());
 ^
[ 32%] Building CXX object 
shell/packageplugins/lookandfeel/CMakeFiles/plasma_packagestructure_lookandfeel.dir/plasma_packagestructure_lookandfeel_automoc.cpp.o
Linking CXX shared module plasma_packagestructure_lookandfeel.so
[ 32%] [ 32%] Building CXX object 
appmenu/CMakeFiles/kded_appmenu.dir/kded_appmenu_automoc.cpp.o
Building CXX object 
libtaskmanager/CMakeFiles/taskmanager.dir/strategies/alphasortingstrategy.cpp.o
[ 32%] Built target plasma_packagestructure_lookandfeel
[ 33%] [ 33%] Building CXX object 
libtaskmanager/CMakeFiles/taskmanager.dir/strategies/desktopsortingstrategy.cpp.o
Building CXX object 
components/shellprivate/CMakeFiles/plasmashellprivateplugin.dir/shellprivateplugin.cpp.o
Scanning dependencies of target plasma_packagestructure_plasmashell
[ 33%] Building CXX object 
shell/packageplugins/shell/CMakeFiles/plasma_packagestructure_plasmashell.dir/shellpackage.cpp.o
Scanning dependencies of target plasma_packagestructure_wallpaper
[ 33%] Building CXX object 
shell/packageplugins/qmlWallpaper/CMakeFiles/plasma_packagestructure_wallpaper.dir/wallpaper.cpp.o
[ 33%] Building CXX object 
shell/packageplugins/qmlWallpaper/CMakeFiles/plasma_packagestructure_wallpaper.dir/plasma_packagestructure_wallpaper_automoc.cpp.o
[ 33%] Building CXX object shell/CMakeFiles/plasmashell.dir/panelshadows.cpp.o
:
 In member function ‘void WidgetExplorerPrivate::initFilters()’:
:123:33:
 warni

Re: Review Request 121533: Register actions for activities management

[Bhushan Shah]

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

(Updated Dec. 15, 2014, 4:15 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


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


Repository: plasma-workspace


Description
---

In Plasma 4 plasma-desktop registered global shortcuts for activities management

Add those actions back


Diffs
-

  shell/shellcorona.h 7c25cd4 
  shell/shellcorona.cpp c416217 

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


Testing
---

all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine


Thanks,

Bhushan Shah

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

Re: Review Request 121533: Register actions for activities management

[Martin Gräßlin]

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

Ship it!


Ship It!

- Martin Gräßlin


On Dec. 15, 2014, 4:41 p.m., Bhushan Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121533/
> ---
> 
> (Updated Dec. 15, 2014, 4:41 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341856
> https://bugs.kde.org/show_bug.cgi?id=341856
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> In Plasma 4 plasma-desktop registered global shortcuts for activities 
> management
> 
> Add those actions back
> 
> 
> Diffs
> -
> 
>   shell/shellcorona.h 7c25cd4 
>   shell/shellcorona.cpp c416217 
> 
> Diff: https://git.reviewboard.kde.org/r/121533/diff/
> 
> 
> Testing
> ---
> 
> all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine
> 
> 
> Thanks,
> 
> Bhushan Shah
> 
>

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

Re: Review Request 121533: Register actions for activities management

[Bhushan Shah]

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



shell/shellcorona.cpp


will remove


- Bhushan Shah


On Dec. 15, 2014, 9:11 p.m., Bhushan Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121533/
> ---
> 
> (Updated Dec. 15, 2014, 9:11 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341856
> https://bugs.kde.org/show_bug.cgi?id=341856
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> In Plasma 4 plasma-desktop registered global shortcuts for activities 
> management
> 
> Add those actions back
> 
> 
> Diffs
> -
> 
>   shell/shellcorona.h 7c25cd4 
>   shell/shellcorona.cpp c416217 
> 
> Diff: https://git.reviewboard.kde.org/r/121533/diff/
> 
> 
> Testing
> ---
> 
> all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine
> 
> 
> Thanks,
> 
> Bhushan Shah
> 
>

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

Re: Review Request 121533: Register actions for activities management

[Bhushan Shah]

> On Dec. 15, 2014, 8:57 p.m., Lukáš Tinkl wrote:
> > shell/shellcorona.cpp, line 1491
> > 
> >
> > Ha? :)

nah


> On Dec. 15, 2014, 8:57 p.m., Lukáš Tinkl wrote:
> > shell/shellcorona.cpp, line 170
> > 
> >
> > You can use KGlobalAccel::setGlobalShortcut() which sets both the 
> > default and active shortcuts, instead of those 2 lines

mgraesslin had better solution


- Bhushan


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


On Dec. 15, 2014, 9:11 p.m., Bhushan Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121533/
> ---
> 
> (Updated Dec. 15, 2014, 9:11 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341856
> https://bugs.kde.org/show_bug.cgi?id=341856
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> In Plasma 4 plasma-desktop registered global shortcuts for activities 
> management
> 
> Add those actions back
> 
> 
> Diffs
> -
> 
>   shell/shellcorona.h 7c25cd4 
>   shell/shellcorona.cpp c416217 
> 
> Diff: https://git.reviewboard.kde.org/r/121533/diff/
> 
> 
> Testing
> ---
> 
> all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine
> 
> 
> Thanks,
> 
> Bhushan Shah
> 
>

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

Re: Review Request 121533: Register actions for activities management

[Bhushan Shah]

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

(Updated Dec. 15, 2014, 9:11 p.m.)


Review request for Plasma.


Changes
---

fix issues


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


Repository: plasma-workspace


Description
---

In Plasma 4 plasma-desktop registered global shortcuts for activities management

Add those actions back


Diffs (updated)
-

  shell/shellcorona.h 7c25cd4 
  shell/shellcorona.cpp c416217 

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


Testing
---

all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine


Thanks,

Bhushan Shah

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

Re: Review Request 121533: Register actions for activities management

[Martin Gräßlin]

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



shell/shellcorona.cpp


too complex: there's a overload taking a QKeySequence:
KGlobalAccel::self()->setGlobalShortcut(activityAction, Qt::META + 
Qt::Key_Q);



shell/shellcorona.cpp


*cough*



shell/shellcorona.cpp


nitpick: const



shell/shellcorona.cpp


nitpick: coding style



shell/shellcorona.cpp


nitpick: const


- Martin Gräßlin


On Dec. 15, 2014, 4:23 p.m., Bhushan Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121533/
> ---
> 
> (Updated Dec. 15, 2014, 4:23 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341856
> https://bugs.kde.org/show_bug.cgi?id=341856
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> In Plasma 4 plasma-desktop registered global shortcuts for activities 
> management
> 
> Add those actions back
> 
> 
> Diffs
> -
> 
>   shell/shellcorona.h 7c25cd4 
>   shell/shellcorona.cpp c416217 
> 
> Diff: https://git.reviewboard.kde.org/r/121533/diff/
> 
> 
> Testing
> ---
> 
> all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine
> 
> 
> Thanks,
> 
> Bhushan Shah
> 
>

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

Re: Review Request 121533: Register actions for activities management

[Lukáš Tinkl]

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



shell/shellcorona.cpp


You can just use:
{QKeySequence(Qt::META + Qt::Key_Q)}



shell/shellcorona.cpp


You can use KGlobalAccel::setGlobalShortcut() which sets both the default 
and active shortcuts, instead of those 2 lines



shell/shellcorona.cpp


Ha? :)



shell/shellcorona.cpp


const



shell/shellcorona.cpp


const


- Lukáš Tinkl


On Pro. 15, 2014, 4:23 odp., Bhushan Shah wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121533/
> ---
> 
> (Updated Pro. 15, 2014, 4:23 odp.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 341856
> https://bugs.kde.org/show_bug.cgi?id=341856
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> In Plasma 4 plasma-desktop registered global shortcuts for activities 
> management
> 
> Add those actions back
> 
> 
> Diffs
> -
> 
>   shell/shellcorona.h 7c25cd4 
>   shell/shellcorona.cpp c416217 
> 
> Diff: https://git.reviewboard.kde.org/r/121533/diff/
> 
> 
> Testing
> ---
> 
> all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine
> 
> 
> Thanks,
> 
> Bhushan Shah
> 
>

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

Re: Review Request 121533: Register actions for activities management

[Bhushan Shah]

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

(Updated Dec. 15, 2014, 8:53 p.m.)


Review request for Plasma.


Changes
---

use setGlobalShortcut


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


Repository: plasma-workspace


Description
---

In Plasma 4 plasma-desktop registered global shortcuts for activities management

Add those actions back


Diffs (updated)
-

  shell/shellcorona.h 7c25cd4 
  shell/shellcorona.cpp c416217 

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


Testing
---

all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine


Thanks,

Bhushan Shah

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

Review Request 121533: Register actions for activities management

[Bhushan Shah]

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

Review request for Plasma.


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


Repository: plasma-workspace


Description
---

In Plasma 4 plasma-desktop registered global shortcuts for activities management

Add those actions back


Diffs
-

  shell/shellcorona.h 7c25cd4 
  shell/shellcorona.cpp c416217 

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


Testing
---

all shortcuts, Meta + Q, Meta + Tab and Meta + Shift + Tab works fine


Thanks,

Bhushan Shah

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[David Edmundson]

> On Dec. 15, 2014, 1:39 p.m., David Edmundson wrote:
> > ksmserver/screenlocker/greeter/greeterapp.cpp, line 428
> > 
> >
> > AFAIK you don't need to pass "this" in the [] when you have "this" as 
> > the receiver for the slot.
> 
> Martin Gräßlin wrote:
> I think you are wrong:
> > 
> /home/martin/src/kf5/kde/workspace/plasma-workspace/ksmserver/screenlocker/greeter/greeterapp.cpp:432:13:
>  error: ‘this’ was not captured for this lambda function

oh, because I normally do [] which captures the entire stack. I was 
misunderstanding things sorry.


- David


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


On Dec. 15, 2014, 9:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated Dec. 15, 2014, 9:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[Martin Gräßlin]

> On Dec. 15, 2014, 2:39 p.m., David Edmundson wrote:
> > ksmserver/screenlocker/greeter/greeterapp.cpp, line 428
> > 
> >
> > AFAIK you don't need to pass "this" in the [] when you have "this" as 
> > the receiver for the slot.

I think you are wrong:
> /home/martin/src/kf5/kde/workspace/plasma-workspace/ksmserver/screenlocker/greeter/greeterapp.cpp:432:13:
>  error: ‘this’ was not captured for this lambda function


- Martin


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


On Dec. 15, 2014, 10:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated Dec. 15, 2014, 10:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[Martin Gräßlin]

> On Dec. 15, 2014, 2:39 p.m., David Edmundson wrote:
> > So basically we have a named pipe and we we pass back the wID of the lock 
> > screen to ksld?
> > 
> > I'm not sure what benefit we have from using Wayland as the protocol as 
> > opposed to a private p2p DBus session or just writing it out as a simple 
> > integer on a socket..but I can't see any harm either.
> > 
> > +1

> So basically we have a named pipe and we we pass back the wID of the lock 
> screen to ksld?

yes

> I'm not sure what benefit we have from using Wayland as the protocol as 
> opposed to a private p2p DBus session or just writing it out as a simple 
> integer on a socket..but I can't see any harm either.

one of the reasons is that I want to extend it to support more. E.g. with the 
protocol in place we can move the authentication to ksld. This makes integer on 
a socket a non-solution. Also we would have to add all the security like proper 
parsing whether it's an integer and so onl Concerning p2p DBus: I do not see a 
way on how one could pass the connection and ensure no other client connects to 
it except the expected one. This is possible in the KWayland case - you can see 
that there are validations in several places.


> On Dec. 15, 2014, 2:39 p.m., David Edmundson wrote:
> > ksmserver/screenlocker/waylandserver.cpp, line 44
> > 
> >
> > FYI you end up calling this twice. Though it doesn't seem like that 
> > will cause a problem.

I just added it in the dtor as a safety measure and stop is deliberately 
implemented in a way that it doesn't matter.


- Martin


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


On Dec. 15, 2014, 10:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated Dec. 15, 2014, 10:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[David Edmundson]

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


So basically we have a named pipe and we we pass back the wID of the lock 
screen to ksld?

I'm not sure what benefit we have from using Wayland as the protocol as opposed 
to a private p2p DBus session or just writing it out as a simple integer on a 
socket..but I can't see any harm either.

+1


ksmserver/screenlocker/greeter/greeterapp.cpp


AFAIK you don't need to pass "this" in the [] when you have "this" as the 
receiver for the slot.



ksmserver/screenlocker/waylandserver.cpp


FYI you end up calling this twice. Though it doesn't seem like that will 
cause a problem.


- David Edmundson


On Dec. 15, 2014, 9:29 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121429/
> ---
> 
> (Updated Dec. 15, 2014, 9:29 a.m.)
> 
> 
> Review request for Plasma, Àlex Fiestas and David Edmundson.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> The screenlocker_greet needs to tell the parent ksld process which
> windows it created. Ksld sends input events to these windows. So
> far this was based on an X property on the window. Unfortunately
> ksld didn't validate whether the windows tagged with this property
> belong to the screenlocker_greet process it started.
> 
> With this change the communication for announcing windows is moved
> away from the X11 protocol and instead a custom Wayland protocol is
> used.
> 
> Ksld starts a KWaylandServer when the greet process gets started. It
> creates anonymous unix sockets for the connection and passes one
> filedescriptor to the started greeter process.
> 
> The check for the X property is removed in ksld and instead only
> windows ids passed through the Wayland socket connection are
> accepted.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/lockwindow.h 
> 9938d201269c89a24c9c0bd6275aa5f731bb5535 
>   ksmserver/screenlocker/lockwindow.cpp 
> 3aa963a59e21636862f5ca59e220bbea3bd41ff9 
>   ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.h PRE-CREATION 
>   ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
>   ksmserver/screenlocker/greeter/greeterapp.h 
> b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 
> 30d1821bdba38028959f3457e900a1b32e628192 
>   ksmserver/screenlocker/greeter/main.cpp 
> 12e570107d0cba851b8978131d730b27924529bb 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 
> 10c473488f08354096f68784b9240392a444af5f 
> 
> Diff: https://git.reviewboard.kde.org/r/121429/diff/
> 
> 
> Testing
> ---
> 
> Running ksmserver with the patch. Lock/unlock working, my exploit is failing.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121472: Override plasmoid size to zero rather than one

[Kai Uwe Broulik]

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

(Updated Dec. 15, 2014, 1:36 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma and Xuetian Weng.


Repository: plasma-workspace


Description
---

This sets the size of an applet to 0 rather than 1 to avoid the plasmoid 
rendering a tiny svg which is then upscaled and re-rendered later.


Diffs
-

  applets/systemtray/plugin/protocols/plasmoid/plasmoidtask.cpp 071705a 

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


Testing
---

Together with Review 121219 systray works without blurry icons. I don't know 
whether that magic number 1 has a deeper legacy, though.


Thanks,

Kai Uwe Broulik

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

Re: Review Request 121294: Improve wallpaper sourceSize handling

[Kai Uwe Broulik]

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

(Updated Dec. 15, 2014, 1:36 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

Do not bind the image's sourceSize to the root item's size since that will 
reload the image whenever the size changes. This is especially noticeable in 
plasmoidviewer where resizing the window causes the background to go black 
momentarily.

This makes it wait 1s before actually changing the source size, preventing 
continuous reloading when resizing the window but should also improve 
resolution changes. Also, it waits for the size to become non-zero before 
loading the image. Setting a sourceSize of (0,0) is equivalent to not setting 
it at all, causing it to load the full image, just to reload it in the proper 
size afterwards.

There's still an issue that the view starts up with a size of 1024x768, loads 
the wallpaper, and then resizes itself to the screen geometry, causing a 
delayed reload of the image which was previously not visible but together with 
me waiting for the size to become available you can see that on plasmashell 
startup, when using eg. the tiled fill mode.

Unrelated:
 - Move the swap image stuff into a separate function
 - Use my animate binding trick for fillMode change too, now these are lag-free 
also


Diffs
-

  wallpapers/image/imagepackage/contents/ui/main.qml 1f11795 

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


Testing
---

Plasmoidviewer is much prettier to use now, no flickering, Plasmashell startup 
is a bit more nasty imho (especially when using a wallpaper background color) 
but should be concealed by ksplash. Switching between wallpapers and fillmodes 
is smooth, it fades from black when changing a wallpaper and fillmode at the 
same time but afaics that has been the case previously, too.


Thanks,

Kai Uwe Broulik

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

Feedback on xdg-shell from Plasma crew

[Martin Gräßlin]

Hi all,

I had a look at the xdg-shell proposal in weston (see [1]) and want to provide 
some feedback from a Plasma/KWin point of view.

First of all: thanks for the work so far on the xdg-shell. The work looks 
quite good and promising. If you reply to the thread, please keep both the 
plasma and wayland mailing list on CC: not all domain experts from Plasma are 
on the wayland mailing list and I don't want to play proxy with my peer 
developers ;-)

I'm grouping the feedback by some categories.

Decorations
---

My understanding is that xdg-shell surfaces are supposed to do client-side-
decorations. If that is the case I consider the protocol as not yet sufficient 
for our needs. It would render huge regressions as several features are no 
longer possible. This includes:
* putting windows on all desktops
* putting a window to a keep above/keep below layer
* shading windows (personally I don't mind if that goes away)

For those three we have dedicated decoration buttons which can be globally 
configured. We would like to still be able to provide them.

In addition there are quite some interaction limitations:
* configurable mouse actions: a right click might not trigger a context menu, 
mouse wheel support
* multiple and configurable mode on the maximize button: KWin allows to 
maximize horizontally/vertically and fully depending which mouse button was 
used on the maximize button

Also for integration with the desktop environment I see problems:
* how to specify the button order? We don't want apps to do things like Opera 
did: putting the buttons on the wrong side ;-)
* specifying a drag delay to trigger move/resize (or better pass this into the 
compositor?)

In general I fear that in the current state it would render a for us rather 
unsuitable system exposing the same problems as GTK's CSD in the X11 world.

Convergence


One of our convergence features is that we adjust the window controls. E.g.
* on Active/Touch no window has controls
* on Netbook only dialogs have controls, while all other windows have no 
controls
* On Desktop the user is allowed to decide per window whether a window should 
have controls

I'm not completely sure on how to provide this. I'd say that this should be 
another state to tell the surface whether it should render controls. Also the 
client should tell whether it's currently rendering controls to prevent that a 
desktop shell exposes further controls for a client using own controls.

General Comments


* set_app_id: What's meant with "It should be the ID that appears in the new 
desktop entry specification, the interface name."? Especially what's the "new 
desktop entry specification"?

* set_window_geometry: this looks like an insufficient solution to us. Drop 
shadows should not be part of the window. In KWin/Plasma we have shadows in a 
dedicated buffer which can get highly compressed and doesn't require to have 
complicated logics to map the windows. Supporting this creates problems for 
things like thumbnails where we want to exclude shadows to be able to produce 
higher quality thumbnails. Also of course snapping and etc.

* why a specific unset_maximized request? Wouldn't it be better to just have 
one maximized request with enum values (maximized horizontally, maximized 
vertically, maximized fully, restored?)

* for all state changes like set_maximized or set_fullscreen I suggest to add 
the serial which triggered the change. By that I'm assuming that a surface is 
only allowed to change state when a user interacted with the window.

* icon? For the task manager we need a way to get an icon. This could be 
either a surface (e.g. allow animated icons) or just a name of the icon theme 
item. We have many applications changing the icon while interacting (e.g. a 
chat application indicating that the remote is typing) and thus a general icon 
is not sufficient.

* show_window_menu: it's lacking some of the feedback we gathered on the NETWM 
mailing list. E.g. if it's from a menu button it should provide the geometry 
of the button to provide a good interaction

* set_parent: what is the use case? Is that supposed to be a dialog? If yes: 
why is it restricting on how a desktop environment is supposed to handle them?

* what about semantic window types: we would like to know what a surface is. 
Is it a dialog? Is it a tooltip, etc. etc. I think this is one of the strong 
points of NETWM and completely missing here.

* a mechanismn like startup notification/_NET_WM_USER_TIME: a compositor would 
probably want to know when a surface got created due to user interaction for 
focus stealing prevention

Best Regards
Martin Gräßlin

[1] weston/protocol/xdg-shell.xml as of 
b502654b9fd9263964ccc4bdcbd8d633233b4f87

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: Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

[Martin Gräßlin]

> On Dec. 15, 2014, 2:01 p.m., Lukáš Tinkl wrote:
> > Solid:Powermanagement has a signal resumingfromSuspend(), conversely, we 
> > could add a backend-independent signal goingToSleep() which ScreenLocker 
> > could connect to.

so we could connent to the resumingFromSuspend for the non-logind backends. 
That would work...


- Martin


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


On Dec. 15, 2014, 11:18 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119814/
> ---
> 
> (Updated Dec. 15, 2014, 11:18 a.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [ksld] ScreenLocker inhibits sleep on logind
> 
> When the system is going to sleep we want to ensure that the screen gets
> locked before the system goes to sleep. Logind provides the inhibitor
> locks which can be used for this.
> 
> If logind is available ksld gains an inhibitor lock for sleep when the
> screen is unlocked. As soon as the screen gets locked the inhibitor lock
> is released. In addition it connects to the prepareForSleep signal by
> logind and locks the screen.
> 
> The solution needs to be extended to have a config option whether the
> screen should be locked on sleep. Currently this is provided by
> powerdevil. Also the solution can only work properly if power devil uses
> logind's sleep dbus interface.
> 
> [ksld] Don't block till the greeter is started
> 
> We only want to ensure that the greeter gets started. There is no
> need to block for that. Instead we can connect to the error signal
> and unlock in case the greeter failed to start.
> 
> 
> -
> @Alex: what do you think is the best solution for handling the "lock screen 
> on resume" config option? My idea would be to move it to screen locker and 
> expose the value through DBus, so that powerdevil can still read it.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/autotests/CMakeLists.txt 
> 4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
>   ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 
> a0253d687150702aa4c22200d9f6a577d0cab6be 
>   ksmserver/screenlocker/kcm/kcm.ui 8f8654b5fe34b8e4bfd95f652659a59c6c664a55 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
>   ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 
> 
> Diff: https://git.reviewboard.kde.org/r/119814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

[Lukáš Tinkl]

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


Solid:Powermanagement has a signal resumingfromSuspend(), conversely, we could 
add a backend-independent signal goingToSleep() which ScreenLocker could 
connect to.

- Lukáš Tinkl


On Pro. 15, 2014, 11:18 dop., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119814/
> ---
> 
> (Updated Pro. 15, 2014, 11:18 dop.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [ksld] ScreenLocker inhibits sleep on logind
> 
> When the system is going to sleep we want to ensure that the screen gets
> locked before the system goes to sleep. Logind provides the inhibitor
> locks which can be used for this.
> 
> If logind is available ksld gains an inhibitor lock for sleep when the
> screen is unlocked. As soon as the screen gets locked the inhibitor lock
> is released. In addition it connects to the prepareForSleep signal by
> logind and locks the screen.
> 
> The solution needs to be extended to have a config option whether the
> screen should be locked on sleep. Currently this is provided by
> powerdevil. Also the solution can only work properly if power devil uses
> logind's sleep dbus interface.
> 
> [ksld] Don't block till the greeter is started
> 
> We only want to ensure that the greeter gets started. There is no
> need to block for that. Instead we can connect to the error signal
> and unlock in case the greeter failed to start.
> 
> 
> -
> @Alex: what do you think is the best solution for handling the "lock screen 
> on resume" config option? My idea would be to move it to screen locker and 
> expose the value through DBus, so that powerdevil can still read it.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/autotests/CMakeLists.txt 
> 4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
>   ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 
> a0253d687150702aa4c22200d9f6a577d0cab6be 
>   ksmserver/screenlocker/kcm/kcm.ui 8f8654b5fe34b8e4bfd95f652659a59c6c664a55 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
>   ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 
> 
> Diff: https://git.reviewboard.kde.org/r/119814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121360: Rework Plasma's notification positioning code

[Emmanuel Pescosta]

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


Maybe a QReadWriteLock instead of a QMutex to make the locking a little bit 
more finer granulated?


applets/notifications/plugin/notificationshelper.cpp


Needs locking



applets/notifications/plugin/notificationshelper.cpp


Needs locking



applets/notifications/plugin/notificationshelper.cpp


unlock immediately after m_hideQueue.takeFirst()



applets/notifications/plugin/notificationshelper.cpp


No need to check it again and also a lock is missing if you want to keep it.



applets/notifications/plugin/notificationshelper.cpp


No need to check it again and also a lock is missing if you want to keep it.



applets/notifications/plugin/notificationshelper.cpp


No need for toString() conversion, just compare those two QVariants. + const



applets/notifications/plugin/notificationshelper.cpp


Please make use of QMutableListIterator



applets/notifications/plugin/notificationshelper.cpp


Removing from m_queue also has to be locked, so move it before the Q_FOREACH


- Emmanuel Pescosta


On Dec. 5, 2014, 8:01 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121360/
> ---
> 
> (Updated Dec. 5, 2014, 8:01 p.m.)
> 
> 
> Review request for Plasma and Kai Uwe Broulik.
> 
> 
> Bugs: 339732
> https://bugs.kde.org/show_bug.cgi?id=339732
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> There can easily be situations where the popups could overlap one another or 
> result in strange animations. This patch rewrites the notifications so that 
> all actions such as show/reposition/hide are handled from a one single place 
> and every action is properly queued and protected around, which makes it more 
> robust, more predictive and less chaotic. There's also a slight delay between 
> every action so it's also visually much more cleaner and easier to see what's 
> going on. 
> 
> 
> Diffs
> -
> 
>   applets/notifications/package/contents/ui/NotificationPopup.qml c99bf21 
>   applets/notifications/plugin/notificationshelper.h af8f6fa 
>   applets/notifications/plugin/notificationshelper.cpp 425f0d6 
> 
> Diff: https://git.reviewboard.kde.org/r/121360/diff/
> 
> 
> Testing
> ---
> 
> Tested whole day plus stress-tested with something like for i in {1..200}; do 
> notify-send "$i - $RANDOM" "$RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
> sodifgj asodfgnsdlfgdf g"; done executed from 4 terminals at once, all works 
> fine and as expected.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 121294: Improve wallpaper sourceSize handling

[Marco Martin]

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

Ship it!


Ship It!

- Marco Martin


On Dec. 4, 2014, 9:16 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121294/
> ---
> 
> (Updated Dec. 4, 2014, 9:16 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Do not bind the image's sourceSize to the root item's size since that will 
> reload the image whenever the size changes. This is especially noticeable in 
> plasmoidviewer where resizing the window causes the background to go black 
> momentarily.
> 
> This makes it wait 1s before actually changing the source size, preventing 
> continuous reloading when resizing the window but should also improve 
> resolution changes. Also, it waits for the size to become non-zero before 
> loading the image. Setting a sourceSize of (0,0) is equivalent to not setting 
> it at all, causing it to load the full image, just to reload it in the proper 
> size afterwards.
> 
> There's still an issue that the view starts up with a size of 1024x768, loads 
> the wallpaper, and then resizes itself to the screen geometry, causing a 
> delayed reload of the image which was previously not visible but together 
> with me waiting for the size to become available you can see that on 
> plasmashell startup, when using eg. the tiled fill mode.
> 
> Unrelated:
>  - Move the swap image stuff into a separate function
>  - Use my animate binding trick for fillMode change too, now these are 
> lag-free also
> 
> 
> Diffs
> -
> 
>   wallpapers/image/imagepackage/contents/ui/main.qml 1f11795 
> 
> Diff: https://git.reviewboard.kde.org/r/121294/diff/
> 
> 
> Testing
> ---
> 
> Plasmoidviewer is much prettier to use now, no flickering, Plasmashell 
> startup is a bit more nasty imho (especially when using a wallpaper 
> background color) but should be concealed by ksplash. Switching between 
> wallpapers and fillmodes is smooth, it fades from black when changing a 
> wallpaper and fillmode at the same time but afaics that has been the case 
> previously, too.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 121472: Override plasmoid size to zero rather than one

[Sebastian Kügler]

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

Ship it!


Ship It!

- Sebastian Kügler


On Dec. 13, 2014, 12:16 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121472/
> ---
> 
> (Updated Dec. 13, 2014, 12:16 a.m.)
> 
> 
> Review request for Plasma and Xuetian Weng.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> This sets the size of an applet to 0 rather than 1 to avoid the plasmoid 
> rendering a tiny svg which is then upscaled and re-rendered later.
> 
> 
> Diffs
> -
> 
>   applets/systemtray/plugin/protocols/plasmoid/plasmoidtask.cpp 071705a 
> 
> Diff: https://git.reviewboard.kde.org/r/121472/diff/
> 
> 
> Testing
> ---
> 
> Together with Review 121219 systray works without blurry icons. I don't know 
> whether that magic number 1 has a deeper legacy, though.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Minutes Monday Plasma hangout

[Sebastian Kügler]

15th December, 2014

We'll skip the Monday hangout on the 29th.


Present:  David, Jens, Aleix, Kai Uwe, Marco, Martin G., Martin K., Vishesh, 
Sebastian

David:
- Resizing issue in IconItem
- Performance issue in date/time engine fixed
- Performance improved in Plasma::Svg

Jens:
- Working on application design
- Would like code snippets for application design patterns

Kai Uwe:
- Fixes in battery and brightness handling
- Turn off backlight when brightness is 0 ( 
https://git.reviewboard.kde.org/r/121506/ )
- Improve UX with brightness OSD ( https://git.reviewboard.kde.org/r/121507/ )
- OSD windowtype to be merged (hopefully)

Marco:
- Progress on plotter (this is a missing component after 4.x -> 5.x)
- Fixing bugs for 5.2.0
- Working on KPackage frameworkification

Aleix:
- Working on kdepimlibs splitting, unlocking dependencies
- Makes KPeople releasable
- To remove copy of KXmlRpcClient in drkonqi
- More PIM meeting today at 3:00 CET to resolve more splitting issues

Martin G:
- Merged KDecoration2
- Started integrating KWaylandServer into screenlocker
- Working on moving decoration rendering into its own thread (5.3 material)
- Working on feedback for xdg-shell proposal, sending it to the wayland list

Martin K:
- Pondering https://git.reviewboard.kde.org/r/121529/diff/# -> likely no, it 
carries no added value
- Porting KTP currently, good progress

Vishesh:
- Working on apps right now

Sebastian:
- Mostly bugfixing
- Looking into 5.4 WebEngine



-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 121529: Let others know that we support persistent notifications

[Jan Grulich]

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

(Updated Pro. 15, 2014, 12:02 odp.)


Status
--

This change has been discarded.


Review request for Plasma and Martin Klapetek.


Repository: plasma-workspace


Description
---

According to our implementation of org.freedesktop.Notifications we don't 
support persistent notifications, which is not true. This patch adds 
"persistence" keyword to the list of capabilities.

See https://developer.gnome.org/notification-spec/#id2825605.


Diffs
-

  dataengines/notifications/notificationsengine.cpp d4b7f19 

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


Testing
---


Thanks,

Jan Grulich

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

Re: Review Request 121360: Rework Plasma's notification positioning code

[Martin Klapetek]

> On Dec. 5, 2014, 8:19 p.m., Martin Gräßlin wrote:
> > I'm a little bit concerned about the mutex usage. I somehow don't see where 
> > this could be threaded. If it's using threads due to the rendering, then 
> > it's important that you create it as a QMutex::Recursive mutex as otherwise 
> > on single-threaded renderers (all non-NVIDIA) it could dead-lock.

I'm not 100% sure either, but I was observing strange issues and really a 
concurrency issues, they all went out when I put the mutexes there.

I'll change to Recursive.


- Martin


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


On Dec. 5, 2014, 8:01 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121360/
> ---
> 
> (Updated Dec. 5, 2014, 8:01 p.m.)
> 
> 
> Review request for Plasma and Kai Uwe Broulik.
> 
> 
> Bugs: 339732
> https://bugs.kde.org/show_bug.cgi?id=339732
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> There can easily be situations where the popups could overlap one another or 
> result in strange animations. This patch rewrites the notifications so that 
> all actions such as show/reposition/hide are handled from a one single place 
> and every action is properly queued and protected around, which makes it more 
> robust, more predictive and less chaotic. There's also a slight delay between 
> every action so it's also visually much more cleaner and easier to see what's 
> going on. 
> 
> 
> Diffs
> -
> 
>   applets/notifications/package/contents/ui/NotificationPopup.qml c99bf21 
>   applets/notifications/plugin/notificationshelper.h af8f6fa 
>   applets/notifications/plugin/notificationshelper.cpp 425f0d6 
> 
> Diff: https://git.reviewboard.kde.org/r/121360/diff/
> 
> 
> Testing
> ---
> 
> Tested whole day plus stress-tested with something like for i in {1..200}; do 
> notify-send "$i - $RANDOM" "$RANDOM sdf sdf sdfwefhsdjfnskdfbkwefnos igodsfgn 
> sodifgj asodfgnsdlfgdf g"; done executed from 4 terminals at once, all works 
> fine and as expected.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

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

Re: Review Request 121530: Remove lock screen on suspend

[Martin Gräßlin]

> On Dec. 15, 2014, 11:55 a.m., Kai Uwe Broulik wrote:
> > daemon/actions/bundled/suspendsession.cpp, line 112
> > 
> >
> > It is not guaranteed that the backend actually uses logind.
> > 
> > Backend could be
> > - PowerDevilHALBackend, which doesn't support that
> > - PowerDevilUPowerBackend which uses logind only if available and 
> > systemd version >= 195
> > 
> > So perhaps it should become possible to query the backend in advance 
> > whether it supports logind and lock manually if not.
> 
> Martin Gräßlin wrote:
> or we declare lock screen on suspend as unsupported on non-logind.

to add to that: there is nothing wrong with having a sufficient interface for 
the other modes which ksld could connect to. I'd prefer to have everything in 
ksld instead of two places.


- Martin


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


On Dec. 15, 2014, 11:45 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121530/
> ---
> 
> (Updated Dec. 15, 2014, 11:45 a.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> This is handled internally in the screenlocker daemon using logind.
> It requires that powerdevil is supending through logind, though.
> 
> 
> Diffs
> -
> 
>   daemon/actions/bundled/suspendsession.h 
> 0c319f266ecfe6e712abe436e7891298d853c592 
>   daemon/actions/bundled/suspendsession.cpp 
> 7308b7e7b797438aa5e772924af0014ddc8067cd 
>   kcmodule/global/GeneralPage.cpp 1f56a6a4aa350b18bfea082c99964671154c1c31 
>   kcmodule/global/generalPage.ui 780b701b580ea71d1218632b0596ad947576384d 
>   PowerDevilSettings.kcfg cd103c6d8da47be210b954e324bec3fc3fae5467 
> 
> Diff: https://git.reviewboard.kde.org/r/121530/diff/
> 
> 
> Testing
> ---
> 
> it compiles. I'm not familiar enough with powerdevil to know whether this is 
> correct.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121530: Remove lock screen on suspend

[Martin Gräßlin]

> On Dec. 15, 2014, 11:55 a.m., Kai Uwe Broulik wrote:
> > daemon/actions/bundled/suspendsession.cpp, line 112
> > 
> >
> > It is not guaranteed that the backend actually uses logind.
> > 
> > Backend could be
> > - PowerDevilHALBackend, which doesn't support that
> > - PowerDevilUPowerBackend which uses logind only if available and 
> > systemd version >= 195
> > 
> > So perhaps it should become possible to query the backend in advance 
> > whether it supports logind and lock manually if not.

or we declare lock screen on suspend as unsupported on non-logind.


- Martin


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


On Dec. 15, 2014, 11:45 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121530/
> ---
> 
> (Updated Dec. 15, 2014, 11:45 a.m.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> This is handled internally in the screenlocker daemon using logind.
> It requires that powerdevil is supending through logind, though.
> 
> 
> Diffs
> -
> 
>   daemon/actions/bundled/suspendsession.h 
> 0c319f266ecfe6e712abe436e7891298d853c592 
>   daemon/actions/bundled/suspendsession.cpp 
> 7308b7e7b797438aa5e772924af0014ddc8067cd 
>   kcmodule/global/GeneralPage.cpp 1f56a6a4aa350b18bfea082c99964671154c1c31 
>   kcmodule/global/generalPage.ui 780b701b580ea71d1218632b0596ad947576384d 
>   PowerDevilSettings.kcfg cd103c6d8da47be210b954e324bec3fc3fae5467 
> 
> Diff: https://git.reviewboard.kde.org/r/121530/diff/
> 
> 
> Testing
> ---
> 
> it compiles. I'm not familiar enough with powerdevil to know whether this is 
> correct.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 121530: Remove lock screen on suspend

[Kai Uwe Broulik]

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



daemon/actions/bundled/suspendsession.cpp


It is not guaranteed that the backend actually uses logind.

Backend could be
- PowerDevilHALBackend, which doesn't support that
- PowerDevilUPowerBackend which uses logind only if available and systemd 
version >= 195

So perhaps it should become possible to query the backend in advance 
whether it supports logind and lock manually if not.


- Kai Uwe Broulik


On Dez. 15, 2014, 10:45 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121530/
> ---
> 
> (Updated Dez. 15, 2014, 10:45 vorm.)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> This is handled internally in the screenlocker daemon using logind.
> It requires that powerdevil is supending through logind, though.
> 
> 
> Diffs
> -
> 
>   daemon/actions/bundled/suspendsession.h 
> 0c319f266ecfe6e712abe436e7891298d853c592 
>   daemon/actions/bundled/suspendsession.cpp 
> 7308b7e7b797438aa5e772924af0014ddc8067cd 
>   kcmodule/global/GeneralPage.cpp 1f56a6a4aa350b18bfea082c99964671154c1c31 
>   kcmodule/global/generalPage.ui 780b701b580ea71d1218632b0596ad947576384d 
>   PowerDevilSettings.kcfg cd103c6d8da47be210b954e324bec3fc3fae5467 
> 
> Diff: https://git.reviewboard.kde.org/r/121530/diff/
> 
> 
> Testing
> ---
> 
> it compiles. I'm not familiar enough with powerdevil to know whether this is 
> correct.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

[Martin Gräßlin]

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


https://git.reviewboard.kde.org/r/121530/ handles removal of the option from 
powerdevil

- Martin Gräßlin


On Dec. 15, 2014, 11:18 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119814/
> ---
> 
> (Updated Dec. 15, 2014, 11:18 a.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [ksld] ScreenLocker inhibits sleep on logind
> 
> When the system is going to sleep we want to ensure that the screen gets
> locked before the system goes to sleep. Logind provides the inhibitor
> locks which can be used for this.
> 
> If logind is available ksld gains an inhibitor lock for sleep when the
> screen is unlocked. As soon as the screen gets locked the inhibitor lock
> is released. In addition it connects to the prepareForSleep signal by
> logind and locks the screen.
> 
> The solution needs to be extended to have a config option whether the
> screen should be locked on sleep. Currently this is provided by
> powerdevil. Also the solution can only work properly if power devil uses
> logind's sleep dbus interface.
> 
> [ksld] Don't block till the greeter is started
> 
> We only want to ensure that the greeter gets started. There is no
> need to block for that. Instead we can connect to the error signal
> and unlock in case the greeter failed to start.
> 
> 
> -
> @Alex: what do you think is the best solution for handling the "lock screen 
> on resume" config option? My idea would be to move it to screen locker and 
> expose the value through DBus, so that powerdevil can still read it.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/autotests/CMakeLists.txt 
> 4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
>   ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 
> a0253d687150702aa4c22200d9f6a577d0cab6be 
>   ksmserver/screenlocker/kcm/kcm.ui 8f8654b5fe34b8e4bfd95f652659a59c6c664a55 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
>   ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
>   ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 
> 
> Diff: https://git.reviewboard.kde.org/r/119814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Review Request 121530: Remove lock screen on suspend

[Martin Gräßlin]

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

Review request for Plasma and Solid.


Repository: powerdevil


Description
---

This is handled internally in the screenlocker daemon using logind.
It requires that powerdevil is supending through logind, though.


Diffs
-

  daemon/actions/bundled/suspendsession.h 
0c319f266ecfe6e712abe436e7891298d853c592 
  daemon/actions/bundled/suspendsession.cpp 
7308b7e7b797438aa5e772924af0014ddc8067cd 
  kcmodule/global/GeneralPage.cpp 1f56a6a4aa350b18bfea082c99964671154c1c31 
  kcmodule/global/generalPage.ui 780b701b580ea71d1218632b0596ad947576384d 
  PowerDevilSettings.kcfg cd103c6d8da47be210b954e324bec3fc3fae5467 

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


Testing
---

it compiles. I'm not familiar enough with powerdevil to know whether this is 
correct.


Thanks,

Martin Gräßlin

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

Re: Review Request 121529: Let others know that we support persistent notifications

[Martin Klapetek]

> On Dec. 15, 2014, 10:59 a.m., Martin Klapetek wrote:
> > This spec is however gnome's own extension of the original spec, which has 
> > no such stuff. Is there an actual use case why this would be needed?
> > 
> > More general question - should we be implementing their extensions?
> 
> Jan Grulich wrote:
> A guy from RedHat working on ABRT asked me today if we support persistent 
> notifications, he was looking at org.freedesktop.Notifications and checking 
> if there is "persistence" keyword in supported capabilities.
> 
> I don't see anything wrong on implementing their extensions, in this case 
> it could be useful.

Personally I find it quite odd to have that in the capabilities, because the 
spec itself actually has the concept of "persistence" in the basic principles, 
so the client implementing the interface _must_ have support for persistent 
notifications, in some way.

As for implmenting a 3rd party extensions, this one specifically...I for one 
dislike the way they are handling it with in the typical Gnome fashion - "we do 
our own thing, don't care about the others, you all succumb to our doings". It 
could have continued being part of the cross-desktop galago spec but this 
wayI'll raise this on the meeting today to get a general opinion on it.


- Martin


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


On Dec. 15, 2014, 10:37 a.m., Jan Grulich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121529/
> ---
> 
> (Updated Dec. 15, 2014, 10:37 a.m.)
> 
> 
> Review request for Plasma and Martin Klapetek.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> According to our implementation of org.freedesktop.Notifications we don't 
> support persistent notifications, which is not true. This patch adds 
> "persistence" keyword to the list of capabilities.
> 
> See https://developer.gnome.org/notification-spec/#id2825605.
> 
> 
> Diffs
> -
> 
>   dataengines/notifications/notificationsengine.cpp d4b7f19 
> 
> Diff: https://git.reviewboard.kde.org/r/121529/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jan Grulich
> 
>

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

Re: Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

[Martin Gräßlin]

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

(Updated Dec. 15, 2014, 11:18 a.m.)


Review request for Plasma and Àlex Fiestas.


Changes
---

* rebased on current master
* added config option for "lock screen on resume"


Repository: plasma-workspace


Description
---

[ksld] ScreenLocker inhibits sleep on logind

When the system is going to sleep we want to ensure that the screen gets
locked before the system goes to sleep. Logind provides the inhibitor
locks which can be used for this.

If logind is available ksld gains an inhibitor lock for sleep when the
screen is unlocked. As soon as the screen gets locked the inhibitor lock
is released. In addition it connects to the prepareForSleep signal by
logind and locks the screen.

The solution needs to be extended to have a config option whether the
screen should be locked on sleep. Currently this is provided by
powerdevil. Also the solution can only work properly if power devil uses
logind's sleep dbus interface.

[ksld] Don't block till the greeter is started

We only want to ensure that the greeter gets started. There is no
need to block for that. Instead we can connect to the error signal
and unlock in case the greeter failed to start.


-
@Alex: what do you think is the best solution for handling the "lock screen on 
resume" config option? My idea would be to move it to screen locker and expose 
the value through DBus, so that powerdevil can still read it.


Diffs (updated)
-

  ksmserver/screenlocker/CMakeLists.txt 
5378a10df2be70cee95b5612c23046eae639f610 
  ksmserver/screenlocker/autotests/CMakeLists.txt 
4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
  ksmserver/screenlocker/kcfg/kscreenlockersettings.kcfg 
a0253d687150702aa4c22200d9f6a577d0cab6be 
  ksmserver/screenlocker/kcm/kcm.ui 8f8654b5fe34b8e4bfd95f652659a59c6c664a55 
  ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
  ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
  ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
  ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 

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


Testing
---


Thanks,

Martin Gräßlin

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

Re: Review Request 121529: Let others know that we support persistent notifications

[Jan Grulich]

> On Pro. 15, 2014, 9:59 dop., Martin Klapetek wrote:
> > This spec is however gnome's own extension of the original spec, which has 
> > no such stuff. Is there an actual use case why this would be needed?
> > 
> > More general question - should we be implementing their extensions?

A guy from RedHat working on ABRT asked me today if we support persistent 
notifications, he was looking at org.freedesktop.Notifications and checking if 
there is "persistence" keyword in supported capabilities.

I don't see anything wrong on implementing their extensions, in this case it 
could be useful.


- Jan


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


On Pro. 15, 2014, 9:37 dop., Jan Grulich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121529/
> ---
> 
> (Updated Pro. 15, 2014, 9:37 dop.)
> 
> 
> Review request for Plasma and Martin Klapetek.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> According to our implementation of org.freedesktop.Notifications we don't 
> support persistent notifications, which is not true. This patch adds 
> "persistence" keyword to the list of capabilities.
> 
> See https://developer.gnome.org/notification-spec/#id2825605.
> 
> 
> Diffs
> -
> 
>   dataengines/notifications/notificationsengine.cpp d4b7f19 
> 
> Diff: https://git.reviewboard.kde.org/r/121529/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jan Grulich
> 
>

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

Re: Review Request 121529: Let others know that we support persistent notifications

[Martin Klapetek]

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


This spec is however gnome's own extension of the original spec, which has no 
such stuff. Is there an actual use case why this would be needed?

More general question - should we be implementing their extensions?

- Martin Klapetek


On Dec. 15, 2014, 10:37 a.m., Jan Grulich wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121529/
> ---
> 
> (Updated Dec. 15, 2014, 10:37 a.m.)
> 
> 
> Review request for Plasma and Martin Klapetek.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> According to our implementation of org.freedesktop.Notifications we don't 
> support persistent notifications, which is not true. This patch adds 
> "persistence" keyword to the list of capabilities.
> 
> See https://developer.gnome.org/notification-spec/#id2825605.
> 
> 
> Diffs
> -
> 
>   dataengines/notifications/notificationsengine.cpp d4b7f19 
> 
> Diff: https://git.reviewboard.kde.org/r/121529/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jan Grulich
> 
>

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

Review Request 121529: Let others know that we support persistent notifications

[Jan Grulich]

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

Review request for Plasma and Martin Klapetek.


Repository: plasma-workspace


Description
---

According to our implementation of org.freedesktop.Notifications we don't 
support persistent notifications, which is not true. This patch adds 
"persistence" keyword to the list of capabilities.

See https://developer.gnome.org/notification-spec/#id2825605.


Diffs
-

  dataengines/notifications/notificationsengine.cpp d4b7f19 

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


Testing
---


Thanks,

Jan Grulich

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

Re: Review Request 121429: Use out-of-band communication between ksld and greeter

[Martin Gräßlin]

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

(Updated Dec. 15, 2014, 10:29 a.m.)


Review request for Plasma, Àlex Fiestas and David Edmundson.


Changes
---

Move Wayland server handling into dedicated class


Repository: plasma-workspace


Description
---

The screenlocker_greet needs to tell the parent ksld process which
windows it created. Ksld sends input events to these windows. So
far this was based on an X property on the window. Unfortunately
ksld didn't validate whether the windows tagged with this property
belong to the screenlocker_greet process it started.

With this change the communication for announcing windows is moved
away from the X11 protocol and instead a custom Wayland protocol is
used.

Ksld starts a KWaylandServer when the greet process gets started. It
creates anonymous unix sockets for the connection and passes one
filedescriptor to the started greeter process.

The check for the X property is removed in ksld and instead only
windows ids passed through the Wayland socket connection are
accepted.


Diffs (updated)
-

  ksmserver/screenlocker/ksldapp.cpp 22698ce37e9d4be17126111b3ded8133f7c3baa6 
  ksmserver/screenlocker/lockwindow.h 9938d201269c89a24c9c0bd6275aa5f731bb5535 
  ksmserver/screenlocker/lockwindow.cpp 
3aa963a59e21636862f5ca59e220bbea3bd41ff9 
  ksmserver/screenlocker/protocols/ksld.xml PRE-CREATION 
  ksmserver/screenlocker/waylandserver.h PRE-CREATION 
  ksmserver/screenlocker/waylandserver.cpp PRE-CREATION 
  ksmserver/screenlocker/greeter/greeterapp.h 
b92b13b63365a9026dba5d71b772dcd8c9ee3d3b 
  ksmserver/screenlocker/greeter/greeterapp.cpp 
30d1821bdba38028959f3457e900a1b32e628192 
  ksmserver/screenlocker/greeter/main.cpp 
12e570107d0cba851b8978131d730b27924529bb 
  ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
  CMakeLists.txt c6d89c14b05f5639937aee5692d305fa2faed974 
  ksmserver/screenlocker/CMakeLists.txt 
5378a10df2be70cee95b5612c23046eae639f610 
  ksmserver/screenlocker/greeter/CMakeLists.txt 
10c473488f08354096f68784b9240392a444af5f 

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


Testing
---

Running ksmserver with the patch. Lock/unlock working, my exploit is failing.


Thanks,

Martin Gräßlin

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

Re: Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

[Martin Gräßlin]

> On Dec. 14, 2014, 8:57 p.m., Kai Uwe Broulik wrote:
> > Ping?
> > 
> > PowerDevil already uses the Logind1 interfaces for suspending in case it 
> > finds a systemd version >= 195

Thanks for that info. This removes a road blocker. So all that's left is moving 
the config option to screen locker and remove all that's left in Powerdevil to 
lock the screen.


- Martin


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


On Aug. 17, 2014, 5:10 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119814/
> ---
> 
> (Updated Aug. 17, 2014, 5:10 p.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> [ksld] ScreenLocker inhibits sleep on logind
> 
> When the system is going to sleep we want to ensure that the screen gets
> locked before the system goes to sleep. Logind provides the inhibitor
> locks which can be used for this.
> 
> If logind is available ksld gains an inhibitor lock for sleep when the
> screen is unlocked. As soon as the screen gets locked the inhibitor lock
> is released. In addition it connects to the prepareForSleep signal by
> logind and locks the screen.
> 
> The solution needs to be extended to have a config option whether the
> screen should be locked on sleep. Currently this is provided by
> powerdevil. Also the solution can only work properly if power devil uses
> logind's sleep dbus interface.
> 
> [ksld] Don't block till the greeter is started
> 
> We only want to ensure that the greeter gets started. There is no
> need to block for that. Instead we can connect to the error signal
> and unlock in case the greeter failed to start.
> 
> 
> -
> @Alex: what do you think is the best solution for handling the "lock screen 
> on resume" config option? My idea would be to move it to screen locker and 
> expose the value through DBus, so that powerdevil can still read it.
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
>   ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 
>   ksmserver/screenlocker/CMakeLists.txt 
> 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/autotests/CMakeLists.txt 
> 4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   ksmserver/screenlocker/ksldapp.cpp 04c7db366722f61dd87407d557ccf7d04ce83bcc 
> 
> Diff: https://git.reviewboard.kde.org/r/119814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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