Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- 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
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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
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
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: wallpapers on lock screen
On 14.10.2014 01:01, David Edmundson wrote: On Mon, Oct 13, 2014 at 4:09 PM, Marco Martin notm...@gmail.com mailto:notm...@gmail.com 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
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 functionality in a working and secure manner, so it's better to remove it. Diffs
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 the screen is still locked. The result is a seemingly frozen system as the logout cannot
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- 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
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 the locked screen is impossible. Logging out means interaction with the session due to the
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 Okt. 14, 2014, 5:41 vorm.) Review request for Plasma and Aleix Pol Gonzalez.
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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., Martin Gräßlin wrote: --- This
Auto-hiding panels
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
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/#review68345 --- On Okt. 14, 2014, 5:41 vorm.,
Re: 5.1 Errata
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
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 session while user B has it restricted. But I think that at that very point closing the lid would
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Auto-hiding panels
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
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Auto-hiding panels
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: Auto-hiding panels
On Tue, Oct 14, 2014 at 11:27 AM, Marco Martin notm...@gmail.com 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: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
--- 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
--- 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: The usage statistics [kactivities, baloo, ktp, plasma]
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: wallpapers on lock screen
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: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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 for user A would allow user B to suspend the session while user B has it restricted. But I think that at
Re: Re: Auto-hiding panels
On Tuesday 14 October 2014 11:42:13 Martin Klapetek wrote: On Tue, Oct 14, 2014 at 11:27 AM, Marco Martin notm...@gmail.com 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: Re: Auto-hiding panels
On Tue, Oct 14, 2014 at 12:12 PM, Martin Gräßlin mgraess...@kde.org 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
Plasma 5.1 new tars coming..
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: The usage statistics [kactivities, baloo, ktp, plasma]
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
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: Plasma 5.1 new tars coming..
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: Re: Re: Auto-hiding panels
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: Review Request 120577: Remove shutdown option from lockscreen's look and feel
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: Review Request 120471: Add Registry::sync() signal
--- 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: Plasma 5.1 new tars coming..
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 120579: [KWayland] Install headers for WaylandServer
--- 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 120579: [KWayland] Install headers for WaylandServer
--- 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
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
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
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #16 from Vincent Petry pvinc...@yahoo.fr --- Created attachment 89126 -- https://bugs.kde.org/attachment.cgi?id=89126action=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
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.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #17 from Vincent Petry pvinc...@yahoo.fr --- 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
[Powerdevil] [Bug 339391] system hangs during suspend-to-ram (must poweroff), while pm-suspend works.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #18 from Vincent Petry pvinc...@yahoo.fr --- 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.
https://bugs.kde.org/show_bug.cgi?id=339391 --- Comment #19 from Roberto figj...@libero.it --- 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
Re: Review Request 120579: [KWayland] Install headers for WaylandServer
--- 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
Re: Review Request 120579: [KWayland] Install headers for WaylandServer
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
Review Request 120581: Don't crash if the plasmoid wasn't properly loaded
--- 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 120581: Don't crash if the plasmoid wasn't properly loaded
--- 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
Re: Review Request 120579: [KWayland] Install headers for WaylandServer
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 120579: [KWayland] Install headers for WaylandServer
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 120581: Don't crash if the plasmoid wasn't properly loaded
--- 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: Auto-hiding panels
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 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote: src/quickaddons/managedtexturenode.h, line 52 https://git.reviewboard.kde.org/r/120550/diff/2/?file=318205#file318205line52 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: Review Request 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120550/#review68396 --- src/quickaddons/imagetexturescache.h https://git.reviewboard.kde.org/r/120550/#comment47668 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
Build failed in Jenkins: plasma-workspace_master_qt5 #973
See http://build.kde.org/job/plasma-workspace_master_qt5/973/changes 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 command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line: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 command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line: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 command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line: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 http://build.kde.org/job/plasma-workspace_master_qt5/ws/systemmonitor/kdedksysguard.cpp:39:1: warning: unused parameter ‘parent’ [-Wunused-parameter] KDEDKSysGuard::KDEDKSysGuard(QObject* parent, const QVariantList) ^ [ 45%] Building CXX object
Review Request 120584: Don't position the panel until it's about to be displayed
--- 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 #974
See http://build.kde.org/job/plasma-workspace_master_qt5/974/changes Changes: [mart] Make apply button work correctly -- [...truncated 2293 lines...] const QSetSolid::PowerManagement::SleepState spdMethods = Solid::PowerManagement::supportedSleepStates(); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp:144:110: warning: ‘QSetSolid::PowerManagement::SleepState 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 QSetSolid::PowerManagement::SleepState spdMethods = Solid::PowerManagement::supportedSleepStates(); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: In member function ‘void ScreenLocker::UnlockApp::suspendToRam()’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: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); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: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); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: In member function ‘void ScreenLocker::UnlockApp::suspendToDisk()’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: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); ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/greeterapp.cpp: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 command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line: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 command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line: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
Re: Review Request 120584: Don't position the panel until it's about to be displayed
--- 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
Re: Review Request 120584: Don't position the panel until it's about to be displayed
--- 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
--- 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
--- 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
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: Auto-hiding panels
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 120550: Use the same strategy as FrameSvgItem and IconItem in QIconItem
On Oct. 13, 2014, 1:35 p.m., Marco Martin wrote: src/quickaddons/managedtexturenode.h, line 52 https://git.reviewboard.kde.org/r/120550/diff/2/?file=318205#file318205line52 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: Review Request 120564: Write default file manager into mimeapps.list in XDG_CONFIG_HOME
--- 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.gita=commith=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: Fwd: Plasma Framework problems
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
