Re: Review Request 123475: Execute KAuth jobs for brightness control in an async manner
On April 23, 2015, 1:32 p.m., Aleix Pol Gonzalez wrote: daemon/backends/upower/powerdevilupowerbackend.cpp, line 161 https://git.reviewboard.kde.org/r/123475/diff/1/?file=362676#file362676line161 Is it fine to use exec() here? no, I missed that one :-( - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123475/#review79375 --- On April 23, 2015, 1:05 p.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123475/ --- (Updated April 23, 2015, 1:05 p.m.) Review request for Plasma, Solid and Kai Uwe Broulik. Repository: powerdevil Description --- KJob::exec is dangerous and caused freezes on my system. Thus this change to remodel the interaction in an async way. Diffs - daemon/backends/upower/powerdevilupowerbackend.h 1c4dd592f0a3cb07b9821c7f82c89517d599635a daemon/backends/upower/powerdevilupowerbackend.cpp 87b9cc7b7db1b6a6f5b31263cd3832715c497328 Diff: https://git.reviewboard.kde.org/r/123475/diff/ Testing --- kded5 no longer freezes. But I'm not sure whether the init gets finished: is there a way to easily verify whether the module loaded completely? Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
ISO for 2015-04-24
http://files.kde.org/snapshots/unstable-amd64-latest.iso.mirrorlist This ISO was created using the Plasma/5.3 branch as of earlier today. Which roughly approximates what is eventually going to become 5.3.0 next week. After release the ISO is then switching back to git master branches for next friday. # changes - installer window decoration doesn't render black anymore # errata - installer window decoration uses !breeze colors. fix discussed; needs implementation in the installer code itself. - extra software that is not marked for stable integration (notably everything that isn't frameworks|plasma|applications) is not available for installation. if a certain package can not be installed chances are that it only has an unstable build and will need the unstable archive added with sudo apt-add-repository ppa:kubuntu-ci/unstable sudo apt update. do note that this will however also bring in plasma master builds. # long standing errata - the ISO is rolled using the CI landing PPA due to stabilization blockage from missing bluez5. this in turn means that upgrades potentially won't work or break half way through as the underlying PPA breaks ever so often. ^ Work on tech to resolve this has been started ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 10:59 p.m., Luigi Toscano wrote: Apart from more technical issues, the patch includes changes to: applets/icontasks/metadata.desktop containments/folder/metadata.desktop kcms/access/kcmaccess.desktop kcms/baloo/kcm_baloofile.desktop which I think are unrelated. yes, that just comes from a git dif master - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79413 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305 kcms/cursortheme/xcursor/sortproxymodel.h 95c9646 kcms/cursortheme/xcursor/sortproxymodel.cpp b9d6309 kcms/cursortheme/xcursor/thememodel.h bcf046a kcms/cursortheme/xcursor/thememodel.cpp 4e4647f kcms/cursortheme/xcursor/themepage.h 98c69fd kcms/cursortheme/xcursor/themepage.cpp 687bd65 kcms/cursortheme/xcursor/themepage.ui 6efe60b kcms/desktoppaths/desktoppath.desktop eb2fad5 kcms/lookandfeel/autotests/lookandfeel/metadata.desktop 3360a85 kcms/lookandfeel/kcm_lookandfeel.desktop 8550e5c kcms/lookandfeel/package/metadata.desktop 6595d6e kcms/touchpad/src/applet/qml/metadata.desktop e9a0bc1 kcms/touchpad/src/kcm/kcm_touchpad.desktop c537e5f kcms/touchpad/src/kded/kcm_touchpad.notifyrc 9e51e0e kcms/touchpad/src/kded/kded_touchpad.desktop ec076a9 kcms/useraccount/kcm_useraccount.desktop 46ef110 layout-templates/org.kde.plasma.desktop.defaultPanel/metadata.desktop 89d7fc3 Diff: https://git.reviewboard.kde.org/r/123473/diff/ Testing --- File Attachments cursorskcm.png https://git.reviewboard.kde.org/media/uploaded/files/2015/04/23/72f14417-e14c-4385-9e8e-959dd1f2d8e4__cursorskcm.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305 kcms/cursortheme/xcursor/sortproxymodel.h 95c9646
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 1:31 p.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 4:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 4:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305 kcms/cursortheme/xcursor/sortproxymodel.h 95c9646 kcms/cursortheme/xcursor/sortproxymodel.cpp b9d6309 kcms/cursortheme/xcursor/thememodel.h bcf046a kcms/cursortheme/xcursor/thememodel.cpp 4e4647f kcms/cursortheme/xcursor/themepage.h 98c69fd
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305 kcms/cursortheme/xcursor/sortproxymodel.h 95c9646 kcms/cursortheme/xcursor/sortproxymodel.cpp b9d6309 kcms/cursortheme/xcursor/thememodel.h bcf046a kcms/cursortheme/xcursor/thememodel.cpp 4e4647f kcms/cursortheme/xcursor/themepage.h 98c69fd kcms/cursortheme/xcursor/themepage.cpp 687bd65 kcms/cursortheme/xcursor/themepage.ui 6efe60b kcms/desktoppaths/desktoppath.desktop eb2fad5 kcms/lookandfeel/autotests/lookandfeel/metadata.desktop 3360a85 kcms/lookandfeel/kcm_lookandfeel.desktop 8550e5c kcms/lookandfeel/package/metadata.desktop 6595d6e kcms/touchpad/src/applet/qml/metadata.desktop e9a0bc1 kcms/touchpad/src/kcm/kcm_touchpad.desktop
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 1:31 p.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? maybe only show them for the selected or on hover? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 4:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 4:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305
[Powerdevil] [Bug 344456] Plasma 5 desktop does not suspend with only upower, no systemd
https://bugs.kde.org/show_bug.cgi?id=344456 ar...@manjaro.org changed: What|Removed |Added CC||ar...@manjaro.org --- Comment #25 from ar...@manjaro.org --- Hi Eric, the part with the missing restart/shutdown in the menu, can be also solved by providing polkit rules for ck restart/shutdown. Polkit rules for upower make also suspend/hibernate appear in menu. But, I do get on gentoo the very same errors logged regarding powerdevil not registering a ck session, thus no suspend. -- 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 123457: Plasma-Workspace: we don't need QtWebkit as a depedency.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123457/ --- (Updated April 24, 2015, 6:16 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Changes --- Submitted with commit 9c1d4f889d32a1b54938709c8c5dd9ca975532a2 by Antonis Tsiapaliokas to branch master. Repository: plasma-workspace Description --- Plasma-Workspace doesn't need QtWebKit as a depedency anymore. Diffs - CMakeLists.txt 70cc52a Diff: https://git.reviewboard.kde.org/r/123457/diff/ Testing --- Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 21, 2015, 9:47 p.m., David Edmundson wrote: lookandfeel/contents/components/InfoPane.qml, line 47 https://git.reviewboard.kde.org/r/123459/diff/1/?file=362312#file362312line47 there's a visible here. If your two lines are needed, this isn't. Or this should be changed to the battery.hasBattery instead. Yes, we have to use this visible. My two lines are a bit of overkill. - Antonis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79311 --- On April 24, 2015, 6:22 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 p.m.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 p.m.) Review request for Plasma. Changes --- fix typo. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs (updated) - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 22, 2015, 3:46 vorm., Kai Uwe Broulik wrote: -1 that's what the visible: pmSource.data[Battery][Has Cumulative] is for. there just used to be a bug where that property wasn't created in the first place if no battery was present leading to an exception causing the item to remain visible. Antonis Tsiapaliokas wrote: What about checking if the pmSource.data[Battery][Has Cumulative] has been set properly, and if not, then using the pmSource.data[Battery][Has Battery]? I have update my patch with the above change... I don't quite get it. Theoretically Has Cumulative is true when there is a power supply battery and it is false if there isn't. I suppose you're running latest plasma-workspace and powerdevil? I used to have this issue on my desktop but fixed it and it's gone here. Could you paste the output of upower -d for your machine, and also the value of Has Cumulative in plasmaengineexplorer? - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79321 --- On April 24, 2015, 6:22 nachm., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 nachm.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:20 p.m.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs (updated) - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 22, 2015, 3:46 a.m., Kai Uwe Broulik wrote: -1 that's what the visible: pmSource.data[Battery][Has Cumulative] is for. there just used to be a bug where that property wasn't created in the first place if no battery was present leading to an exception causing the item to remain visible. What about checking if the pmSource.data[Battery][Has Cumulative] has been set properly, and if not, then using the pmSource.data[Battery][Has Battery]? I have update my patch with the above change... - Antonis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79321 --- On April 24, 2015, 6:22 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 p.m.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 24, 2015, 3:10 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs (updated) - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml PRE-CREATION kcms/cursortheme/package/contents/ui/main.qml PRE-CREATION kcms/cursortheme/package/metadata.desktop PRE-CREATION kcms/cursortheme/xcursor/itemdelegate.h 9acb0e9 kcms/cursortheme/xcursor/itemdelegate.cpp e737005 kcms/cursortheme/xcursor/previewwidget.h 4a11e2d kcms/cursortheme/xcursor/previewwidget.cpp 79d1305 kcms/cursortheme/xcursor/sortproxymodel.h 95c9646 kcms/cursortheme/xcursor/sortproxymodel.cpp b9d6309 kcms/cursortheme/xcursor/thememodel.h bcf046a kcms/cursortheme/xcursor/thememodel.cpp 4e4647f kcms/cursortheme/xcursor/themepage.h 98c69fd kcms/cursortheme/xcursor/themepage.cpp 687bd65 kcms/cursortheme/xcursor/themepage.ui 6efe60b kcms/desktoppaths/desktoppath.desktop eb2fad5 kcms/lookandfeel/autotests/lookandfeel/metadata.desktop 3360a85 kcms/lookandfeel/kcm_lookandfeel.desktop 8550e5c kcms/lookandfeel/package/metadata.desktop 6595d6e kcms/touchpad/src/applet/qml/metadata.desktop e9a0bc1 kcms/touchpad/src/kcm/kcm_touchpad.desktop c537e5f kcms/touchpad/src/kded/kcm_touchpad.notifyrc 9e51e0e kcms/touchpad/src/kded/kded_touchpad.desktop ec076a9 kcms/useraccount/kcm_useraccount.desktop 46ef110 layout-templates/org.kde.plasma.desktop.defaultPanel/metadata.desktop 89d7fc3 Diff: https://git.reviewboard.kde.org/r/123473/diff/ Testing --- File Attachments cursorskcm.png https://git.reviewboard.kde.org/media/uploaded/files/2015/04/23/72f14417-e14c-4385-9e8e-959dd1f2d8e4__cursorskcm.png Thanks, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123492: Fix memory leak in AppletQuickItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123492/#review79480 --- Ship it! Ship It! - Aleix Pol Gonzalez On April 24, 2015, 6:33 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123492/ --- (Updated April 24, 2015, 6:33 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Change-Id: If96689f937cf3b7e46c6eeacf8e8f850e9db571a Diffs - src/plasmaquick/appletquickitem.cpp b608a80adbc9f737027e59ff5c9f9933df8de06e Diff: https://git.reviewboard.kde.org/r/123492/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123493: Fix leaky incubation controller
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123493/#review79481 --- Ship it! Ship It! - Aleix Pol Gonzalez On April 24, 2015, 6:43 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123493/ --- (Updated April 24, 2015, 6:43 p.m.) Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- Docs for QQmlEngine explcitly say The engine can only have one active controller and it does not take ownership of it. therefore we need to set a parent. The incubator controls the deletion of generated objects, so this means we're leaking all QML items created by the KDeclarative::QmlObject. Diffs - src/kdeclarative/qmlobject.cpp c483665c43985ba57459a880895ee8bf7ff92041 Diff: https://git.reviewboard.kde.org/r/123493/diff/ Testing --- Plasma shell still loads and runs fine. Valgrind is a lot less angry. Will merge after 5.10 to play safe. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. - Sebastian --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7 kcms/baloo/kcm_baloofile.desktop 2eee6fc kcms/cursortheme/CMakeLists.txt 83f3ba2 kcms/cursortheme/Messages.sh 79450c7 kcms/cursortheme/cursortheme.desktop f443208 kcms/cursortheme/kcm_cursortheme.desktop PRE-CREATION kcms/cursortheme/kcmcursortheme.h d9e32b2 kcms/cursortheme/kcmcursortheme.cpp 44576ff kcms/cursortheme/package/contents/ui/Delegate.qml
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 1:31 p.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 24, 2015, 5:10 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 24, 2015, 5:10 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls
Review Request 123494: Create DesktopView before connecting signals from the activity consumer
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123494/ --- Review request for Plasma and Marco Martin. Repository: plasma-workspace Description --- This avoids the crash situation where something have created the activity consumer earlier and currentActivityChanged signal is emitted before view is created. ``` #0 PlasmaQuick::View::setContainment (this=0x0, cont=0x16a9fc0) at /home/bshah/aur/plasma-framework-git/src/plasma-framework/src/plasmaquick/view.cpp:243 #1 0x00462097 in StandaloneAppCorona::currentActivityChanged (this=0x7772a0, newActivity=...) at /home/bshah/aur/plasma-workspace-git/src/plasma-workspace/shell/standaloneappcorona.cpp:192 #2 0x732383c9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #3 0x771f9763 in KActivities::Consumer::currentActivityChanged (this=0x741aa0, _t1=...) at /home/bshah/aur/kactivities-git/src/build/src/lib/core/moc_consumer.cpp:216 #4 0x771f94dd in KActivities::Consumer::qt_static_metacall (_o=0x741aa0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0x7fffa570) at /home/bshah/aur/kactivities-git/src/build/src/lib/core/moc_consumer.cpp:103 #5 0x732383c9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 #6 0x771f91d6 in KActivities::ActivitiesCache::currentActivityChanged (this=0x77c900, _t1=...) at /home/bshah/aur/kactivities-git/src/build/src/lib/core/moc_activitiescache_p.cpp:353 #7 0x771ee4f7 in KActivities::ActivitiesCache::setCurrentActivity (this=0x77c900, activity=...) at /home/bshah/aur/kactivities-git/src/kactivities/src/lib/core/activitiescache_p.cpp:297 ``` I hit this crash when creating recent media backend for pmc. First backendsmodel is initalized which in turn loads the recentmedia backend and hence creates the activity consumer first. Afterwards when signal is connected it calls currentActivityChanged slot and fails to set containment on null view. Diffs - shell/standaloneappcorona.cpp efa5c91 Diff: https://git.reviewboard.kde.org/r/123494/diff/ Testing --- works fine Thanks, Bhushan Shah ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. Marco Martin wrote: this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough Martin Gräßlin wrote: so that may have to be made inline as well, not sure if it would work well tough Given that it already has this Available size, I think it could be a neat idea to morph it into the delegate. (o) Resolution Dependent (o) |Dropdown| available sizes For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. * So that the appearance and behavior of the KCM is consistent with that of the icon theme KCM. * So that the listview looks and behaves identically to other listviews. * To enable the user to get a quick overview of the installed themes without having to scroll. * Each item in the listview provides three key points of data so as to not overwhelm the user with information; a single large image of the most important cursor, the name of the theme, and finally a short description. Every design decision was make after careful consideration, and after studying the user interface
Review Request 123492: Fix memory leak in AppletQuickItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123492/ --- Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Change-Id: If96689f937cf3b7e46c6eeacf8e8f850e9db571a Diffs - src/plasmaquick/appletquickitem.cpp b608a80adbc9f737027e59ff5c9f9933df8de06e Diff: https://git.reviewboard.kde.org/r/123492/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123492: Fix memory leak in AppletQuickItem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123492/#review79466 --- Ship it! Ship It! - Marco Martin On April 24, 2015, 4:33 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123492/ --- (Updated April 24, 2015, 4:33 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- Change-Id: If96689f937cf3b7e46c6eeacf8e8f850e9db571a Diffs - src/plasmaquick/appletquickitem.cpp b608a80adbc9f737027e59ff5c9f9933df8de06e Diff: https://git.reviewboard.kde.org/r/123492/diff/ Testing --- Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 123493: Fix leaky incubation controller
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123493/ --- Review request for KDE Frameworks and Plasma. Repository: kdeclarative Description --- Docs for QQmlEngine explcitly say The engine can only have one active controller and it does not take ownership of it. therefore we need to set a parent. The incubator controls the deletion of generated objects, so this means we're leaking all QML items created by the KDeclarative::QmlObject. Diffs - src/kdeclarative/qmlobject.cpp c483665c43985ba57459a880895ee8bf7ff92041 Diff: https://git.reviewboard.kde.org/r/123493/diff/ Testing --- Plasma shell still loads and runs fine. Valgrind is a lot less angry. Will merge after 5.10 to play safe. Thanks, David Edmundson ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123473: Port mouse theme kcm to QML
On April 23, 2015, 11:31 a.m., Eike Hein wrote: This is more an experiment on how much modules can be closely ported (and in how much time). What's the benefit to the user of merging this version now? Marco Martin wrote: none. not too much pain as well tough. all of them have to eventually be ported tough and in order to get done, one has to.. do it Eike Hein wrote: all of them have to eventually be ported tough and in order to get done, one has to.. do it I'm just not a big fan of putting transitional pain (worse UI from a weaker toolkit) on the user when there's an opportunity to avoid it, I guess ... right now, Qt Quick has worse performance, no keyboard accelerator management, no form layouts, limited widgets, some visual problems, etc. - It's true of course that using it builds greater pressure to get it fixed, but are we *certain* that actively hurting the quality of our releases is the only path available? Marco Martin wrote: bah, right now accelerators and tab focus kinda works in that module.. still kinda, but again, if the decision is to go in that direction, of which i remeber it was talked about and decided, otherwise I wouldn't have wasted two days on it ;) Now, I'm fine if now we decide to not port modules, but most of them kindof have to be redone anyways, and I would prefer reding them once rather than twice. David Edmundson wrote: It's true of course that using it builds greater pressure to get it fixed, but are we certain that actively hurting the quality of our releases is the only path available? It's not as simple as saying using new stuff /will/ hurt the quality compared to the current state. This KCM wouldn't use form layouts, or any special widgets that we don't have anyway. Keyboard accelorators and tab keys /should/ work in QQC so by the time we finish with this, I think we can make it just as perfect /and/ progress our QQC integration at the same time. Also it's not like these KCMs are truly perfect as-is. There are 8 open bugs on the cursor KCM. I'd like to think paying some attention to these KCMs will fix some of them. I do completely agree with you that users shouldn't be hurt by porting efforts and we should have an absolutely no regressions at all policy before merging, with no excuses about limitations in QQC. Martin Gräßlin wrote: I agree with David that we also should see this as a chance. For example I always wondered why there is this strange preview area on the top, instead of just previewing all cursors in the list directly. With QQC that becomes quite easier and removes the it's probably because it would be a nightmare with delegates. Marco Martin wrote: having all the previews inline could probably be simpler since i could perhaps avoid a custom qquickpainteditem.. however, it would look very crowded i think? Martin Gräßlin wrote: maybe only show them for the selected or on hover? Marco Martin wrote: this is very quick and dirty: http://wstaw.org/m/2015/04/24/plasma-desktopzp1576.png with very big delegates, it almost looks nice :) Sebastian Kügler wrote: I quite like it. Also, it's really not necessary to be able to view 5 or more themes at the same time, this makes comparison already a lot easier. this is with a better layout: http://wstaw.org/m/2015/04/24/plasma-desktopUj1576.png there is still one thing that doesn't logically work too much, that is the size combo box, since it depends from the theme selected (not all themes have all the same sizes available) so that may have to be made inline as well, not sure if it would work well tough - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/#review79374 --- On April 23, 2015, 2:08 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123473/ --- (Updated April 23, 2015, 2:08 p.m.) Review request for Plasma. Repository: plasma-desktop Description --- This is more an experiment on how much modules can be closely ported (and in how much time). the mouse theme kcm should be pretty much feature complete. the main problem is the size combobox missing the cursor image due to the QtQuickControls ComboBox being very limited and without a customizable delegate. all the other functions such as add/remove/ghns seems to work well Diffs - applets/icontasks/metadata.desktop f0b237c containments/folder/metadata.desktop a6d08a7 kcms/access/kcmaccess.desktop 825b6d7
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 22, 2015, 3:46 a.m., Kai Uwe Broulik wrote: -1 that's what the visible: pmSource.data[Battery][Has Cumulative] is for. there just used to be a bug where that property wasn't created in the first place if no battery was present leading to an exception causing the item to remain visible. Antonis Tsiapaliokas wrote: What about checking if the pmSource.data[Battery][Has Cumulative] has been set properly, and if not, then using the pmSource.data[Battery][Has Battery]? I have update my patch with the above change... Kai Uwe Broulik wrote: I don't quite get it. Theoretically Has Cumulative is true when there is a power supply battery and it is false if there isn't. I suppose you're running latest plasma-workspace and powerdevil? I used to have this issue on my desktop but fixed it and it's gone here. Could you paste the output of upower -d for your machine, and also the value of Has Cumulative in plasmaengineexplorer? When i wrote this patch(2 days ago), plasmaengineexplorer didn't had the Has Cumulative. Today i update my setup and plasmaenginexplorer has a value for the Has Cumulative. Yes, i am running the latest plasma-workspace and powerdevil. So since none of us can reproduce the issue anymore, and you have fixed the issue with the Has Cumulative, i guess we can discard this review. Right? - Antonis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79321 --- On April 24, 2015, 6:22 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 p.m.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 22, 2015, 3:46 a.m., Kai Uwe Broulik wrote: -1 that's what the visible: pmSource.data[Battery][Has Cumulative] is for. there just used to be a bug where that property wasn't created in the first place if no battery was present leading to an exception causing the item to remain visible. Antonis Tsiapaliokas wrote: What about checking if the pmSource.data[Battery][Has Cumulative] has been set properly, and if not, then using the pmSource.data[Battery][Has Battery]? I have update my patch with the above change... Kai Uwe Broulik wrote: I don't quite get it. Theoretically Has Cumulative is true when there is a power supply battery and it is false if there isn't. I suppose you're running latest plasma-workspace and powerdevil? I used to have this issue on my desktop but fixed it and it's gone here. Could you paste the output of upower -d for your machine, and also the value of Has Cumulative in plasmaengineexplorer? Antonis Tsiapaliokas wrote: When i wrote this patch(2 days ago), plasmaengineexplorer didn't had the Has Cumulative. Today i update my setup and plasmaenginexplorer has a value for the Has Cumulative. Yes, i am running the latest plasma-workspace and powerdevil. So since none of us can reproduce the issue anymore, and you have fixed the issue with the Has Cumulative, i guess we can discard this review. Right? Kai Uwe Broulik wrote: That one [1] fixed it; sorry for the confusion, could be closed then :) [1] http://quickgit.kde.org/?p=plasma-workspace.gita=commith=49c425a80eca011cff20d2af47477f6ffb76e3bf Np :) - Antonis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79321 --- On April 24, 2015, 6:22 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 p.m.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 7:02 p.m.) Status -- This change has been discarded. Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 123459: Lockscreen: It shouldn't show the battery information on system which they don't have a battery
On April 22, 2015, 3:46 vorm., Kai Uwe Broulik wrote: -1 that's what the visible: pmSource.data[Battery][Has Cumulative] is for. there just used to be a bug where that property wasn't created in the first place if no battery was present leading to an exception causing the item to remain visible. Antonis Tsiapaliokas wrote: What about checking if the pmSource.data[Battery][Has Cumulative] has been set properly, and if not, then using the pmSource.data[Battery][Has Battery]? I have update my patch with the above change... Kai Uwe Broulik wrote: I don't quite get it. Theoretically Has Cumulative is true when there is a power supply battery and it is false if there isn't. I suppose you're running latest plasma-workspace and powerdevil? I used to have this issue on my desktop but fixed it and it's gone here. Could you paste the output of upower -d for your machine, and also the value of Has Cumulative in plasmaengineexplorer? Antonis Tsiapaliokas wrote: When i wrote this patch(2 days ago), plasmaengineexplorer didn't had the Has Cumulative. Today i update my setup and plasmaenginexplorer has a value for the Has Cumulative. Yes, i am running the latest plasma-workspace and powerdevil. So since none of us can reproduce the issue anymore, and you have fixed the issue with the Has Cumulative, i guess we can discard this review. Right? That one [1] fixed it; sorry for the confusion, could be closed then :) [1] http://quickgit.kde.org/?p=plasma-workspace.gita=commith=49c425a80eca011cff20d2af47477f6ffb76e3bf - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/#review79321 --- On April 24, 2015, 6:22 nachm., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123459/ --- (Updated April 24, 2015, 6:22 nachm.) Review request for Plasma. Bugs: 346441 https://bugs.kde.org/show_bug.cgi?id=346441 Repository: plasma-workspace Description --- The battery information shouldn't be shown on systems which they don't have battery (desktops/laptop without battery). Diffs - lookandfeel/contents/components/InfoPane.qml 18739ad Diff: https://git.reviewboard.kde.org/r/123459/diff/ Testing --- File Attachments no battery after https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/d3e0b27b-e695-46a2-b56a-dc60c9679309__no_battery_after.png no battery before https://git.reviewboard.kde.org/media/uploaded/files/2015/04/21/884a20d3-852c-4b1d-a588-7bb47e725011__no_battery_before.png Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
