[Breeze] [Bug 339849] Can't set breeze dark color scheme
https://bugs.kde.org/show_bug.cgi?id=339849 Hugo Pereira Da Costa hugo.pere...@free.fr changed: What|Removed |Added Latest Commit|http://commits.kde.org/bree |http://commits.kde.org/bree |ze/04031cec8bd9ddab3f5e0d7d |ze/f58e7d0523f1c93a74046d9e |245a17e27b45d30a|cac82c72f0068c89 --- Comment #5 from Hugo Pereira Da Costa hugo.pere...@free.fr --- Git commit f58e7d0523f1c93a74046d9ecac82c72f0068c89 by Hugo Pereira Da Costa, on behalf of Andrew Lake. Committed on 11/10/2014 at 06:16. Pushed by hpereiradacosta into branch 'hpereira/kwin-decoration'. rename Breeze-Dark.colors to BreezeDark.colors M +1-1CMakeLists.txt R +0-0colors/BreezeDark.colors [from: colors/Breeze-Dark.colors - 100% similarity] http://commits.kde.org/breeze/f58e7d0523f1c93a74046d9ecac82c72f0068c89 -- 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 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
[Breeze] [Bug 339849] Can't set breeze dark color scheme
https://bugs.kde.org/show_bug.cgi?id=339849 Jonathan Riddell j...@jriddell.org changed: What|Removed |Added CC||j...@jriddell.org --- Comment #6 from Jonathan Riddell j...@jriddell.org --- this was fixed in the final 5.1 packages (versioned 5.1.0.1) -- 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 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 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/ --- (Updated Oct. 15, 2014, 10:50 a.m.) Status -- This change has been marked as submitted. 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
Review Request 120596: Adopt QuickAddons in plasma-framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Removes the code that was moved to QuickAddons Diffs - src/declarativeimports/core/framesvgitem.cpp bb4dc69 src/declarativeimports/core/iconitem.cpp 4f3d5d6 src/declarativeimports/core/svgitem.cpp 50807d4 src/declarativeimports/core/svgtexturenode.h 8cc7bb3 src/plasmaquick/CMakeLists.txt a10beab src/declarativeimports/core/CMakeLists.txt 9aba919 src/declarativeimports/core/framesvgitem.h 73494d4 Diff: https://git.reviewboard.kde.org/r/120596/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ 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, 7: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
Review Request 120597: Fix warnings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120597/ --- Review request for Plasma. Repository: plasma-desktop Description --- Whenever showing the panel settings I got this warning: file:///home/kde-devel/kde5/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:183: ReferenceError: minimumWidthChanged is not defined This patch fixes this warning and also some rendering issues in the panel's settings dialog, where the buttons would have different sizes when laid out vertically. Diffs - desktoppackage/contents/views/Panel.qml e05d3b9 Diff: https://git.reviewboard.kde.org/r/120597/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120596: Adopt QuickAddons in plasma-framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/#review68445 --- Ship it! Inviala! - Marco Martin On Ott. 15, 2014, 10:50 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/ --- (Updated Ott. 15, 2014, 10:50 a.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Removes the code that was moved to QuickAddons Diffs - src/declarativeimports/core/framesvgitem.cpp bb4dc69 src/declarativeimports/core/iconitem.cpp 4f3d5d6 src/declarativeimports/core/svgitem.cpp 50807d4 src/declarativeimports/core/svgtexturenode.h 8cc7bb3 src/plasmaquick/CMakeLists.txt a10beab src/declarativeimports/core/CMakeLists.txt 9aba919 src/declarativeimports/core/framesvgitem.h 73494d4 Diff: https://git.reviewboard.kde.org/r/120596/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120597: Fix warnings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120597/#review68446 --- Ship it! Inviala! - Marco Martin On Ott. 15, 2014, 10:58 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120597/ --- (Updated Ott. 15, 2014, 10:58 a.m.) Review request for Plasma. Repository: plasma-desktop Description --- Whenever showing the panel settings I got this warning: file:///home/kde-devel/kde5/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:183: ReferenceError: minimumWidthChanged is not defined This patch fixes this warning and also some rendering issues in the panel's settings dialog, where the buttons would have different sizes when laid out vertically. Diffs - desktoppackage/contents/views/Panel.qml e05d3b9 Diff: https://git.reviewboard.kde.org/r/120597/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ 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
Build failed in Jenkins: plasma-workspace_master_qt5 #975
See http://build.kde.org/job/plasma-workspace_master_qt5/975/changes Changes: [notmart] remove bypasswindowmanagerhint -- [...truncated 2343 lines...] [ 39%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/clipcommandprocess.cpp.o Scanning dependencies of target ksldTest [ 39%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/ksldTest.dir/ksldtest.cpp.o Linking CXX executable keyboardGrabber Scanning dependencies of target lockWindowTest [ 39%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o [ 39%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/klippersettings.cpp.o Scanning dependencies of target logindTest [ 39%] [ 39%] Built target keyboardGrabber [ 39%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 39%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Linking CXX shared library libkdeinit5_klipper.so [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o Linking CXX shared module screenlocker_kcm.so [ 40%] Built target kdeinit_klipper [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/ksldTest.dir/ksldTest_automoc.cpp.o Scanning dependencies of target pointerGrabber [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o [ 41%] Built target screenlocker_kcm [ 41%] [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/clipboardengine.cpp.o [ 41%] [ 42%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/clipboardservice.cpp.o Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/__/logind.cpp.o Linking CXX executable ksldTest [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindTest_automoc.cpp.o [ 42%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/clipboardjob.cpp.o Scanning dependencies of target kscreenlocker_test [ 42%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_main.cpp.o Linking CXX executable lockWindowTest [ 42%] Built target ksldTest [ 42%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_test_automoc.cpp.o Linking CXX executable pointerGrabber [ 42%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/plasma_engine_clipboard_automoc.cpp.o [ 42%] Built target lockWindowTest Scanning dependencies of target ksplashqml [ 42%] Built target pointerGrabber [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o Scanning dependencies of target kded_ksysguard [ 42%] Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o Scanning dependencies of target systemmonitor [ 43%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/ksystemactivitydialog.cpp.o [ 43%] Generating statusnotifieritem_interface.cpp, statusnotifieritem_interface.h [ 43%] [ 43%] Generating statusnotifierwatcheradaptor.cpp, statusnotifierwatcheradaptor.h Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kded_ksysguard_automoc.cpp.o [ 43%] Generating statusnotifierwatcheradaptor.moc [ 43%] Generating statusnotifieritem_interface.moc Scanning dependencies of target kded_statusnotifierwatcher Linking CXX executable kscreenlocker_test [ 43%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcher.cpp.o Linking CXX executable logindTest [ 44%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcheradaptor.cpp.o [ 44%] Built target kscreenlocker_test [ 44%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifieritem_interface.cpp.o [ 44%] Built target logindTest [ 44%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/kded_statusnotifierwatcher_automoc.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) ^ [ 44%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashApp.cpp.o [ 44%] Generating klauncher_iface.cpp, klauncher_iface.h [ 44%] Generating klauncher_iface.moc Linking CXX shared module kded_ksysguard.so Scanning dependencies of target kdeinit_kcminit [ 44%] Building CXX object startkde/kcminit/CMakeFiles/kdeinit_kcminit.dir/main.cpp.o
Re: Review Request 120597: Fix warnings
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120597/ --- (Updated Oct. 15, 2014, 11:21 a.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-desktop Description --- Whenever showing the panel settings I got this warning: file:///home/kde-devel/kde5/share/plasma/shells/org.kde.plasma.desktop/contents/views/Panel.qml:183: ReferenceError: minimumWidthChanged is not defined This patch fixes this warning and also some rendering issues in the panel's settings dialog, where the buttons would have different sizes when laid out vertically. Diffs - desktoppackage/contents/views/Panel.qml e05d3b9 Diff: https://git.reviewboard.kde.org/r/120597/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120596: Adopt QuickAddons in plasma-framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120596/ --- (Updated Oct. 15, 2014, 11:24 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Removes the code that was moved to QuickAddons Diffs - src/declarativeimports/core/framesvgitem.cpp bb4dc69 src/declarativeimports/core/iconitem.cpp 4f3d5d6 src/declarativeimports/core/svgitem.cpp 50807d4 src/declarativeimports/core/svgtexturenode.h 8cc7bb3 src/plasmaquick/CMakeLists.txt a10beab src/declarativeimports/core/CMakeLists.txt 9aba919 src/declarativeimports/core/framesvgitem.h 73494d4 Diff: https://git.reviewboard.kde.org/r/120596/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build became unstable: plasma-desktop_master_qt5 #727
See http://build.kde.org/job/plasma-desktop_master_qt5/727/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is still unstable: plasma-desktop_master_qt5 #728
See http://build.kde.org/job/plasma-desktop_master_qt5/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is still unstable: plasma-desktop_master_qt5 #729
See http://build.kde.org/job/plasma-desktop_master_qt5/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Build failed in Jenkins: plasma-workspace_master_qt5 #976
See http://build.kde.org/job/plasma-workspace_master_qt5/976/changes Changes: [notmart] signal availableScreenRectChanged on type change -- [...truncated 2298 lines...] ^ Scanning dependencies of target fakekcheckpass Scanning dependencies of target authenticatorTest [ 39%] Building C object ksmserver/screenlocker/greeter/autotests/CMakeFiles/fakekcheckpass.dir/fakekcheckpass.c.o [ 39%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/authenticatorTest.dir/authenticatortest.cpp.o Scanning dependencies of target killTest [ 39%] [ 39%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/killTest.dir/killtest.cpp.o [ 40%] http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/autotests/fakekcheckpass.c: In function ‘main’: http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/autotests/fakekcheckpass.c:219:18: warning: variable ‘username’ set but not used [-Wunused-but-set-variable] const char*username = 0; ^ http://build.kde.org/job/plasma-workspace_master_qt5/ws/ksmserver/screenlocker/greeter/autotests/fakekcheckpass.c:218:18: warning: variable ‘method’ set but not used [-Wunused-but-set-variable] const char*method = classic; ^ Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/screenlocker_static_automoc.cpp.o Generating screenlocker_interface.cpp, screenlocker_interface.h [ 40%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/killTest.dir/killTest_automoc.cpp.o [ 40%] [ 40%] Generating ui_kcm.h Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/fakekcheckpass.dir/fakekcheckpass_automoc.cpp.o [ 40%] Generating kscreensaversettings.h, kscreensaversettings.cpp Linking CXX executable fakekcheckpass [ 40%] [ 41%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/authenticatorTest.dir/__/authenticator.cpp.o Generating screenlocker_interface.moc [ 41%] Built target fakekcheckpass [ 41%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/authenticatorTest.dir/authenticatorTest_automoc.cpp.o [ 41%] Scanning dependencies of target screenlocker_kcm Building CXX object klipper/CMakeFiles/kdeinit_klipper.dir/tray.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kcm.cpp.o [ 41%] 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 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 executable kscreenlocker_greet Scanning dependencies of target keyboardGrabber [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardgrabber.cpp.o [ 41%] Built target kscreenlocker_greet [ 41%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/screenlocker_interface.cpp.o Scanning dependencies of target lockWindowTest command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o Linking CXX static library libscreenlocker_static.a Linking CXX executable killTest [ 41%] Built target screenlocker_static Linking CXX executable authenticatorTest [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 41%] Built target killTest [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o [ 42%] Built target authenticatorTest [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardGrabber_automoc.cpp.o [ 42%] Building CXX object klipper/CMakeFiles/kdeinit_klipper.dir/kdeinit_klipper_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 Linking CXX executable keyboardGrabber Scanning dependencies of target logindTest [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o [ 42%] Built target keyboardGrabber [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Scanning dependencies of target pointerGrabber [ 42%] Building CXX object
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/ --- (Updated Oct. 15, 2014, 1:54 p.m.) Review request for Plasma. Changes --- I took another go at the problem because I realized that this patch only fixed the issue if I had the panel laid out horizontally. Reasoning:Consider 2 screens laid out horizontally, we want to have the panel at the right screen, vertically at the right. (1280x800 and 1920x1080) The problem is probably on KWin (or somewhere outside plasma anyway) because we would put the panel at 0x0, then set the window to the geometry and screen. What QtXcb was receiving was: 0: QRect(0,0 12x12) 1: QRect(3146,0 53x1080) which is taking the wrong window width 2: QRect(1226,0 53x1080) 0 is the initial window size, 1 happened when reparenting the containment into the panel. Then given that 1 wasn't considered to be on any screen (note that 3146-1920-1280=-54, and we needed 53), then the window was moved to the primaryScreen. Because Qt knows best 3. Now this patch makes sure we're initializing the window in the correct place, so that Qt needs to do less magic, by positioning the panel before reparenting the containment QQuickItem into the panel, which is when things started to move around. Also I saw that we were initializing the position considering the 12x12 instead of the panel thickness, which was causing also this window kicking. Use the proper size. Bugs: 339672 https://bugs.kde.org/show_bug.cgi?id=339672 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 (updated) - shell/panelview.cpp 9260c18 shell/shellcorona.cpp ba66d46 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/#review68453 --- Ship it! Inviala! - Marco Martin On Ott. 15, 2014, 1:54 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. 15, 2014, 1:54 p.m.) Review request for Plasma. Bugs: 339672 https://bugs.kde.org/show_bug.cgi?id=339672 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 shell/shellcorona.cpp ba66d46 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
Jenkins build is back to stable : plasma-desktop_master_qt5 #730
See http://build.kde.org/job/plasma-desktop_master_qt5/730/changes ___ 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/#review68455 --- I consider it as highly unlikely that KWin positioned the panel unless it (or Qt) was doing something wrong. The panel should request a position and KWin honors that and as it's a panel there is nothing which should make KWin in applying any rules. Anyway: if you have the feeling it could be KWin I recommend to pick a different window manager for the test (e.g. OpenBox). If you see the same or similar results one can rule out the WM. - Martin Gräßlin On Oct. 15, 2014, 3:54 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. 15, 2014, 3:54 p.m.) Review request for Plasma. Bugs: 339672 https://bugs.kde.org/show_bug.cgi?id=339672 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 shell/shellcorona.cpp ba66d46 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 Oct. 15, 2014, 2:06 p.m., Martin Gräßlin wrote: I consider it as highly unlikely that KWin positioned the panel unless it (or Qt) was doing something wrong. The panel should request a position and KWin honors that and as it's a panel there is nothing which should make KWin in applying any rules. Anyway: if you have the feeling it could be KWin I recommend to pick a different window manager for the test (e.g. OpenBox). If you see the same or similar results one can rule out the WM. Correct, that was written before I changed the positionPanel width()-thickness(). Sorry about that, my fault. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120584/#review68455 --- On Oct. 15, 2014, 1:54 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. 15, 2014, 1:54 p.m.) Review request for Plasma. Bugs: 339672 https://bugs.kde.org/show_bug.cgi?id=339672 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 shell/shellcorona.cpp ba66d46 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 #977
See http://build.kde.org/job/plasma-workspace_master_qt5/977/changes Changes: [bhush94] Remove config action for activity bar and panelspacer -- [...truncated 2327 lines...] [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardgrabber.cpp.o Linking CXX static library libscreenlocker_static.a Scanning dependencies of target screenlocker_kcm [ 40%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kcm.cpp.o Scanning dependencies of target lockWindowTest 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/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o [ 40%] Built target screenlocker_static [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardGrabber_automoc.cpp.o [ 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 executable keyboardGrabber Linking CXX shared module plasma_engine_clipboard.so [ 40%] Built target keyboardGrabber [ 40%] 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 Linking CXX executable killTest Linking CXX executable kscreenlocker_greet [ 41%] Built target plasma_engine_clipboard [ 41%] Built target killTest Scanning dependencies of target logindTest [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o Scanning dependencies of target pointerGrabber [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o [ 42%] Built target kscreenlocker_greet Scanning dependencies of target kscreenlocker_test [ 42%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_main.cpp.o Scanning dependencies of target ksplashqml [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashApp.cpp.o [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashWindow.cpp.o Linking CXX executable pointerGrabber [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/ksplashqml_automoc.cpp.o [ 42%] Built target pointerGrabber [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Linking CXX executable lockWindowTest Linking CXX shared module screenlocker_kcm.so [ 42%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_test_automoc.cpp.o [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/__/logind.cpp.o [ 42%] Built target lockWindowTest Linking CXX executable kscreenlocker_test Scanning dependencies of target kded_ksysguard [ 42%] Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o [ 42%] Built target screenlocker_kcm [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindTest_automoc.cpp.o Scanning dependencies of target systemmonitor [ 43%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/ksystemactivitydialog.cpp.o [ 43%] Generating statusnotifieritem_interface.cpp, statusnotifieritem_interface.h [ 43%] [ 43%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/main.cpp.o Generating statusnotifierwatcheradaptor.cpp, statusnotifierwatcheradaptor.h [ 43%] Generating statusnotifieritem_interface.moc [ 43%] Generating statusnotifierwatcheradaptor.moc [ 43%] Built target kscreenlocker_test [ 43%] Generating klauncher_iface.cpp, klauncher_iface.h Scanning dependencies of target kded_statusnotifierwatcher [ 43%] [ 43%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcher.cpp.o Generating
Jenkins build became unstable: plasma-desktop_master_qt5 #731
See http://build.kde.org/job/plasma-desktop_master_qt5/731/ ___ 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/ --- (Updated Oct. 15, 2014, 3:15 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Bugs: 339672 https://bugs.kde.org/show_bug.cgi?id=339672 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 shell/shellcorona.cpp ba66d46 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 #978
See http://build.kde.org/job/plasma-workspace_master_qt5/978/changes Changes: [aleixpol] --debug [aleixpol] Ensure the panel is not placed outside the screen [aleixpol] Ensure we are setting the Panel position when the containment changes -- [...truncated 2311 lines...] ^ 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); ^ [ 38%] Building CXX object shell/CMakeFiles/plasmashell.dir/plasmashell_automoc.cpp.o [ 38%] Building CXX object ksmserver/screenlocker/greeter/autotests/CMakeFiles/killTest.dir/killTest_automoc.cpp.o [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/qrc_fallbacktheme.cpp.o [ 39%] Built target kdeinit_klipper [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreensaversettings.cpp.o [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreenlocker_greet_automoc.cpp.o [ 39%] Generating screenlocker_interface.cpp, screenlocker_interface.h [ 39%] Generating ui_kcm.h [ 40%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/screenlocker_static_automoc.cpp.o [ 40%] Generating kscreensaversettings.h, kscreensaversettings.cpp [ 41%] Generating screenlocker_interface.moc Scanning dependencies of target keyboardGrabber [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardgrabber.cpp.o Scanning dependencies of target lockWindowTest [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o Scanning dependencies of target logindTest [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o Scanning dependencies of target screenlocker_kcm [ 41%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kcm.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 executable killTest [ 41%] Scanning dependencies of target pointerGrabber Built target killTest [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardGrabber_automoc.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o [ 41%] 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 Linking CXX executable keyboardGrabber Linking CXX executable plasmashell Linking CXX executable kscreenlocker_greet [ 41%] Built target keyboardGrabber [ 41%] 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 static library libscreenlocker_static.a [ 41%] Built target screenlocker_static [ 41%] 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 Linking CXX executable pointerGrabber [ 41%] Built target kscreenlocker_greet [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 41%] [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Built target plasmashell [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o [ 42%] Built target pointerGrabber Scanning dependencies of target ksplashqml [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o Scanning dependencies of target kded_ksysguard [ 42%] Scanning dependencies of target systemmonitor Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o [ 43%] Building CXX object
Jenkins build is still unstable: plasma-desktop_master_qt5 #732
See http://build.kde.org/job/plasma-desktop_master_qt5/changes ___ 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/#review68501 --- Relevant code in greeterapp needs removing too. There's a property and a slot ::shutdown() Interestingly the canShutDown is based on whether the user can logout which is a bit random. - David Edmundson 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
Jenkins build is still unstable: plasma-desktop_master_qt5 #733
See http://build.kde.org/job/plasma-desktop_master_qt5/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Build failed in Jenkins: plasma-workspace_master_qt5 #979
See http://build.kde.org/job/plasma-workspace_master_qt5/979/changes Changes: [aleixpol] Actively enforce that the panel is smaller than the screen. -- [...truncated 2324 lines...] 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 executable keyboardGrabber Linking CXX executable authenticatorTest [ 38%] Built target authenticatorTest [ 38%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/screenlocker_kcm_automoc.cpp.o [ 38%] Scanning dependencies of target lockWindowTest Built target keyboardGrabber 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/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o [ 38%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/logind.cpp.o [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/qrc_fallbacktheme.cpp.o [ 39%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 39%] Building CXX object klipper/CMakeFiles/plasma_engine_clipboard.dir/plasma_engine_clipboard_automoc.cpp.o Linking CXX executable testsh [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreensaversettings.cpp.o [ 39%] [ 39%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreenlocker_greet_automoc.cpp.o Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/screensaveradaptor.cpp.o [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o Linking CXX shared module screenlocker_kcm.so [ 40%] Built target testsh Scanning dependencies of target logindTest [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o [ 40%] Built target screenlocker_kcm Scanning dependencies of target pointerGrabber [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o Scanning dependencies of target ksplashqml [ 40%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/kscreensaveradaptor.cpp.o [ 40%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Linking CXX executable lockWindowTest Linking CXX shared module plasma_engine_clipboard.so [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o [ 40%] Built target lockWindowTest [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/__/logind.cpp.o Linking CXX executable pointerGrabber [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindTest_automoc.cpp.o [ 40%] Linking CXX executable kscreenlocker_greet Built target pointerGrabber [ 41%] Built target plasma_engine_clipboard Scanning dependencies of target kded_ksysguard Scanning dependencies of target systemmonitor [ 42%] [ 42%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/ksystemactivitydialog.cpp.o Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o [ 42%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/main.cpp.o [ 42%] Built target kscreenlocker_greet [ 42%] [ 42%] Generating statusnotifieritem_interface.cpp, statusnotifieritem_interface.h Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashApp.cpp.o [ 42%] Generating statusnotifierwatcheradaptor.cpp, statusnotifierwatcheradaptor.h [ 42%] [ 42%] Generating statusnotifierwatcheradaptor.moc Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/kscreensaversettings.cpp.o [ 42%] Generating statusnotifieritem_interface.moc [ 42%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/ksmserver_interface.cpp.o Scanning dependencies of target kded_statusnotifierwatcher [ 42%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/powerdevilpolicyagent.cpp.o [ 42%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcher.cpp.o Linking CXX executable logindTest 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) ^ [ 42%] [ 43%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/systemmonitor_automoc.cpp.o Building CXX object
Re: Review Request 120577: Remove shutdown option from lockscreen's look and feel
On Okt. 15, 2014, 8:30 nachm., David Edmundson wrote: Relevant code in greeterapp needs removing too. There's a property and a slot ::shutdown() Interestingly the canShutDown is based on whether the user can logout which is a bit random. Relevant code in greeterapp needs removing too. all right, will update. Interestingly the canShutDown is based on whether the user can logout which is a bit random. yeah, I thought so as well when reading the documentation. What would be cool is to tell logind that currently the screen is locked and that logind behaves like there is no active session in that case. Maybe worth to take to their mailing list? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- On Okt. 14, 2014, 11:45 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, 11:45 vorm.) Review request for Plasma and Aleix Pol Gonzalez. Bugs: 339453 https://bugs.kde.org/show_bug.cgi?id=339453 Repository: plasma-workspace Description --- Logging out from the locked screen is impossible. Logging out means interaction with the session due to the session manager. The session manager asks all applications to quit and applications are allowed to ask for example saving changes. The session manager stopps the logout in this case and asks the window manager to focus this window and the session manager will only continue the logout once the application resolved the situation. At any time in this process the user is still able to abort the logout! Switching to the application which needs interaction is impossible, though as the screen is still locked. The result is a seemingly frozen system as the logout cannot continue and there is no indication what is going on. Of course the lock screen cannot unlock the session for the logout as that would circumvent the security. If the lock screen would unlock one would just have to click the button and abort the logout really fast to have the system unlocked. So this is clearly not an option. The result is: we cannot implement this functionality in a working and secure manner, so it's better to remove it. Diffs - lookandfeel/contents/lockscreen/LockScreen.qml 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d Diff: https://git.reviewboard.kde.org/r/120577/diff/ Testing --- run kscreenlocker_greeter --testing and locked the screen - button is gone. Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120602: Fix glitching Alternatives dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120602/ --- Review request for Plasma and Marco Martin. Bugs: 340003 https://bugs.kde.org/show_bug.cgi?id=340003 Repository: plasma-desktop Description --- Fixes a porting oversight and also takes into account the buttons and heading. Apparently when a dialog does not explicitly set a mainItem, the Dialog tries to guess the size from the children of the dialog which was anchors.fill and then it got confused. Diffs - desktoppackage/contents/explorer/AppletAlternatives.qml 4e97dc9 Diff: https://git.reviewboard.kde.org/r/120602/diff/ Testing --- Dialog flies in smoothly trying to display the list without scrollbars but is still properly max'd to not fill the entire screen. Thanks, Kai Uwe Broulik ___ 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. 15, 2014, 6:30 p.m., David Edmundson wrote: Relevant code in greeterapp needs removing too. There's a property and a slot ::shutdown() Interestingly the canShutDown is based on whether the user can logout which is a bit random. Martin Gräßlin wrote: Relevant code in greeterapp needs removing too. all right, will update. Interestingly the canShutDown is based on whether the user can logout which is a bit random. yeah, I thought so as well when reading the documentation. What would be cool is to tell logind that currently the screen is locked and that logind behaves like there is no active session in that case. Maybe worth to take to their mailing list? We already do tell logind that the session is locked (or at least we should be), but as you pointed out earlier canShutdown is user based not session based so it doesn't really end up helping. It's worth an email, they might have a plan or at least they would want to know where logind maybe misses something for when they make v2. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- 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 120602: Fix glitching Alternatives dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120602/#review68516 --- Ship it! the patch is ok, however the fact that if a mainITem is not explicitly set the behavior is different reveals some weird underlying problem. (it's the default property, *should* be the same) - Marco Martin On Ott. 15, 2014, 8:23 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120602/ --- (Updated Ott. 15, 2014, 8:23 p.m.) Review request for Plasma and Marco Martin. Bugs: 340003 https://bugs.kde.org/show_bug.cgi?id=340003 Repository: plasma-desktop Description --- Fixes a porting oversight and also takes into account the buttons and heading. Apparently when a dialog does not explicitly set a mainItem, the Dialog tries to guess the size from the children of the dialog which was anchors.fill and then it got confused. Diffs - desktoppackage/contents/explorer/AppletAlternatives.qml 4e97dc9 Diff: https://git.reviewboard.kde.org/r/120602/diff/ Testing --- Dialog flies in smoothly trying to display the list without scrollbars but is still properly max'd to not fill the entire screen. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120602: Fix glitching Alternatives dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120602/ --- (Updated Okt. 15, 2014, 9:21 nachm.) Review request for Plasma and Marco Martin. Changes --- Indeed, the issue was just the anchors.fill: parent because filling parent and setting Layout sizes is a bad idea. The heading and button still need to be accounted for, though. Bugs: 340003 https://bugs.kde.org/show_bug.cgi?id=340003 Repository: plasma-desktop Description --- Fixes a porting oversight and also takes into account the buttons and heading. Apparently when a dialog does not explicitly set a mainItem, the Dialog tries to guess the size from the children of the dialog which was anchors.fill and then it got confused. Diffs (updated) - desktoppackage/contents/explorer/AppletAlternatives.qml 4e97dc9 Diff: https://git.reviewboard.kde.org/r/120602/diff/ Testing --- Dialog flies in smoothly trying to display the list without scrollbars but is still properly max'd to not fill the entire screen. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120602: Fix glitching Alternatives dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120602/ --- (Updated Oct. 15, 2014, 9:40 p.m.) Status -- This change has been marked as submitted. Review request for Plasma and Marco Martin. Bugs: 340003 https://bugs.kde.org/show_bug.cgi?id=340003 Repository: plasma-desktop Description --- Fixes a porting oversight and also takes into account the buttons and heading. Apparently when a dialog does not explicitly set a mainItem, the Dialog tries to guess the size from the children of the dialog which was anchors.fill and then it got confused. Diffs - desktoppackage/contents/explorer/AppletAlternatives.qml 4e97dc9 Diff: https://git.reviewboard.kde.org/r/120602/diff/ Testing --- Dialog flies in smoothly trying to display the list without scrollbars but is still properly max'd to not fill the entire screen. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Build failed in Jenkins: plasma-workspace_master_qt5 #980
See http://build.kde.org/job/plasma-workspace_master_qt5/980/changes Changes: [kde] PlasmaComponents.ListView already provides onClicked and containsMouse -- [...truncated 2332 lines...] [ 40%] Building CXX object ksmserver/screenlocker/kcm/CMakeFiles/screenlocker_kcm.dir/kscreensaversettings.cpp.o Built target killTest [ 40%] command-line:0:0: warning: TRANSLATION_DOMAIN redefined [enabled by default] command-line:0:0: note: this is the location of the previous definition Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/powerdevilpolicyagent.cpp.o Scanning dependencies of target keyboardGrabber [ 40%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardgrabber.cpp.o [ 40%] Building CXX object ksmserver/screenlocker/greeter/CMakeFiles/kscreenlocker_greet.dir/kscreenlocker_greet_automoc.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/CMakeFiles/screenlocker_static.dir/screenlocker_static_automoc.cpp.o Scanning dependencies of target lockWindowTest [ 41%] Scanning dependencies of target logindTest Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockwindowtest.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindtest.cpp.o [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/keyboardGrabber.dir/keyboardGrabber_automoc.cpp.o Linking CXX executable keyboardGrabber [ 41%] Built target keyboardGrabber [ 41%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/__/lockwindow.cpp.o [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/lockWindowTest.dir/lockWindowTest_automoc.cpp.o [ 42%] 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 [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/fakelogind.cpp.o Linking CXX static library libscreenlocker_static.a [ 42%] Built target screenlocker_static [ 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 Linking CXX executable kscreenlocker_greet [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/__/logind.cpp.o Scanning dependencies of target pointerGrabber [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointergrabber.cpp.o Linking CXX executable lockWindowTest [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/pointerGrabber.dir/pointerGrabber_automoc.cpp.o [ 42%] Built target kscreenlocker_greet [ 42%] Building CXX object ksmserver/screenlocker/autotests/CMakeFiles/logindTest.dir/logindTest_automoc.cpp.o Scanning dependencies of target kscreenlocker_test Scanning dependencies of target ksplashqml [ 42%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_main.cpp.o [ 42%] Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/main.cpp.o [ 42%] Built target lockWindowTest [ 42%] Scanning dependencies of target kded_ksysguard Building CXX object ksplash/ksplashqml/CMakeFiles/ksplashqml.dir/SplashApp.cpp.o [ 42%] Building CXX object systemmonitor/CMakeFiles/kded_ksysguard.dir/kdedksysguard.cpp.o Scanning dependencies of target systemmonitor Linking CXX shared module screenlocker_kcm.so Linking CXX executable pointerGrabber [ 43%] Building CXX object systemmonitor/CMakeFiles/systemmonitor.dir/ksystemactivitydialog.cpp.o [ 43%] Built target screenlocker_kcm [ 43%] Generating statusnotifieritem_interface.cpp, statusnotifieritem_interface.h [ 43%] Generating statusnotifierwatcheradaptor.cpp, statusnotifierwatcheradaptor.h [ 43%] [ 43%] Built target pointerGrabber Generating statusnotifierwatcheradaptor.moc [ 43%] [ 43%] Building CXX object ksmserver/screenlocker/tests/CMakeFiles/kscreenlocker_test.dir/kscreenlocker_test_automoc.cpp.o [ 43%] Generating klauncher_iface.cpp, klauncher_iface.h Generating statusnotifieritem_interface.moc [ 43%] Generating klauncher_iface.moc [ 43%] Generating klauncher_iface.moc Scanning dependencies of target kded_statusnotifierwatcher [ 43%] Building CXX object statusnotifierwatcher/CMakeFiles/kded_statusnotifierwatcher.dir/statusnotifierwatcher.cpp.o Scanning dependencies of target kdeinit_kcminit [ 43%] Linking CXX executable kscreenlocker_test Building CXX object startkde/kcminit/CMakeFiles/kdeinit_kcminit.dir/main.cpp.o Scanning dependencies of target kdeinit_kcminit_startup [ 43%] Building CXX object
Jenkins build is back to stable : plasma-desktop_master_qt5 #734
See http://build.kde.org/job/plasma-desktop_master_qt5/734/changes ___ 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. 15, 2014, 8:30 p.m., David Edmundson wrote: Relevant code in greeterapp needs removing too. There's a property and a slot ::shutdown() Interestingly the canShutDown is based on whether the user can logout which is a bit random. Martin Gräßlin wrote: Relevant code in greeterapp needs removing too. all right, will update. Interestingly the canShutDown is based on whether the user can logout which is a bit random. yeah, I thought so as well when reading the documentation. What would be cool is to tell logind that currently the screen is locked and that logind behaves like there is no active session in that case. Maybe worth to take to their mailing list? David Edmundson wrote: We already do tell logind that the session is locked (or at least we should be), but as you pointed out earlier canShutdown is user based not session based so it doesn't really end up helping. It's worth an email, they might have a plan or at least they would want to know where logind maybe misses something for when they make v2. We already do tell logind that the session is locked we do? How? ;-) I had looked at the interface and all I could see was the lockSession which asks the sessions to lock the screen (and we do that), but no way to tell logind that it's locked now and it's no longer locked. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68501 --- 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
