[KDE Bugtracking System] REMINDER: current Plasma regressions
Please find below a list of the current regressions reported for Plasma. This is a weekly reminder. This search was scheduled by myr...@kde.org. Plasma regressions (1 bugs) -- Bug 301424: https://bugs.kde.org/show_bug.cgi?id=301424 Severity: normal Priority: NOR Status: REOPENED Resolution: Product: plasma Keywords: regression Component: widget-systemtray Version: 4.9.90 Beta2 Summary: Cannot open battery monitor applet if set to hidden in systray ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
No objections just a massive thumbs up! On Wednesday 01 October 2014 16.21.03 Andrew Lake wrote: For anyone using the breeze dark theme, I've been meaning for a while to make some adjustments so that the edges aren't quite so pronounced and high contrast. It looks this way because it's currently using the same svgs (and edge highlights) from the normal breeze theme svgs. I have changes ready to push to reduce that high contrast edge outline, but I wanted to check to see if there was anyone that was particularly wedded to the those white outlines before I do. I'd do up a screen shot but just imagine those bright white outlines turned all the way down. Holler if anyone has any objections. :-) Thanks, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build became unstable: plasma-workspace_master_qt5 #945
See http://build.kde.org/job/plasma-workspace_master_qt5/945/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
On 02.10.2014 01:21, Andrew Lake wrote: Holler if anyone has any objections. :-) Personally I kind of like the white outlines. Not sure how to put it, they give kind of a cool retro-y vibe perhaps ;). I think they might actually fall into happy-accident territory, but I'm not married to them ... Thanks, Andrew Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
On Thu, Oct 2, 2014 at 11:10 AM, Eike Hein h...@kde.org wrote: On 02.10.2014 01:21, Andrew Lake wrote: Holler if anyone has any objections. :-) Personally I kind of like the white outlines. Not sure how to put it, they give kind of a cool retro-y vibe perhaps ;). I think they might actually fall into happy-accident territory, but I'm not married to them ... Same here. I personally do like them, imo it gives some kind of visual connection to the white icons used in breeze-dark, but if you think the disadvantages are bigger, go ahead :) Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
On Wednesday 01 October 2014 16:21:03 Andrew Lake wrote: For anyone using the breeze dark theme, I've been meaning for a while to make some adjustments so that the edges aren't quite so pronounced and high contrast. It looks this way because it's currently using the same svgs (and edge highlights) from the normal breeze theme svgs. I have changes ready to push to reduce that high contrast edge outline, but I wanted to check to see if there was anyone that was particularly wedded to the those white outlines before I do. I'd do up a screen shot but just imagine those bright white outlines turned all the way down. Holler if anyone has any objections. :-) does the change involve duplicating the svgs? I quite like them as well, also i prefer duplication of images to be as little as possible (just yesterday i fixed some graphics glitches exactly in that, means next time work gets to be done double of the times) I am not that opposed to it, but if it has to be done i would prefer a way that doesn't duplicate svgs (that should be possible) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Jenkins build is back to stable : plasma-workspace_master_qt5 #946
See http://build.kde.org/job/plasma-workspace_master_qt5/946/changes ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 3:27 p.m.) Review request for Plasma. Changes --- Add screenshots Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments (updated) Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67810 --- Ship it! I tried it a bit, it seems to work fine - Marco Martin On Oct. 2, 2014, 1:27 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 1:27 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67811 --- Ship it! Nice work! applets/digital-clock/package/contents/ui/DigitalClock.qml https://git.reviewboard.kde.org/r/120461/#comment47214 There may be a corner case here, when the formfactor changes to Planar or MediaCenter (i.e. other), Layout.* properties may still be set. I don't know if this is much of an issue in practise, as that kind of formfactor change should happen very rarely, but might be something to improve (in the future). - Sebastian Kügler On Oct. 2, 2014, 1:27 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 1:27 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67812 --- File Attachment: Variants in vertical panel - digital-clock2.png https://git.reviewboard.kde.org//r/120461/#fcomment270 Is it the panel which makes it not look horizontally centered? applets/digital-clock/package/contents/ui/DigitalClock.qml https://git.reviewboard.kde.org/r/120461/#comment47215 This could be compacted to one-liners without braces applets/digital-clock/package/contents/ui/DigitalClock.qml https://git.reviewboard.kde.org/r/120461/#comment47216 Could this be based on some unit? applets/digital-clock/package/contents/ui/DigitalClock.qml https://git.reviewboard.kde.org/r/120461/#comment47217 Is this needed? - Kai Uwe Broulik On Okt. 2, 2014, 1:27 nachm., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Okt. 2, 2014, 1:27 nachm.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67813 --- Ship it! Ship It! - Kai Uwe Broulik On Okt. 2, 2014, 1:27 nachm., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Okt. 2, 2014, 1:27 nachm.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
On Oct. 2, 2014, 3:57 p.m., Sebastian Kügler wrote: applets/digital-clock/package/contents/ui/DigitalClock.qml, line 216 https://git.reviewboard.kde.org/r/120461/diff/1/?file=316057#file316057line216 There may be a corner case here, when the formfactor changes to Planar or MediaCenter (i.e. other), Layout.* properties may still be set. I don't know if this is much of an issue in practise, as that kind of formfactor change should happen very rarely, but might be something to improve (in the future). Well now that you mentioned it, I never tried it on desktop. This is not enough for desktop/planar, so...fix incoming ^_- - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67811 --- On Oct. 2, 2014, 3:27 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 3:27 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
On Oct. 2, 2014, 4:04 p.m., Kai Uwe Broulik wrote: File Attachment: Variants in vertical panel - digital-clock2.png https://git.reviewboard.kde.org/r/120461/#fcomment271 Is it the panel which makes it not look horizontally centered? I think so, the vertical variant has Layout.fillWidth: true but when you paint rectangles, you can see a couple pixels offset at the side. There are no margins being set. It's possibly the blue strip. On Oct. 2, 2014, 4:04 p.m., Kai Uwe Broulik wrote: applets/digital-clock/package/contents/ui/DigitalClock.qml, lines 219-220 https://git.reviewboard.kde.org/r/120461/diff/1/?file=316057#file316057line219 Could this be based on some unit? I removed it completely, replaced with minSize based on units On Oct. 2, 2014, 4:04 p.m., Kai Uwe Broulik wrote: applets/digital-clock/package/contents/ui/DigitalClock.qml, line 231 https://git.reviewboard.kde.org/r/120461/diff/1/?file=316057#file316057line231 Is this needed? For tooltip? Otherwise I don't think it is - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/#review67812 --- On Oct. 2, 2014, 3:27 p.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 3:27 p.m.) Review request for Plasma. Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120461: Refactor DigitalClock applet to use multiple labels and states
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120461/ --- (Updated Oct. 2, 2014, 5:05 p.m.) Review request for Plasma. Changes --- Fixed desktop/planar mode, couple other minor issues Repository: plasma-workspace Description --- Right now the clock applet is using one single label (besides the sizehelper) to fit time, timezone and also date. This has several drawbacks like for example the whole label must use one font size, one eliding etc. Putting everything into its own label gives way more flexibility as we can position and size things independently - for example making the time bigger font than the timezone or date and elide long timezone name without omitting the date. The sizing is now also simpler and more robust. This patch adds the time and timezone labels into Flow which changes direction based on the layout (in vertical panels layouts things vertically, horizontal panels either vertically or horizontally depending on date being shown or not), the date label is then always appended at the bottom. The reason for dateLabel not being in the Flow is that in horizontal panels we want the date label always go to the bottom and be center aligned and Flow does not support horizontal alignment of its children. Two anchors seems much easier in this case. This removes two i18n strings and works around having to add another one (line 352 in the patch) - it's not kosher but I did it so it can still be merged for 5.1 which I would be strongly in favor of. If you decide it should wait for 5.2, I'll add the i18n at the line 352). Finally, this adds states for separate handling of vertical and horizontal panels, which has cleaned the code quite a lot from all the vertical ? complex_a_stuff : complex_b_stuff. Sorry it took so long, I kept quickly adding more things to finish it asap until the point where I had to stop and start from scratch. Result is much simpler much cleaner code. Diffs (updated) - applets/digital-clock/package/contents/ui/DigitalClock.qml 4853716 Diff: https://git.reviewboard.kde.org/r/120461/diff/ Testing --- I did try a thorough testing of all the features in panels on all screen edges, all seems good. File Attachments Variants in horizontal panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/30deb86a-4ea6-45b7-b2ed-cfbab0c76e68__digital-clock1.png Variants in vertical panel https://git.reviewboard.kde.org/media/uploaded/files/2014/10/02/4fd5dca9-2e90-419e-a60d-f998b8b2bd7e__digital-clock2.png Thanks, Martin Klapetek ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
Thanks for the feedback. Given the collection of responses so far, I'll go ahead and leave the white outlines as they are. Regarding duplication of svgs. Yes, the changes I prepared had separate panel-background, dialog and tooltip svgs specifically for the dark theme. The main reason is that reflective properties of the edge of the material changes with color - brighter colors reflect more light, darker colors reflect less. So where as the Cardboard Grey of the normal Breeze theme needed a much brighter outline to better represent the quality of the edge, the dark grey of the breeze dark theme would need a much less bright outline. The current white outlines that we've grown to like are a happy accident of the much brighter outline needed for the normal theme. Now, we'll just say that those outlines are intentional. ;-) In any event, I think there may be only so much complexity that's worth it to avoid duplication of svgs. Beyond a certain point a theme of a different color is, in the end, just a different theme. And these themes are a couple of drunken grizzly bears to put together as is. :-) Thanks much for the feedback! Andrew [back to visual bug hunting] On Thu, Oct 2, 2014 at 2:25 AM, Marco Martin notm...@gmail.com wrote: On Wednesday 01 October 2014 16:21:03 Andrew Lake wrote: For anyone using the breeze dark theme, I've been meaning for a while to make some adjustments so that the edges aren't quite so pronounced and high contrast. It looks this way because it's currently using the same svgs (and edge highlights) from the normal breeze theme svgs. I have changes ready to push to reduce that high contrast edge outline, but I wanted to check to see if there was anyone that was particularly wedded to the those white outlines before I do. I'd do up a screen shot but just imagine those bright white outlines turned all the way down. Holler if anyone has any objections. :-) does the change involve duplicating the svgs? I quite like them as well, also i prefer duplication of images to be as little as possible (just yesterday i fixed some graphics glitches exactly in that, means next time work gets to be done double of the times) I am not that opposed to it, but if it has to be done i would prefer a way that doesn't duplicate svgs (that should be possible) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving kde:muon repository to kde/workspaces
On Fri, Sep 26, 2014 at 4:44 PM, Aleix Pol aleix...@kde.org wrote: Hi, I'd like to have it moved to get it released with the Plasma 5.2 release, so no rush. I think though it's a good match as I think KDE has had a need for offering resources that are not part of the actual release and also Muon could really use some visibility outside of the Kubuntu world. Since Muon adopted PackageKit and Appstream, the technology tie is no more, so we'll be able to consider it a part of the Plasma Workspace solutions. If there's no considerable objections, I'd like to request the repository move next week. Cheers! Aleix Since there hasn't been any complaints, I'll request the move. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving kde:muon repository to kde/workspaces
[silently cheering you on!] On Thursday 02 October 2014 19.23.17 Aleix Pol wrote: On Fri, Sep 26, 2014 at 4:44 PM, Aleix Pol aleix...@kde.org wrote: Hi, I'd like to have it moved to get it released with the Plasma 5.2 release, so no rush. I think though it's a good match as I think KDE has had a need for offering resources that are not part of the actual release and also Muon could really use some visibility outside of the Kubuntu world. Since Muon adopted PackageKit and Appstream, the technology tie is no more, so we'll be able to consider it a part of the Plasma Workspace solutions. If there's no considerable objections, I'd like to request the repository move next week. Cheers! Aleix Since there hasn't been any complaints, I'll request the move. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving kde:muon repository to kde/workspaces
Dne 2.10.2014 v 19:28 Jens Reuterberg napsal(a): [silently cheering you on!] On Thursday 02 October 2014 19.23.17 Aleix Pol wrote: On Fri, Sep 26, 2014 at 4:44 PM, Aleix Pol aleix...@kde.org wrote: Hi, I'd like to have it moved to get it released with the Plasma 5.2 release, so no rush. I think though it's a good match as I think KDE has had a need for offering resources that are not part of the actual release and also Muon could really use some visibility outside of the Kubuntu world. Since Muon adopted PackageKit and Appstream, the technology tie is no more, so we'll be able to consider it a part of the Plasma Workspace solutions. If there's no considerable objections, I'd like to request the repository move next week. Cheers! Aleix Since there hasn't been any complaints, I'll request the move. No objections from me at all, we will work out the problems with the PackageKit backend :) Here's me hoping we will have a working system updater and a software center in one, regardless of the transient problems -- Lukáš Tinkl lu...@kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
On Thursday 02 October 2014 10:19:52 Andrew Lake wrote: Thanks for the feedback. Given the collection of responses so far, I'll go ahead and leave the white outlines as they are. Regarding duplication of svgs. Yes, the changes I prepared had separate panel-background, dialog and tooltip svgs specifically for the dark theme. I have an idea for a svg that should have automagically a pretty much solid white outline on breeze normal and a just a little bit brighter onbreeze-dark (attached) here only the top, topright and left elements are adjusted because lazyness, but if is a good concept i can finish it: there are two clones of the border pixel: one has the background color, solid (so gray/white on breeze and blackish on breeze-dark) then a second copy is on top of it, white/translucent, so will result in a dull white in the normal case, and a light gray in breeze-dark. -- Marco Martin___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breeze dark theme white edge outlines
Cool Marco! I'm totally fine with that as a solution instead of separate svgs. :-) Of course, you'll still have to decide if you like the white outlines on the dark theme or more subtle edge outlines. deep echo-y voiceThe decision is in your hands. muwahahaha! /deep echo-y voice Seriously though, while I wouldn't have proposed the more subtle outlines if I didn't think they look better, I'm totally cool with whatever the decision on this is from a visual standpoint. I think everyone knows the timelines we're working with, so I say just make and decision and go for it. :-) Hope this helps! Andrew On Thu, Oct 2, 2014 at 11:13 AM, Marco Martin notm...@gmail.com wrote: On Thursday 02 October 2014 10:19:52 Andrew Lake wrote: Thanks for the feedback. Given the collection of responses so far, I'll go ahead and leave the white outlines as they are. Regarding duplication of svgs. Yes, the changes I prepared had separate panel-background, dialog and tooltip svgs specifically for the dark theme. I have an idea for a svg that should have automagically a pretty much solid white outline on breeze normal and a just a little bit brighter onbreeze-dark (attached) here only the top, topright and left elements are adjusted because lazyness, but if is a good concept i can finish it: there are two clones of the border pixel: one has the background color, solid (so gray/white on breeze and blackish on breeze-dark) then a second copy is on top of it, white/translucent, so will result in a dull white in the normal case, and a light gray in breeze-dark. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
10000 lines change in kdeplasma-addons 4.14 branch
Hi Weng, I have been just told you just merged your origin/xuetianweng/kimpanel-ibus-1.5 into KDE/4.14 in the kdeplasma-addons repo That brings 27 files changed, 10677 insertions(+), 1424 deletions(-) Has this been discussed anywhere? Because honestly this seems quite a big change for a stable branch. Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 10000 lines change in kdeplasma-addons 4.14 branch
Hi, Sorry for all the trouble. Sho on irc asked me that he want to test the ibus 1.5 support easier so I get it merged for kde4. Unfortunately there's no further kdeplamsa-addons for kde4 and I didn't finish this before 4.14, so it's also either leave it broken in kde4 or add a usable version. This change doesn't break old things but fix a never supported version for ibus, and the old support is also kept in a different directory. So there is no actual code deletion, and doesn't change the behavior for old version of ibus 1.4. The line number looks huge for following reason: 1. The ibus upstream changed quite a lot and made that ibus support must parse a gtk key string. It's not possible to use gtk for just a keystring parse so I was forced to copy some gdk key string parsing code here. In this part of code there is a hardcoded key symbol to string table which is unfortunately huge. 2. The old supporting code is also kept but moved, and new code is also based on those code. For i18n, there is no new string should be introduced. In summary, this change doesn't break on old version, and introduce a fix of supoort for new version which is never supported before. On Thu, Oct 2, 2014 at 3:52 PM, Albert Astals Cid aa...@kde.org wrote: Hi Weng, I have been just told you just merged your origin/xuetianweng/kimpanel-ibus-1.5 into KDE/4.14 in the kdeplasma-addons repo That brings 27 files changed, 10677 insertions(+), 1424 deletions(-) Has this been discussed anywhere? Because honestly this seems quite a big change for a stable branch. Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Moving repositories in the module structure
Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-devel@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 10000 lines change in kdeplasma-addons 4.14 branch
El Dijous, 2 d'octubre de 2014, a les 16:41:38, Weng Xuetian va escriure: Hi, Sorry for all the trouble. Sho on irc asked me that he want to test the ibus 1.5 support easier so I get it merged for kde4. Unfortunately there's no further kdeplamsa-addons for kde4 and I didn't finish this before 4.14, so it's also either leave it broken in kde4 or add a usable version. With my release team hat on, i would have really welcome a you asking *before* you do such a big commit in a stable branch. It is not my fault Plasma people decided to not have any more kdeplasma feature releases, a new feature in a stable branch is a new feature in a stable branch and it needs an exception. With your explanation i don't think we should reject the exception, but seriously, some communication never hurts. Please everyone understand that we have stable branches for a reason, and adding 10K lines in them is usually not the reason. For me we can leave this as it is, but please next time you need to commit such a big chunk of code to a stable branch talk to people on a mailing list and ideally the release team. Now let's all go back to do amazing work :) Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving repositories in the module structure
On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-devel@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving repositories in the module structure
I'm sorry for doing the move that fast, I should have realized it was sent only to plasma-devel Víctor Blázquez On Fri, Oct 3, 2014 at 12:04 AM, Aleix Pol aleix...@kde.org wrote: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-devel@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving repositories in the module structure
El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-devel@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Maybe you should explain the changes so people is aware of them :) Cheers, Albert Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Moving repositories in the module structure
On Fri, Oct 3, 2014 at 1:52 AM, Albert Astals Cid aa...@kde.org wrote: El Divendres, 3 d'octubre de 2014, a les 00:04:42, Aleix Pol va escriure: On Thu, Oct 2, 2014 at 11:34 PM, Ben Cooksley bcooks...@kde.org wrote: Hi all, It seems there has been a recent outbreak of repository moves which have been extremely poorly co-ordinated by those doing the requests. In addition, it is actually a requirement that modules moving from Extragear into (what was at least) the SC need to re-transit through KDE Review.It is also considered proper practice to at least inform the translation, documentation and release teams in advance you intend to make these moves - something which has also been neglected. For all further repository structure moves - please ensure you have received the appropriate consent from the above mentioned teams, and have announced them on the appropriate mailing lists in advance. @Plasma team: plasma-devel@kde.org does not constitute an appropriate mailing list, as it is not a community wide development mailing list. Only kde-devel and kde-core-devel qualify for this. Thanks, Ben Cooksley KDE Sysadmin My apologies, I shouldn't have rushed into doing such moves and send e-mails to all the interested parties. If someone considers it appropriate, I can roll some of the changes back. Maybe you should explain the changes so people is aware of them :) Cheers, Albert Aleix Changes: - kde-gtk-config was moved from extragear/base to kde/workspace. - muon was moved from extragear/sysadmin to kde/workspace. That is, only projects.kde.org structure change. The reasoning is that this way they will be released together with Plasma Workspace. As they've been used they don't really make sense outside Plasma (especially the first) and we want to make sure that distros know these components are designed to work together with Plasma. I didn't notify kde-core-devel because it didn't occur to me that the community would have an opinion regarding whether it's me who releases the packages or Jonathan (who has been doing the Plasma packages). Cheers! Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120471: Add Registry::sync() signal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120471/ --- Review request for kwin, Plasma and Martin Gräßlin. Repository: kwayland Description --- Add Registry::sync() signal Emitted when the Wayland display is done flushing the initial interface callbacks, announcing wl_display properties. This can be used to compress events. Note that this signal is emitted only after announcing interfaces, such as outputs, but not after receiving callbacks of interface properties, such as the output's geometry, modes, etc.. This signal is emitted from the wl_display_sync callback. For this, we add a wl_callback_listener to the registry's Private, enqueue its events properly, if necessary, and trigger the signal through a callback mechanism similar to the wl_registry callbacks. This signal allows users of the API to find out when the signal emissions, such as outputAnnounced, etc. for all currently existing interfaces is complete. Diffs - src/client/registry.h 9e63a2b20c9734cc599f8c612441165b20d361bd src/client/registry.cpp 22f948488b88f2a9fbf2fd78f0d223d05585fe17 Diff: https://git.reviewboard.kde.org/r/120471/diff/ Testing --- tests in libkscreen exercise this feature, it works as expected, meaning I can notify when all initial synchronization is done. Thanks, Sebastian Kügler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
