Re: Fwd: Plasma Framework problems

[Marco Martin]

On Monday 13 October 2014, Marco Martin wrote:
> > I need approval from Marco and other David.
> 
> after a quick chat with David E this morning, I would revert that patch
> (and then remove the plugin in plasma-workspace master)
> *but* this only if there will be a 5.3.1 (there should be a fix in
> kwindowsystem as well as far i understood, so would be good a 5.3.1 release
> with both fixes)

Updates on this? how to proceed? it would be released from the current master, 
5.3 status plus one comit, or..?

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

Re: Review Request 120564: Write default file manager into mimeapps.list in XDG_CONFIG_HOME

[David Faure]

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

Ship it!


Indeed, well spotted.

Can you request a developer account? I don't have time to submit all your 
patches :-)
https://techbase.kde.org/Contribute/Get_a_Contributor_Account

- David Faure


On Oct. 12, 2014, 5:48 p.m., Luc Menut wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120564/
> ---
> 
> (Updated Oct. 12, 2014, 5:48 p.m.)
> 
> 
> Review request for Plasma and David Faure.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> Write the default file manager into mimeapps.list (inode/directory) in 
> XDG_CONFIG_HOME, as per mime-apps spec
> http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.1.html#file
> 
> keditfiletype (kde-cli-tools) already reads/writes mimeapps.list in 
> XDG_CONFIG_HOME since
> http://quickgit.kde.org/?p=kde-cli-tools.git&a=commit&h=e0d3bbdd0f68c39126a3c81bc373b53947d402f1
> 
> regards,
> 
> Luc Menut - Mageia
> 
> PS: I don't have write access to kde git, so could you commit the change if 
> the patch looks fine. Thanks.
> 
> 
> Diffs
> -
> 
>   kcms/componentchooser/componentchooserfilemanager.cpp b23bfa0 
> 
> Diff: https://git.reviewboard.kde.org/r/120564/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Luc Menut
> 
>

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

Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Marco Martin]

> On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote:
> > src/quickaddons/managedtexturenode.h, line 52
> > 
> >
> > even if will always remain just this member, just to me sure, it should 
> > be in a dpointer
> 
> Aleix Pol Gonzalez wrote:
> I don't think it's a good idea to add a d-pointer there. It's a class to 
> encapsulate the object, I don't see why we should store more things in there.
> 
> If needs changed, then I'd suggest to create another class.
> 
> Marco Martin wrote:
> if it's exported, i prefer a dpointer anyways
> 
> Aleix Pol Gonzalez wrote:
> Can we please discuss this? I really don't think we want to be so cheap 
> when it comes to memory usage. This means that each node in the scene will 
> take a payload for no much reason.
> 
> Vishesh Handa wrote:
> It's not only about memory usage. The memory gets defragmented as well.
> 
> Also, maybe considering this class is so small, you may want to inline 
> the function definitions.

heap fragmentation may be a valid argument, yeah


- Marco


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


On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120550/
> ---
> 
> (Updated Oct. 13, 2014, 5:54 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Moves the caching types used in Plasma Workspace into a QuickAddons submodule.
> 
> Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
> item. Uses the same strategies used in Plasma Framework for caching the 
> textures.
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
>   src/quickaddons/CMakeLists.txt PRE-CREATION 
>   src/quickaddons/imagetexturescache.h PRE-CREATION 
>   src/quickaddons/imagetexturescache.cpp PRE-CREATION 
>   src/quickaddons/managedtexturenode.h PRE-CREATION 
>   src/quickaddons/managedtexturenode.cpp PRE-CREATION 
>   tests/qiconitem_test.qml PRE-CREATION 
>   src/CMakeLists.txt eb0dfd3 
> 
> Diff: https://git.reviewboard.kde.org/r/120550/diff/
> 
> 
> Testing
> ---
> 
> I added some manual test (that was impossible to run before the patch). Also 
> tested it in KRunner and Muon Discover, which use the component. Everything 
> still works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Auto-hiding panels

[Andrew Lake]

On Tue, Oct 14, 2014 at 6:51 AM, Àlex Fiestas wrote:

> On Tuesday 14 October 2014 10:43:42 Martin Klapetek wrote:
> > I'd like to change this for Plasma panels to not have any resistance or
> > very minimal one, basically get it into a state that slamming the mouse
> > against a screen edge will show the panel easily, without requiring an
> > additional push.
> I think we should ask VDG about this, it is a change in behavior and look
> and
> feel after all!
>
> Maybe just tweak to the edge triggering code might get us there as Martin
suggests. :-)

Best I can tell, the behavioral model from the user side is to move the
cursor far enough beyond the edge and the panel will appear. Based on that
behavioral model, I think the expectation would be that if the cursor is
moving relatively quickly when it get's to the edge it'll get to the magic
distance beyond the edge more quickly than if the cursor is moving
relatively slowly.

Another potential behavioral model could be a force model, where the panel
unhides when the edge is hit with a certain degree of "force". Force based
models can be quite complex though since it usually requires some kind of
elastic resistance at the edge to allow triggering when moving the cursor
relatively slowly. Also, since there are very few uses of the cursor within
the screen boundaries that employ a force model, the user needs to maintain
quite different behavioral models of the the cursor behavior at the edge
versus the middle of the screen. It doesn't mean it can't be done, but I
think it can be quite tricky to do well. A simple magic distance past the
edge behavior is usually much simpler and more predictable I think and
should handle the fast versus slow edge approaches just fine.

Hope this helps,
Andrew
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120584: Don't position the panel until it's about to be displayed

[Marco Martin]

> On Ott. 14, 2014, 4:36 p.m., Marco Martin wrote:
> > Sounds sensible.
> > however, can someone try plasma without this patch and with the Qt patch:
> > https://codereview.qt-project.org/#/c/97050/ 
> > 
> > this one may be a workaround for the qt xcb problem adressed in the above, 
> > but i'm not 100% sure since i can't reproduce the issue of panel starting 
> > up on wrong monitor (even if is a workaround, this one may be needed 
> > anyways since it would take aeons anyways for the qt patch making to 
> > releases)

even without the patch in qt, to see if it was *that* issue, it can be checked 
if seeting the panels as window can cover (or anything *without* struts) makes 
the problem not happen.

so the problem is the following:
* the panel sets an extended strut, removing its geometry from 
QScreen::AvailableGeometry()
* if the panel is ill-positioned just a little and overflows in the second 
screen even just a pixel (admittedly a bug in itself, but unrelated), qt xcb 
sees that the panel is not in the availableGeometry() of its screen, so checks 
if it is of any other screen, and if it is of even 1 pixel, it migrates the 
panel t the new screen


- Marco


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


On Ott. 14, 2014, 4:15 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120584/
> ---
> 
> (Updated Ott. 14, 2014, 4:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I was getting the Panels wrongly positioned because Qt would reset the 
> position at some point while initializing the class. This patch disables any 
> position while the panel is not shown and makes sure it's placed when it's 
> set to be shown.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 9260c18 
> 
> Diff: https://git.reviewboard.kde.org/r/120584/diff/
> 
> 
> Testing
> ---
> 
> Both my installations initialize properly now.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 120584: Don't position the panel until it's about to be displayed

[Marco Martin]

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

Ship it!


Sounds sensible.
however, can someone try plasma without this patch and with the Qt patch:
https://codereview.qt-project.org/#/c/97050/ 

this one may be a workaround for the qt xcb problem adressed in the above, but 
i'm not 100% sure since i can't reproduce the issue of panel starting up on 
wrong monitor (even if is a workaround, this one may be needed anyways since it 
would take aeons anyways for the qt patch making to releases)

- Marco Martin


On Ott. 14, 2014, 4:15 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120584/
> ---
> 
> (Updated Ott. 14, 2014, 4:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I was getting the Panels wrongly positioned because Qt would reset the 
> position at some point while initializing the class. This patch disables any 
> position while the panel is not shown and makes sure it's placed when it's 
> set to be shown.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 9260c18 
> 
> Diff: https://git.reviewboard.kde.org/r/120584/diff/
> 
> 
> Testing
> ---
> 
> Both my installations initialize properly now.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 120584: Don't position the panel until it's about to be displayed

[Jeremy Whiting]

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

Ship it!


Ship It!

- Jeremy Whiting


On Oct. 14, 2014, 10:15 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120584/
> ---
> 
> (Updated Oct. 14, 2014, 10:15 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I was getting the Panels wrongly positioned because Qt would reset the 
> position at some point while initializing the class. This patch disables any 
> position while the panel is not shown and makes sure it's placed when it's 
> set to be shown.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 9260c18 
> 
> Diff: https://git.reviewboard.kde.org/r/120584/diff/
> 
> 
> Testing
> ---
> 
> Both my installations initialize properly now.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 120584: Don't position the panel until it's about to be displayed

[Jeremy Whiting]

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


That seems to fix the panel showing on the wrong screen I was experiencing 
before. Nice.

- Jeremy Whiting


On Oct. 14, 2014, 10:15 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120584/
> ---
> 
> (Updated Oct. 14, 2014, 10:15 a.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I was getting the Panels wrongly positioned because Qt would reset the 
> position at some point while initializing the class. This patch disables any 
> position while the panel is not shown and makes sure it's placed when it's 
> set to be shown.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 9260c18 
> 
> Diff: https://git.reviewboard.kde.org/r/120584/diff/
> 
> 
> Testing
> ---
> 
> Both my installations initialize properly now.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 120584: Don't position the panel until it's about to be displayed

[Martin Gräßlin]

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


looks like a useful change to me (and I hope it fixes the mispositioning I 
experienced today when restarting the system ;-) )

- Martin Gräßlin


On Oct. 14, 2014, 6:15 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120584/
> ---
> 
> (Updated Oct. 14, 2014, 6:15 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> I was getting the Panels wrongly positioned because Qt would reset the 
> position at some point while initializing the class. This patch disables any 
> position while the panel is not shown and makes sure it's placed when it's 
> set to be shown.
> 
> 
> Diffs
> -
> 
>   shell/panelview.cpp 9260c18 
> 
> Diff: https://git.reviewboard.kde.org/r/120584/diff/
> 
> 
> Testing
> ---
> 
> Both my installations initialize properly now.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Build failed in Jenkins: plasma-workspace_master_qt5 #974

[KDE CI System]

See 

Changes:

[mart] Make apply button work correctly

--
[...truncated 2293 lines...]
 const QSet spdMethods = 
Solid::PowerManagement::supportedSleepStates();

 ^
:144:110:
 warning: ‘QSet 
Solid::PowerManagement::supportedSleepStates()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:74)
 [-Wdeprecated-declarations]
 const QSet spdMethods = 
Solid::PowerManagement::supportedSleepStates();

  ^
:
 In member function ‘void ScreenLocker::UnlockApp::suspendToRam()’:
:278:29:
 warning: ‘void 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::SleepState, 
QObject*, const char*)’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:83)
 [-Wdeprecated-declarations]
 Solid::PowerManagement::requestSleep(Solid::PowerManagement::SuspendState, 
0, 0);
 ^
:278:84:
 warning: ‘void 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::SleepState, 
QObject*, const char*)’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:83)
 [-Wdeprecated-declarations]
 Solid::PowerManagement::requestSleep(Solid::PowerManagement::SuspendState, 
0, 0);

^
:
 In member function ‘void ScreenLocker::UnlockApp::suspendToDisk()’:
:291:29:
 warning: ‘void 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::SleepState, 
QObject*, const char*)’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:83)
 [-Wdeprecated-declarations]
 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::HibernateState, 0, 
0);
 ^
:291:86:
 warning: ‘void 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::SleepState, 
QObject*, const char*)’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:83)
 [-Wdeprecated-declarations]
 
Solid::PowerManagement::requestSleep(Solid::PowerManagement::HibernateState, 0, 
0);

  ^
[ 37%] Building CXX object 
ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kscreensaversettings.cpp.o
:0:0: warning: "TRANSLATION_DOMAIN" redefined [enabled by default]
:0:0: note: this is the location of the previous definition
[ 37%] Built target killTest
[ 37%] [ 37%] Building CXX object 
ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/main.cpp.o
Building CXX object 
ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/ksmserver_interface.cpp.o
[ 37%] Building CXX object 
klipper/CMakeFiles/plasma_engine_clipboard.dir/clipboardengine.cpp.o
[ 37%] Building CXX object klipper/CMakeFiles/kdeinit_klipper.dir/tray.cpp.o
Linking CXX executable authenticatorTest
[ 37%] Building CXX object 
shell/CMakeFiles/plasmashell.dir/plasmashell_automoc.cpp.o
[ 37%] Built target authenticatorTest
[ 37%] Building CXX object 
ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/screenlocker_interface.cpp.o
:0:0: warning: "TRANSLATION_DOMAIN" redefined [enabled by default]
:0:0: note: this is the location of the previous definition
[ 38%] Building CXX object 
ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/qrc_fallbacktheme.cpp.o
[ 38%] Building CXX object 
ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreensaversettings.cpp.o
[ 39%] Building CXX object 
klipper/CMakeFiles/plasma_engine_clipboard.dir/clipboardservice.cpp.o
[ 39%] Building CXX object 
klipper/CMakeFiles/plasm

Review Request 120584: Don't position the panel until it's about to be displayed

[Aleix Pol Gonzalez]

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

Review request for Plasma.


Repository: plasma-workspace


Description
---

I was getting the Panels wrongly positioned because Qt would reset the position 
at some point while initializing the class. This patch disables any position 
while the panel is not shown and makes sure it's placed when it's set to be 
shown.


Diffs
-

  shell/panelview.cpp 9260c18 

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


Testing
---

Both my installations initialize properly now.


Thanks,

Aleix Pol Gonzalez

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

Build failed in Jenkins: plasma-workspace_master_qt5 #973

[KDE CI System]

See 

Changes:

[me] Baloo Runner: Port to newer api

--
[...truncated 2340 lines...]
[ 40%] Building CXX object 
ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kscreensaversettings.cpp.o
:0:0: warning: "TRANSLATION_DOMAIN" redefined [enabled by default]
:0:0: note: this is the location of the previous definition
[ 40%] Building CXX object 
ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/screenlocker_interface.cpp.o
:0:0: warning: "TRANSLATION_DOMAIN" redefined [enabled by default]
:0:0: note: this is the location of the previous definition
Linking CXX shared module plasma_engine_clipboard.so
Scanning dependencies of target ksldTest
[ 40%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/ksldTest.dir/ksldtest.cpp.o
[ 41%] Built target plasma_engine_clipboard
[ 41%] Building CXX object 
klipper/CMakeFiles/kdeinit_klipper.dir/kdeinit_klipper_automoc.cpp.o
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/ksldTest.dir/ksldTest_automoc.cpp.o
[ 42%] Building CXX object 
ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/screenlocker_kcm_automoc.cpp.o
:0:0: warning: "TRANSLATION_DOMAIN" redefined [enabled by default]
:0:0: note: this is the location of the previous definition
Scanning dependencies of target lockWindowTest
Scanning dependencies of target logindTest
[ 42%] [ 42%] Scanning dependencies of target pointerGrabber
Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o
Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o
Linking CXX executable kscreenlocker_greet
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/__/logind.cpp.o
[ 42%] Built target kscreenlocker_greet
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindTest_automoc.cpp.o
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o
Linking CXX executable pointerGrabber
Linking CXX shared module screenlocker_kcm.so
[ 42%] Built target pointerGrabber
Scanning dependencies of target kscreenlocker_test
[ 42%] Building CXX object 
ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_main.cpp.o
Linking CXX executable ksldTest
[ 42%] Built target screenlocker_kcm
Linking CXX shared library libkdeinit5_klipper.so
Scanning dependencies of target ksplashqml
[ 42%] Building CXX object 
ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o
[ 42%] Built target ksldTest
[ 42%] Scanning dependencies of target kded_ksysguard
[ 42%] Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o
Generating statusnotifieritem_interface.cpp, statusnotifieritem_interface.h
[ 42%] Building CXX object 
systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o
[ 42%] Scanning dependencies of target systemmonitor
Generating statusnotifierwatcheradaptor.cpp, statusnotifierwatcheradaptor.h
[ 43%] Building CXX object 
systemmonitor/CMakeFiles/systemmonitor.dir/ksystemactivitydialog.cpp.o
[ 43%] Built target kdeinit_klipper
[ 43%] [ 43%] Building CXX object 
systemmonitor/CMakeFiles/kded_ksysguard.dir/kded_ksysguard_automoc.cpp.o
Generating statusnotifierwatcheradaptor.moc
[ 43%] Generating statusnotifieritem_interface.moc
[ 43%] Building CXX object 
ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_test_automoc.cpp.o
Scanning dependencies of target kded_statusnotifierwatcher
[ 43%] [ 44%] Building CXX object 
statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcher.cpp.o
Building CXX object 
ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o
Linking CXX executable kscreenlocker_test
Linking CXX executable logindTest
[ 44%] Built target logindTest
[ 45%] Building CXX object 
statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcheradaptor.cpp.o
[ 45%] Built target kscreenlocker_test
[ 45%] Building CXX object 
statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifieritem_interface.cpp.o
[ 45%] Building CXX object 
ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashApp.cpp.o
:39:1:
 warning: unused parameter ‘parent’ [-Wunused-parameter]
 KDEDKSysGuard::KDEDKSysGuard(QObject* parent, const QVariantList&)
 ^
[ 45%] Building CXX object 
ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashWindow.cpp.o
[ 45%] Building CXX object 
ksplash/ksplashqml/CMakeFiles/k

Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Vishesh Handa]

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



src/quickaddons/imagetexturescache.h


Strange indentation.


- Vishesh Handa


On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120550/
> ---
> 
> (Updated Oct. 13, 2014, 5:54 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Moves the caching types used in Plasma Workspace into a QuickAddons submodule.
> 
> Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
> item. Uses the same strategies used in Plasma Framework for caching the 
> textures.
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
>   src/quickaddons/CMakeLists.txt PRE-CREATION 
>   src/quickaddons/imagetexturescache.h PRE-CREATION 
>   src/quickaddons/imagetexturescache.cpp PRE-CREATION 
>   src/quickaddons/managedtexturenode.h PRE-CREATION 
>   src/quickaddons/managedtexturenode.cpp PRE-CREATION 
>   tests/qiconitem_test.qml PRE-CREATION 
>   src/CMakeLists.txt eb0dfd3 
> 
> Diff: https://git.reviewboard.kde.org/r/120550/diff/
> 
> 
> Testing
> ---
> 
> I added some manual test (that was impossible to run before the patch). Also 
> tested it in KRunner and Muon Discover, which use the component. Everything 
> still works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem

[Vishesh Handa]

> On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote:
> > src/quickaddons/managedtexturenode.h, line 52
> > 
> >
> > even if will always remain just this member, just to me sure, it should 
> > be in a dpointer
> 
> Aleix Pol Gonzalez wrote:
> I don't think it's a good idea to add a d-pointer there. It's a class to 
> encapsulate the object, I don't see why we should store more things in there.
> 
> If needs changed, then I'd suggest to create another class.
> 
> Marco Martin wrote:
> if it's exported, i prefer a dpointer anyways
> 
> Aleix Pol Gonzalez wrote:
> Can we please discuss this? I really don't think we want to be so cheap 
> when it comes to memory usage. This means that each node in the scene will 
> take a payload for no much reason.

It's not only about memory usage. The memory gets defragmented as well.

Also, maybe considering this class is so small, you may want to inline the 
function definitions.


- Vishesh


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


On Oct. 13, 2014, 5:54 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120550/
> ---
> 
> (Updated Oct. 13, 2014, 5:54 p.m.)
> 
> 
> Review request for KDE Frameworks, Plasma, David Edmundson, and Marco Martin.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> Moves the caching types used in Plasma Workspace into a QuickAddons submodule.
> 
> Adopts them in QIconItem by moving it from a QPainterItem to a QQuickPainter 
> item. Uses the same strategies used in Plasma Framework for caching the 
> textures.
> 
> 
> Diffs
> -
> 
>   src/qmlcontrols/kquickcontrolsaddons/CMakeLists.txt 2977812 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.h 839a33f 
>   src/qmlcontrols/kquickcontrolsaddons/qiconitem.cpp 0eb46b1 
>   src/quickaddons/CMakeLists.txt PRE-CREATION 
>   src/quickaddons/imagetexturescache.h PRE-CREATION 
>   src/quickaddons/imagetexturescache.cpp PRE-CREATION 
>   src/quickaddons/managedtexturenode.h PRE-CREATION 
>   src/quickaddons/managedtexturenode.cpp PRE-CREATION 
>   tests/qiconitem_test.qml PRE-CREATION 
>   src/CMakeLists.txt eb0dfd3 
> 
> Diff: https://git.reviewboard.kde.org/r/120550/diff/
> 
> 
> Testing
> ---
> 
> I added some manual test (that was impossible to run before the patch). Also 
> tested it in KRunner and Muon Discover, which use the component. Everything 
> still works.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Auto-hiding panels

[Àlex Fiestas]

On Tuesday 14 October 2014 10:43:42 Martin Klapetek wrote:
> I'd like to change this for Plasma panels to not have any resistance or
> very minimal one, basically get it into a state that slamming the mouse
> against a screen edge will show the panel easily, without requiring an
> additional push.
I think we should ask VDG about this, it is a change in behavior and look and 
feel after all!

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 120581: Don't crash if the plasmoid wasn't properly loaded

[Aleix Pol Gonzalez]

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

(Updated Oct. 14, 2014, 1:46 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

If d->applet->package().isValid(), then d->qmlObject->mainComponent() is null.

This makes Plasma crash when a plasmoid is loaded.


Diffs
-

  src/plasmaquick/appletquickitem.cpp 45055a5 

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


Testing
---

Doesn't crash anymore.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Martin Gräßlin]

> On Oct. 14, 2014, 1:50 p.m., Martin Gräßlin wrote:
> > -2, it's not installed as the WaylandServer still needs work and is not in 
> > a state yet to provide ABI.
> 
> Sebastian Kügler wrote:
> Well, neither is WaylandServer, the point at this point in time is to 
> allow sharing code, no?
> 
> Is there another way to easily start a wayland server to I can run my 
> autotests automatically?
> 
> Martin Gräßlin wrote:
> that's why WaylandServer is not installed. The WaylandClient library is 
> supposed to be ABI stable.
> 
> I want to get it into a state that WaylandServer can be ABI stable. But I 
> cannot guarantee that I will be happy with the state for 5.1. It pretty much 
> depends on how fast we get the interfaces implemented. At the moment lots is 
> still stubs which makes it difficult to say "yeah, that API won't change 
> anymore".
> 
> For your current need I'd suggest to keep the patch locally to get it 
> working and make proper CMake magic in kscreen. AFAIU you only need the 
> server for the unit test, so the component should only be searched for tests 
> and the respective tests should just not be built if the Component is not 
> found. That way you should be able to write all the tests and they will just 
> work (TM) once this component becomes public.
> 
> Martin Gräßlin wrote:
> As you submitted part of the change I read that as the suggestion works 
> for you?
> 
> Sebastian Kügler wrote:
> Ah, sorry, should have replied in-text (not just in-commit and assume you 
> read my mind to fill in the blanks).
> 
> Well, the export header fix needed to go in, anyway, so that's pushed and 
> out of the way.
> 
> As to the other part, I suppose it's OK (I simply trust you there), it 
> requires a little more attention to be paid on my side, but as the wayland 
> backend in libkscreen is also still incumbent (and not quite near useful), I 
> can live with that for now. That's assuming I can check for 
> KF5::WaylandClient and KF5::WaylandServer separately in the cmake foo, I 
> haven't checked that yet, the current check builds the wayland backend and 
> the tests conditional if(Wayland_Client_FOUND AND KF5Wayland_FOUND), so 
> there's no distinction between WaylandServer and WaylandClient, yet. As I 
> said, haven't checked that yet.

unless there's a bug in the CMake foo in KWayland (I wouldn't be suprised if 
there were ;-) ), it should be possible to find separately. If not please 
report and we can fix it.


- Martin


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


On Oct. 14, 2014, 2:49 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 2:49 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Sebastian Kügler]

> On Oct. 14, 2014, 11:50 a.m., Martin Gräßlin wrote:
> > -2, it's not installed as the WaylandServer still needs work and is not in 
> > a state yet to provide ABI.
> 
> Sebastian Kügler wrote:
> Well, neither is WaylandServer, the point at this point in time is to 
> allow sharing code, no?
> 
> Is there another way to easily start a wayland server to I can run my 
> autotests automatically?
> 
> Martin Gräßlin wrote:
> that's why WaylandServer is not installed. The WaylandClient library is 
> supposed to be ABI stable.
> 
> I want to get it into a state that WaylandServer can be ABI stable. But I 
> cannot guarantee that I will be happy with the state for 5.1. It pretty much 
> depends on how fast we get the interfaces implemented. At the moment lots is 
> still stubs which makes it difficult to say "yeah, that API won't change 
> anymore".
> 
> For your current need I'd suggest to keep the patch locally to get it 
> working and make proper CMake magic in kscreen. AFAIU you only need the 
> server for the unit test, so the component should only be searched for tests 
> and the respective tests should just not be built if the Component is not 
> found. That way you should be able to write all the tests and they will just 
> work (TM) once this component becomes public.
> 
> Martin Gräßlin wrote:
> As you submitted part of the change I read that as the suggestion works 
> for you?

Ah, sorry, should have replied in-text (not just in-commit and assume you read 
my mind to fill in the blanks).

Well, the export header fix needed to go in, anyway, so that's pushed and out 
of the way.

As to the other part, I suppose it's OK (I simply trust you there), it requires 
a little more attention to be paid on my side, but as the wayland backend in 
libkscreen is also still incumbent (and not quite near useful), I can live with 
that for now. That's assuming I can check for KF5::WaylandClient and 
KF5::WaylandServer separately in the cmake foo, I haven't checked that yet, the 
current check builds the wayland backend and the tests conditional 
if(Wayland_Client_FOUND AND KF5Wayland_FOUND), so there's no distinction 
between WaylandServer and WaylandClient, yet. As I said, haven't checked that 
yet.


- Sebastian


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


On Oct. 14, 2014, 12:49 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 12:49 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120581: Don't crash if the plasmoid wasn't properly loaded

[Marco Martin]

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

Ship it!


Inviala!

- Marco Martin


On Ott. 14, 2014, 1:09 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120581/
> ---
> 
> (Updated Ott. 14, 2014, 1:09 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> If d->applet->package().isValid(), then d->qmlObject->mainComponent() is null.
> 
> This makes Plasma crash when a plasmoid is loaded.
> 
> 
> Diffs
> -
> 
>   src/plasmaquick/appletquickitem.cpp 45055a5 
> 
> Diff: https://git.reviewboard.kde.org/r/120581/diff/
> 
> 
> Testing
> ---
> 
> Doesn't crash anymore.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 120581: Don't crash if the plasmoid wasn't properly loaded

[Aleix Pol Gonzalez]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

If d->applet->package().isValid(), then d->qmlObject->mainComponent() is null.

This makes Plasma crash when a plasmoid is loaded.


Diffs
-

  src/plasmaquick/appletquickitem.cpp 45055a5 

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


Testing
---

Doesn't crash anymore.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Martin Gräßlin]

> On Oct. 14, 2014, 1:50 p.m., Martin Gräßlin wrote:
> > -2, it's not installed as the WaylandServer still needs work and is not in 
> > a state yet to provide ABI.
> 
> Sebastian Kügler wrote:
> Well, neither is WaylandServer, the point at this point in time is to 
> allow sharing code, no?
> 
> Is there another way to easily start a wayland server to I can run my 
> autotests automatically?
> 
> Martin Gräßlin wrote:
> that's why WaylandServer is not installed. The WaylandClient library is 
> supposed to be ABI stable.
> 
> I want to get it into a state that WaylandServer can be ABI stable. But I 
> cannot guarantee that I will be happy with the state for 5.1. It pretty much 
> depends on how fast we get the interfaces implemented. At the moment lots is 
> still stubs which makes it difficult to say "yeah, that API won't change 
> anymore".
> 
> For your current need I'd suggest to keep the patch locally to get it 
> working and make proper CMake magic in kscreen. AFAIU you only need the 
> server for the unit test, so the component should only be searched for tests 
> and the respective tests should just not be built if the Component is not 
> found. That way you should be able to write all the tests and they will just 
> work (TM) once this component becomes public.

As you submitted part of the change I read that as the suggestion works for you?


- Martin


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


On Oct. 14, 2014, 2:49 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 2:49 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Sebastian Kügler]

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

(Updated Oct. 14, 2014, 12:49 p.m.)


Status
--

This change has been marked as submitted.


Review request for kwin, Plasma and Martin Gräßlin.


Repository: kwayland


Description
---

Install headers for WaylandServer

I'm not sure why this was commented (it didn't work, due to wrong
paths), but maybe there's another reason.

Anyway, I'd like to use these things for my unit tests in libkscreen, so
I don't have to start a Wayland server manually, and this seems to be
needed.

In detail:
- actually install headers
- generate the export header into Wayland/Server
- include it from there


Diffs
-

  src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
  src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
  src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
  src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
  src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
  src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
  src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
  src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 

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


Testing
---

Used the library from libkscreen, no problems so far (headers found, linker 
succeeds).


Thanks,

Sebastian Kügler

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Roberto]

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

--- Comment #19 from Roberto  ---
I used powertop a few times in the past weeks, and then switched to tlp. Of
course I have tried to disable tlp to see if that helps (it doesn't).

My filesystem is ext4.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #18 from Vincent Petry  ---
I raised a ticket in the kernel tracker:
https://bugzilla.kernel.org/show_bug.cgi?id=86241

I suggest to continue the discussion there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #17 from Vincent Petry  ---
Just checked dmesg from before the crash but there is no relevant info. The
last entries are from a few hours before... not sure whether they got "eaten".
I could imagine that suspending prevents buffers to be flushed to disk.

I guess for now the only thing we can do is try different combinations of
software / desktop env and possibly kernel modules... until the problem isn't
reproducible a few days in a row.

Roberto, did you also use powertop to optimize battery life ?
Do you also have a BTRFS root partition ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Martin Gräßlin]

> On Oct. 14, 2014, 1:50 p.m., Martin Gräßlin wrote:
> > -2, it's not installed as the WaylandServer still needs work and is not in 
> > a state yet to provide ABI.
> 
> Sebastian Kügler wrote:
> Well, neither is WaylandServer, the point at this point in time is to 
> allow sharing code, no?
> 
> Is there another way to easily start a wayland server to I can run my 
> autotests automatically?

that's why WaylandServer is not installed. The WaylandClient library is 
supposed to be ABI stable.

I want to get it into a state that WaylandServer can be ABI stable. But I 
cannot guarantee that I will be happy with the state for 5.1. It pretty much 
depends on how fast we get the interfaces implemented. At the moment lots is 
still stubs which makes it difficult to say "yeah, that API won't change 
anymore".

For your current need I'd suggest to keep the patch locally to get it working 
and make proper CMake magic in kscreen. AFAIU you only need the server for the 
unit test, so the component should only be searched for tests and the 
respective tests should just not be built if the Component is not found. That 
way you should be able to write all the tests and they will just work (TM) once 
this component becomes public.


- Martin


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


On Oct. 14, 2014, 1:46 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 1:46 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.

[Vincent Petry]

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

--- Comment #16 from Vincent Petry  ---
Created attachment 89126
  --> https://bugs.kde.org/attachment.cgi?id=89126&action=edit
Failed pm-suspend.log

It happened again, when running pm-suspend directly.

I've attached the log.
It looks the same as the successful one, except that it stops at:

Tue Oct 14 13:11:03 CEST 2014: performing suspend
INFO: using built-in quirks database from HAL.
INFO: S2RAM_OPTS from HAL quirks: ' '.

But the successful one goes one line further before waking up:

/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Mon Oct 13 19:53:58 CEST 2014: performing suspend
INFO: using built-in quirks database from HAL.
INFO: S2RAM_OPTS from HAL quirks: ' '.
KMS graphics driver is in use, skipping quirks.
Mon Oct 13 19:54:12 CEST 2014: Awake.

The additional row missing from the broken one is:
KMS graphics driver is in use, skipping quirks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Sebastian Kügler]

> On Oct. 14, 2014, 11:54 a.m., Martin Gräßlin wrote:
> > that said: I'm happy to take a patch to fix the export header ;-)

Sure, I can push that part separately (with commented INSTALL directive), but 
let's sort that thread of the discussion out, first.


- Sebastian


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


On Oct. 14, 2014, 11:46 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 11:46 a.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Sebastian Kügler]

> On Oct. 14, 2014, 11:50 a.m., Martin Gräßlin wrote:
> > -2, it's not installed as the WaylandServer still needs work and is not in 
> > a state yet to provide ABI.

Well, neither is WaylandServer, the point at this point in time is to allow 
sharing code, no?

Is there another way to easily start a wayland server to I can run my autotests 
automatically?


- Sebastian


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


On Oct. 14, 2014, 11:46 a.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 11:46 a.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Martin Gräßlin]

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


that said: I'm happy to take a patch to fix the export header ;-)

- Martin Gräßlin


On Oct. 14, 2014, 1:46 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 1:46 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120579: [KWayland] Install headers for WaylandServer

[Martin Gräßlin]

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


-2, it's not installed as the WaylandServer still needs work and is not in a 
state yet to provide ABI.

- Martin Gräßlin


On Oct. 14, 2014, 1:46 p.m., Sebastian Kügler wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120579/
> ---
> 
> (Updated Oct. 14, 2014, 1:46 p.m.)
> 
> 
> Review request for kwin, Plasma and Martin Gräßlin.
> 
> 
> Repository: kwayland
> 
> 
> Description
> ---
> 
> Install headers for WaylandServer
> 
> I'm not sure why this was commented (it didn't work, due to wrong
> paths), but maybe there's another reason.
> 
> Anyway, I'd like to use these things for my unit tests in libkscreen, so
> I don't have to start a Wayland server manually, and this seems to be
> needed.
> 
> In detail:
> - actually install headers
> - generate the export header into Wayland/Server
> - include it from there
> 
> 
> Diffs
> -
> 
>   src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
>   src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
>   src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
>   src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
>   src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
>   src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
>   src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
>   src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 
> 
> Diff: https://git.reviewboard.kde.org/r/120579/diff/
> 
> 
> Testing
> ---
> 
> Used the library from libkscreen, no problems so far (headers found, linker 
> succeeds).
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 12:34 p.m., Aleix Pol Gonzalez wrote:
> > I think it's unfortunate, you're giving a mix of technical and usability 
> > reasons to back your patch. In any case, I understand that the bug needs to 
> > be solved and if this is what it takes, then do it.
> > 
> > FWIW, I also think suspend would be good here.
> 
> Martin Gräßlin wrote:
> Just out of interest: where am I mixing technical and usability reasons? 
> To me the commit message sounds only technical.
> 
> Aleix Pol Gonzalez wrote:
> Well, it's not like it's not possible to shutdown from the lock screen. 
> Many OS have done that in the past, thinking of Android, Windows (XP?), etc. 
> So we can fix that, or disable it. So that's technical, while removing the 
> functionality is the usability way to solve things.
> 
> Disabling it is efficient on the other hand, because we already have this 
> patch.

ok, I understand what you mean. But I think the comparison to other OS doesn't 
really fit as we have the session management and interaction. Android is 
designed differentelly with each application having to expect that it gets 
killed at any time anyway.


- Martin


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


On Oct. 14, 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/120577/
> ---
> 
> (Updated Oct. 14, 2014, 11:45 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Bugs: 339453
> https://bugs.kde.org/show_bug.cgi?id=339453
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Review Request 120579: [KWayland] Install headers for WaylandServer

[Sebastian Kügler]

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

Review request for kwin, Plasma and Martin Gräßlin.


Repository: kwayland


Description
---

Install headers for WaylandServer

I'm not sure why this was commented (it didn't work, due to wrong
paths), but maybe there's another reason.

Anyway, I'd like to use these things for my unit tests in libkscreen, so
I don't have to start a Wayland server manually, and this seems to be
needed.

In detail:
- actually install headers
- generate the export header into Wayland/Server
- include it from there


Diffs
-

  src/server/CMakeLists.txt 066d564507633b42455482b441912359d7e65c74 
  src/server/buffer_interface.h 9cf84c5f3b62df6d53c36d4671302388a9adf261 
  src/server/compositor_interface.h 60ea01a59cea595df39d5ab74215f2de98fb390d 
  src/server/display.h 31cb24fc46576e94e72e637a81b99b8155fcbe9b 
  src/server/output_interface.h eba9a32e5110a6892931665ff568e4322cd1c8e1 
  src/server/seat_interface.h 18d2dba38564df0519cd6f636f2dc527473c0b97 
  src/server/shell_interface.h 31f84044c7dcfb172e6a8a7134f9474ff973c5fd 
  src/server/surface_interface.h 31e0e75e3db534720900cf4458ea1c265f5570a7 

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


Testing
---

Used the library from libkscreen, no problems so far (headers found, linker 
succeeds).


Thanks,

Sebastian Kügler

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

Re: Plasma 5.1 new tars coming..

[Jonathan Riddell]

New tars up at
 http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/
and coming soon to depot

To save time I cheated and just ran sed on the CMakeLists.txt file of
most of them to fix the version number but I did reroll breeze to fix
the BreezeDark.color filename, oxygen to fix build for the Qt4 and
plasma-nm to fix the way the internal version number is set.

Tars are versioned 5.1.0.1 for clarity, internal verion is 5.1.0.

Lo siento

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

Re: Review Request 120471: Add Registry::sync() signal

[Sebastian Kügler]

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

(Updated Oct. 14, 2014, 11:40 a.m.)


Status
--

This change has been marked as submitted.


Review request for kwin, Plasma and Martin Gräßlin.


Repository: kwayland


Description
---

Add Registry::sync() signal

Emitted when the Wayland display is done flushing the initial interface
callbacks, announcing wl_display properties. This can be used to compress
events. Note that this signal is emitted only after announcing interfaces,
such as outputs, but not after receiving callbacks of interface properties,
such as the output's geometry, modes, etc..
This signal is emitted from the wl_display_sync callback.

For this, we add a wl_callback_listener to the registry's Private,
enqueue its events properly, if necessary, and trigger the signal
through a callback mechanism similar to the wl_registry callbacks.

This signal allows users of the API to find out when the signal
emissions, such as outputAnnounced, etc. for all currently existing
interfaces is complete.


Diffs
-

  autotests/client/test_wayland_registry.cpp 571be0f 
  src/client/registry.h 9e63a2b 
  src/client/registry.cpp 207cdef 

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


Testing
---

tests in libkscreen exercise this feature, it works as expected, meaning I can 
notify when all initial synchronization is done.


Thanks,

Sebastian Kügler

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Aleix Pol Gonzalez]

> On Oct. 14, 2014, 10:34 a.m., Aleix Pol Gonzalez wrote:
> > I think it's unfortunate, you're giving a mix of technical and usability 
> > reasons to back your patch. In any case, I understand that the bug needs to 
> > be solved and if this is what it takes, then do it.
> > 
> > FWIW, I also think suspend would be good here.
> 
> Martin Gräßlin wrote:
> Just out of interest: where am I mixing technical and usability reasons? 
> To me the commit message sounds only technical.

Well, it's not like it's not possible to shutdown from the lock screen. Many OS 
have done that in the past, thinking of Android, Windows (XP?), etc. So we can 
fix that, or disable it. So that's technical, while removing the functionality 
is the usability way to solve things.

Disabling it is efficient on the other hand, because we already have this patch.


- Aleix


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


On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 9:45 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Bugs: 339453
> https://bugs.kde.org/show_bug.cgi?id=339453
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Re: Re: Auto-hiding panels

[Martin Gräßlin]

On Tuesday 14 October 2014 12:19:24 Martin Klapetek wrote:
> To overcome the panel resistance in one single mouse movement it takes me 
moving the mouse across half the table here.

This would indicate that the overall edge triggering code needs to be 
improved. I'm certainly not saying that it's perfect. For my usage it's not a 
problem as I'm using a trackball.

So the outcome for me is: let's try improve the handling to make it better for 
everyone.

Cheers
Martin

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

Re: Plasma 5.1 new tars coming..

[Sebastian Kügler]

On Tuesday, October 14, 2014 11:22:39 Jonathan Riddell wrote:
> I just noticed at the last minute that the Plasma tars didn't have
> their internal version numbers updated to 5.1.0, the script I wrote to
> make that easier must have only updated master and not branch.  I'm
> going to reroll the tars now to fix the version number.  Sorry folks.

That also means that we've pushed back Plasma 5.1.0 to tomorrow, today, we'll 
release 4.14.2, then.
-- 
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 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 12:34 p.m., Aleix Pol Gonzalez wrote:
> > I think it's unfortunate, you're giving a mix of technical and usability 
> > reasons to back your patch. In any case, I understand that the bug needs to 
> > be solved and if this is what it takes, then do it.
> > 
> > FWIW, I also think suspend would be good here.

Just out of interest: where am I mixing technical and usability reasons? To me 
the commit message sounds only technical.


- Martin


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


On Oct. 14, 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/120577/
> ---
> 
> (Updated Oct. 14, 2014, 11:45 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Bugs: 339453
> https://bugs.kde.org/show_bug.cgi?id=339453
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[Ivan Čukić]

> also, once what it can do and can't is explained well, the VDG can go crazy
> with ideas for taskbar/launchers

+1

> could the generic kpart patch that was at some point in kdelibs4 then
> removed be in kf5 kparts? would it work with current architecture?

I'm guessing it would work. Don't know whether kpart has changed much or not.


> > 4. Reading API
> > ===

> you want only something very basic or also permitting full sql access?

Depending on the use-cases. I'm guessing we will end up with something close 
to sql, but I don't want to actually give the access to write custom queries 
to the clients.

That would mean freezing the database schema, or at least keeping it back-
compat.


-- 
Cheerio,
Ivan

KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/
gpg key id: 850B6F76, keyserver.pgp.com
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Aleix Pol Gonzalez]

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


I think it's unfortunate, you're giving a mix of technical and usability 
reasons to back your patch. In any case, I understand that the bug needs to be 
solved and if this is what it takes, then do it.

FWIW, I also think suspend would be good here.

- Aleix Pol Gonzalez


On Oct. 14, 2014, 9:45 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 9:45 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Bugs: 339453
> https://bugs.kde.org/show_bug.cgi?id=339453
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[Marco Martin]

On Monday 13 October 2014, Ivan Čukić wrote:
>  - Replacing the 'recent documents' with something more meaningful (kinda a
> subset of the previous item)
>  - Tasks applet and launchers could show the list of important (or recent)
> documents opened in a specific application.
>  - ** more advanced ** Deducing which things belong to each other based on
> the fact they have been often used together and similar.

also, once what it can do and can't is explained well, the VDG can go crazy 
with ideas for taskbar/launchers


> 
> Vishesh asked for the formula for the scoring - see appendix 1.
> 
> Applications that supported this in 4.x were (I'm probably missing a few):
> Dolphin, Gwenview, Calligra (modulo Kexi), Okular, Kate, KWrite and Vim in
> konsole. I have no idea whether the patches remained in Qt5 ports.

could the generic kpart patch that was at some point in kdelibs4 then removed 
be in kf5 kparts? would it work with current architecture?

> 4. Reading API
> ===
> 
> This needs to be designed. I would not be surprised if the API ends up
> being similar to baloo's querying system since it seems we will have quite
> a diverse set of use-cases. Although, it should provide a proper live data
> model for the results.

you want only something very basic or also permitting full sql access?



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

Plasma 5.1 new tars coming..

[Jonathan Riddell]

I just noticed at the last minute that the Plasma tars didn't have
their internal version numbers updated to 5.1.0, the script I wrote to
make that easier must have only updated master and not branch.  I'm
going to reroll the tars now to fix the version number.  Sorry folks.

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

Re: Re: Auto-hiding panels

[Martin Klapetek]

On Tue, Oct 14, 2014 at 12:12 PM, Martin Gräßlin  wrote:

>
> huh? all of that should not be needed. Just continue to move into the same
> direction and it will trigger. Especially there should not be any need to
> do
> the same movement twice as the mouse pointer gets repositioned.
>

Moving the mouse across the screen to the edge stops the cursor at the edge
(even if I continue moving the mouse a bit), the blue glow appears,
instinctively I stop the mouse (as the mouse cursor is not moving anymore)
and at this point I just have to move the mouse again with the same force -
hence the "two slams". To overcome the panel resistance in one single mouse
movement it takes me moving the mouse across half the table here.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Auto-hiding panels

[Martin Gräßlin]

On Tuesday 14 October 2014 11:42:13 Martin Klapetek wrote:
> On Tue, Oct 14, 2014 at 11:27 AM, Marco Martin  wrote:
> > On Tuesday 14 October 2014, Martin Klapetek wrote:
> > > I'd like to change this for Plasma panels to not have any resistance or
> > > very minimal one, basically get it into a state that slamming the mouse
> > > against a screen edge will show the panel easily, without requiring an
> > > additional push.
> > 
> > i'm a bit concerned this would cause a lot of unwanted activations, is the
> > first complain i hear about autohide panels, and the reson back in the
> > days i
> > stopped using them
> 
> In this case it's the 'wanted' activation that's not working too nicely. I
> think that auto-hiding panel that requires two slams against a screen edge
> to appear is just worse to have than couple of unwanted activations.
> 
> As for non-precise pointing devices - this might actually highlight the
> problem even more - you may not be too precise with it, so what you do is
> you slam the pointer towards the edge, that's the easiest thing you can do
> with less-precise devices - drag it/push it strongly in one direction. But
> the current state actually requires careful navigation around the
> screenedge like slow movement towards it or doing the same movement twice
> to trigger the panel, so imo the current situation is even worse with those
> devices (and I'm thinking people with lessened hand mobility, trackballs,
> touchpads and stylus-tablets...what I missed?).

huh? all of that should not be needed. Just continue to move into the same 
direction and it will trigger. Especially there should not be any need to do 
the same movement twice as the mouse pointer gets repositioned.

> 
> There is also another angle to this - we could make the auto-hiding
> algorithm more clever and better handling the unwanted activation - eg. if
> you quickly go to the edge and quickly go out, the hiding delay could be
> minimal, if you stay longer or not move so quickly away from the panel, the
> hiding delay could be longer etc. Eike did some similar stuff in Kicker.

feel free to experiment with improving the screen edge activation :-)

Cheers
Martin

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: wallpapers on lock screen

[Marco Martin]

On Tuesday 14 October 2014, David Edmundson wrote:
> 
> I'd quite like to use the wallpaper plugins from SDDM too; which means
> exposing WallpaperInterface in a slightly different manner than you'd
> probably be wanting to use for the lock screen, as I can't go via a
> Containment.

doesn't even need that wallpaperinterface, just an object with a couple of 
properties exposed, other than that the qml of wallpapers is pretty 
independent

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

Re: The usage statistics [kactivities, baloo, ktp, plasma]

[Eike Hein]

Thanks for starting this :)

Just to recap, here's the stuff I can see myself needing from
the Task Manager and Kicker side:

* Recently used applications across the entire system.
* Most frequently used applications across the entire system.
* Recently installed applications.
* Recently used documents across the entire system.
* Most frequently used documents across the entire system.
* Recently used documents by $application.
* Most used documents by $application.
* Metadata for the recently/most used documents.


So API-wise, that means:
* The ability to query for the above, where the query can
  have operands such as $application, where $application
  could be a KService::Ptr or a KService:menuId()
  for example.
* A good return format for the data that is easily usable
  and easy to bring into model form for QML.
* While I could probably work procedurally for my cases,
  for QML it would be very interesting if the API were to
  support live change notifications.
* Since both Kicker and the Task Managers are launchers
  themselves (including for documents, with DND onto
  launchers), also the API to create usage events, unless
  this is implemented in KRun or similar.
* Recently installed apps would need a new CREATED event
  in KAMD.


So in terms of how to proceed, I think one of us needs to
draw up draft APIs that we can iterate on, and then we need
to somehow turn all the implementation side into work items
between us (ideally on Kanboard or so).

But I'm getting ahead of myself :). Next up is David with
his list of use cases in KTP so we get a more complete pic-
ture of the requirements ...



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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

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

(Updated Oct. 14, 2014, 9:45 a.m.)


Review request for Plasma and Aleix Pol Gonzalez.


Changes
---

Add bug no


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


Repository: plasma-workspace


Description
---

Logging out from the locked screen is impossible. Logging out means
interaction with the session due to the session manager. The session
manager asks all applications to quit and applications are allowed to
ask for example saving changes. The session manager stopps the
logout in this case and asks the window manager to focus this window
and the session manager will only continue the logout once the
application resolved the situation. At any time in this process the
user is still able to abort the logout!

Switching to the application which needs interaction is impossible,
though as the screen is still locked. The result is a seemingly
frozen system as the logout cannot continue and there is no indication
what is going on.

Of course the lock screen cannot unlock the session for the logout as
that would circumvent the security. If the lock screen would unlock
one would just have to click the button and abort the logout really
fast to have the system unlocked. So this is clearly not an option.

The result is: we cannot implement this functionality in a working
and secure manner, so it's better to remove it.


Diffs
-

  lookandfeel/contents/lockscreen/LockScreen.qml 
7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 

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


Testing
---

run kscreenlocker_greeter --testing and locked the screen - button is gone.


Thanks,

Martin Gräßlin

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Eike Hein]

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


This is related to https://bugs.kde.org/show_bug.cgi?id=339453 for the record

- Eike Hein


On Oct. 14, 2014, 5:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 5:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Lukáš Tinkl]

> On Říj. 14, 2014, 9:02 dop., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Auto-hiding panels

[Martin Klapetek]

On Tue, Oct 14, 2014 at 11:27 AM, Marco Martin  wrote:

> On Tuesday 14 October 2014, Martin Klapetek wrote:
> >
> > I'd like to change this for Plasma panels to not have any resistance or
> > very minimal one, basically get it into a state that slamming the mouse
> > against a screen edge will show the panel easily, without requiring an
> > additional push.
>
> i'm a bit concerned this would cause a lot of unwanted activations, is the
> first complain i hear about autohide panels, and the reson back in the
> days i
> stopped using them


In this case it's the 'wanted' activation that's not working too nicely. I
think that auto-hiding panel that requires two slams against a screen edge
to appear is just worse to have than couple of unwanted activations.

As for non-precise pointing devices - this might actually highlight the
problem even more - you may not be too precise with it, so what you do is
you slam the pointer towards the edge, that's the easiest thing you can do
with less-precise devices - drag it/push it strongly in one direction. But
the current state actually requires careful navigation around the
screenedge like slow movement towards it or doing the same movement twice
to trigger the panel, so imo the current situation is even worse with those
devices (and I'm thinking people with lessened hand mobility, trackballs,
touchpads and stylus-tablets...what I missed?).

There is also another angle to this - we could make the auto-hiding
algorithm more clever and better handling the unwanted activation - eg. if
you quickly go to the edge and quickly go out, the hiding delay could be
minimal, if you stay longer or not move so quickly away from the panel, the
hiding delay could be longer etc. Eike did some similar stuff in Kicker.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Auto-hiding panels

[Marco Martin]

On Tuesday 14 October 2014, Martin Klapetek wrote:
> 
> I'd like to change this for Plasma panels to not have any resistance or
> very minimal one, basically get it into a state that slamming the mouse
> against a screen edge will show the panel easily, without requiring an
> additional push.

i'm a bit concerned this would cause a lot of unwanted activations, is the 
first complain i hear about autohide panels, and the reson back in the days i 
stopped using them


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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Auto-hiding panels

[Martin Gräßlin]

On Tuesday 14 October 2014 10:43:42 Martin Klapetek wrote:
> Any opinions/objections?

as I implemented it this way I can share the reasons why I did go for re-using 
the screen edge activation we have for other things. First of all: 
consistency. All edges work the same way and users can expect certain 
behavior: if the glow is shown one has to push against the edge to get 
functionality.

Second reason: multi-usage of the edge: it's possible to use the edge multiple 
times, so it should behave the same way for all of them.

Third reason: preventing unwanted triggering: the auto-hiding panel is there 
for increasing the screen estate. With the panel unhiding without the push 
back it will become difficult to use the newly exposed area. This is 
especially important if one considers that not all pointer devices are very 
precise and not everybody is able to use a pointer device in a precise manner.

Personally I don't care whether there is a pushback or not. From the 
experience over the years with the screen edges I highly recommend to the 
pushback, though.

Cheers
Martin


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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?
> 
> Martin Klapetek wrote:
> > So, the button should also honor that policy?
> 
> The thing is (I think) that having the button exposed 

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.
> 
> Kai Uwe Broulik wrote:
> So, the button should also honor that policy?

> So, the button should also honor that policy?

The thing is (I think) that having the button exposed for user A would allow 
user B to suspend the

Re: 5.1 Errata

[Jonathan Riddell]

On Mon, Oct 13, 2014 at 12:31:19PM -0700, Andrew Lake wrote:
>Can anyone confirm that this bug exists in 5.1? I don't think the fix made
>it in time, but I wanted to check before adding it to the errata.
>https://bugs.kde.org/show_bug.cgi?id=339849

It does exist in the 5.1 tar, you can e-mail release-team@ if you
think packagers should fix it I've made the change in the kubuntu
packages.  You can also ask at sysadmin.kde.org/tickets if you want to
be able to edit bugs on bugs.kde.org.

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Kai Uwe Broulik]

> On Okt. 14, 2014, 7:02 vorm., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> Martin Gräßlin wrote:
> > Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?
> 
> no, as that is controlled by logind. If the system is configured to not 
> allow it, logind won't suspend the system if the lid closes.

So, the button should also honor that policy?


- Kai Uwe


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

Auto-hiding panels

[Martin Klapetek]

Hello,

currently in Plasma5 auto-hidden panels work in a way that it basically
requires mouse slamming either twice or very very hard against the screen
edge which has the panel. Quoting from [1] "This is configurable in KWin.
KWin doesn't trigger screen edges directly, but requires a strong push."

Trying to use this for about a day, it is not as smooth as it could be
because of the screen edge pushback - you slam your mouse towards the edge
but the panel does not appear, only the blue glow, requiring additional
push. It does work however if the mouse is approached slowly to the screen
edge. I suggest to try using it for a while with default setup to get the
feel of it.

I'd like to change this for Plasma panels to not have any resistance or
very minimal one, basically get it into a state that slamming the mouse
against a screen edge will show the panel easily, without requiring an
additional push.

This should be possibly as Martin G. suggests[1]:

* infrastructure supports special cases without a pushback
* client activation could be moved to such a special case without breaking
existing functionality

Any opinions/objections?

[1] - https://bugs.kde.org/show_bug.cgi?id=339203

Cheers
-- 
Martin Klapetek | KDE Developer
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...
> 
> Kai Uwe Broulik wrote:
> Having a suspend button is a security issue but closing the lid, which 
> causes it to suspend, is not?

> Having a suspend button is a security issue but closing the lid, which causes 
> it to suspend, is not?

no, as that is controlled by logind. If the system is configured to not allow 
it, logind won't suspend the system if the lid closes.


- Martin


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


On Oct. 14, 2014, 7:41 a.m

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Kai Uwe Broulik]

> On Okt. 14, 2014, 7:02 vorm., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> Martin Gräßlin wrote:
> > Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...
> 
> yes and no. In a multi-user system you can of course configure the system 
> in a way to not allow suspend/hibernate from login manager.
> 
> It all boils down to: why do we go all the hassle to check whether this 
> options should be enabled from a security point of view, when we allow it for 
> not logged-in users. If we go for allow for not logged in users, we can 
> remove quite a decent amount of code...

Having a suspend button is a security issue but closing the lid, which causes 
it to suspend, is not?


- Kai Uwe


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


On Okt. 14, 2014, 5:41 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Ok

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.
> 
> Martin Klapetek wrote:
> Oh come on, that's hardly any security circumvention. By that logic we 
> should not show battery state, current user's date/time, user name and user 
> picture in the lock screen either because it's exposing things which other 
> users might have restricted access to.
> 
> Plus you said in the very first comment that it's possible to go around 
> this to the login screen and from there anyone can suspend...

> Plus you said in the very first comment that it's possible to go around this 
> to the login screen and from there anyone can suspend...

yes and no. In a multi-user system you can of course configure the system in a 
way to not allow suspend/hibernate from login manager.

It all boils down to: why do we go all the hassle to check whether this options 
should be enabled from a security point of view, when we allow it for not 
logged-in users. If we go for allow for not logged in users, we can remove 
quite a decent amount of code...


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Marco Martin]

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


+1000 from me

- Marco Martin


On Ott. 14, 2014, 5:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Ott. 14, 2014, 5:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)
> 
> Martin Gräßlin wrote:
> > It's not about exposing every option that makes sense, it's about 
> replacing one senseless with one that makes more sense ;)
> 
> I don't see it that way. The option got added in a strange way shortly 
> before the 5.0 release with the maintainers of the screenlocker not having a 
> chance to review it (let's say it simple: if I would have reviewed the code, 
> it would not have gone in, in the first place). So I'm comparing to the last 
> state where it was working which is 4.11 and there the screen locker did not 
> expose such an option and I want to go back to that working state. Let's look 
> from there whether it's a valid option to expose the suspend option and not 
> from the broken state.
> 
> To me it's not a valid use case to expose suspend in the lock screen. To 
> a certain degree it circumvents security. Suspend/Hibernate is allowed on a 
> per-user logged in base. That's implemented by checking whether 
> suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
> it circumvents the check. A not logged in user (or a user who is not allowed 
> to supsend in his session) is able to suspend (multi user system just needs 
> to switch to a logged session which allows suspend). Thus I think from a 
> security perspective the option may not be there in the first place.

Oh come on, that's hardly any security circumvention. By that logic we should 
not show battery state, current user's date/time, user name and user picture in 
the lock screen either because it's exposing things which other users might 
have restricted access to.

Plus you said in the very first comment that it's possible to go around this to 
the login screen and from there anyone can suspend...


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as th

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.
> 
> Martin Klapetek wrote:
> There are still usecases however where either the user does not want/need 
> to close the lid and/or sets his laptop to not suspend on the lid close 
> (personally I have that disabled when on charger). Plus there is the whole 
> non-laptop world. It's not about exposing every option that makes sense, it's 
> about replacing one senseless with one that makes more sense ;)

> It's not about exposing every option that makes sense, it's about replacing 
> one senseless with one that makes more sense ;)

I don't see it that way. The option got added in a strange way shortly before 
the 5.0 release with the maintainers of the screenlocker not having a chance to 
review it (let's say it simple: if I would have reviewed the code, it would not 
have gone in, in the first place). So I'm comparing to the last state where it 
was working which is 4.11 and there the screen locker did not expose such an 
option and I want to go back to that working state. Let's look from there 
whether it's a valid option to expose the suspend option and not from the 
broken state.

To me it's not a valid use case to expose suspend in the lock screen. To a 
certain degree it circumvents security. Suspend/Hibernate is allowed on a 
per-user logged in base. That's implemented by checking whether 
suspend/hibernate is supported at runtime. By exposing it in the screenlocker 
it circumvents the check. A not logged in user (or a user who is not allowed to 
supsend in his session) is able to suspend (multi user system just needs to 
switch to a logged session which allows suspend). Thus I think from a security 
perspective the option may not be there in the first place.


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functional

Re: wallpapers on lock screen

[ctoenn...@interstel.de]

On 14.10.2014 01:01, David Edmundson wrote:



On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin > wrote:



on either case, should be very easy to recycle the complete wallpaper
mechanism of plasmashell, even the qml only wallpapers (that if
animated..
yay, screensavers!)


I'd quite like to use the wallpaper plugins from SDDM too; which means 
exposing WallpaperInterface in a slightly different manner than you'd 
probably be wanting to use for the lock screen, as I can't go via a 
Containment.


+1
for extending the lockscreen kcm to work/look similar in picking a 
different background for a chosen theme like sddm kcm.


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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> Martin Gräßlin wrote:
> > Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/
> 
> At least my notebook(s) have a visible LED indicating it is in sleep mode.

There are still usecases however where either the user does not want/need to 
close the lid and/or sets his laptop to not suspend on the lid close 
(personally I have that disabled when on charger). Plus there is the whole 
non-laptop world. It's not about exposing every option that makes sense, it's 
about replacing one senseless with one that makes more sense ;)


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)
> 
> Kai Uwe Broulik wrote:
> Although closing the lid apparently reliably suspends the device, even 
> when locked, my gut makes me not trust it. :/

> Although closing the lid apparently reliably suspends the device, even when 
> locked, my gut makes me not trust it. :/

At least my notebook(s) have a visible LED indicating it is in sleep mode.


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Kai Uwe Broulik]

> On Okt. 14, 2014, 7:02 vorm., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.
> 
> Martin Gräßlin wrote:
> I expected this question to come :-) - I'm not sure whether it's a valid 
> use case, at least for laptops. Closing the lid should send it to suspend, 
> the suspend button should still work (if not, we should fix it). So there are 
> already quite some decent ways to get the system to suspend when locked. 
> Especially with lid closing it does what it's supposed to do.
> 
> In fact the functionality should even be available through the Change 
> Session functionality as that drops you to the login manager where you can 
> suspend. Sure not as comfortable as directly exposing it. But we don't need 
> to expose every option which might make sense ;-)

Although closing the lid apparently reliably suspends the device, even when 
locked, my gut makes me not trust it. :/


- Kai Uwe


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


On Okt. 14, 2014, 5:41 vorm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Okt. 14, 2014, 5:41 vorm.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Gräßlin]

> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote:
> > Could we possibly get "Suspend" button instead? Suspend stores the session 
> > state into memory and then restores it without any issues (and we lock 
> > screen on wakeup anyway); many times I have found my laptop with locked 
> > screen and I had to unlock, click the suspend button in the panel only to 
> > get it locked again and suspended.

I expected this question to come :-) - I'm not sure whether it's a valid use 
case, at least for laptops. Closing the lid should send it to suspend, the 
suspend button should still work (if not, we should fix it). So there are 
already quite some decent ways to get the system to suspend when locked. 
Especially with lid closing it does what it's supposed to do.

In fact the functionality should even be available through the Change Session 
functionality as that drops you to the login manager where you can suspend. 
Sure not as comfortable as directly exposing it. But we don't need to expose 
every option which might make sense ;-)


- Martin


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


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel

[Martin Klapetek]

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


Could we possibly get "Suspend" button instead? Suspend stores the session 
state into memory and then restores it without any issues (and we lock screen 
on wakeup anyway); many times I have found my laptop with locked screen and I 
had to unlock, click the suspend button in the panel only to get it locked 
again and suspended.

- Martin Klapetek


On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120577/
> ---
> 
> (Updated Oct. 14, 2014, 7:41 a.m.)
> 
> 
> Review request for Plasma and Aleix Pol Gonzalez.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Logging out from the locked screen is impossible. Logging out means
> interaction with the session due to the session manager. The session
> manager asks all applications to quit and applications are allowed to
> ask for example saving changes. The session manager stopps the
> logout in this case and asks the window manager to focus this window
> and the session manager will only continue the logout once the
> application resolved the situation. At any time in this process the
> user is still able to abort the logout!
> 
> Switching to the application which needs interaction is impossible,
> though as the screen is still locked. The result is a seemingly
> frozen system as the logout cannot continue and there is no indication
> what is going on.
> 
> Of course the lock screen cannot unlock the session for the logout as
> that would circumvent the security. If the lock screen would unlock
> one would just have to click the button and abort the logout really
> fast to have the system unlocked. So this is clearly not an option.
> 
> The result is: we cannot implement this functionality in a working
> and secure manner, so it's better to remove it.
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/lockscreen/LockScreen.qml 
> 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d 
> 
> Diff: https://git.reviewboard.kde.org/r/120577/diff/
> 
> 
> Testing
> ---
> 
> run kscreenlocker_greeter --testing and locked the screen - button is gone.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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