Re: Moving repositories in the module structure
On Fri, Oct 3, 2014 at 11:33 AM, Víctor Blázquez victor.blazq...@kde.org wrote: I'm sorry for doing the move that fast, I should have realized it was sent only to plasma-devel No worries - in virtually all cases it is fine to process requests when we receive them. Víctor Blázquez Thanks, Ben 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
On Fri, Oct 3, 2014 at 2:28 PM, Aleix Pol aleix...@kde.org wrote: 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. I don't think it is necessary to revert the changes at the moment. 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). Who is doing the releasing doesn't matter as such. It is the move in location which matters here - various parts of our infrastructure rely on these locations. Translations for instance. Also, while this was only a Extragear to semi-SC module called kde/workspace move, such moves still probably need announcement so those interesting in reviewing the code, etc. can do so. Cheers! Aleix Thanks, Ben ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120489: Hide PrograssBar inner item when value is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- Review request for Plasma. Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120489: Hide PrograssBar inner item when value is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/#review67930 --- Your branch name in the review request doesn't make much sense, we're in frameworks here. There's a test file tests/components/progressbar.qml can you run that and check things still all look OK. (btw, if you *want* you can try using gerrit for this review request https://techbase.kde.org/Development/Gerrit we're trialling it for plasma-framework, it'd be nice to have the opinion from someone new.) - David Edmundson On Oct. 4, 2014, 8:03 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- (Updated Oct. 4, 2014, 8:03 p.m.) Review request for Plasma. Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120489: Hide PrograssBar inner item when value is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- (Updated Okt. 4, 2014, 8:27 nachm.) Review request for Plasma. Changes --- Removed branch Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request 120491: Add indeterminate ProgressBar to test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120491/ --- Review request for Plasma. Repository: plasma-framework Description --- Adds an indeterminate ProgressBar to verify the animation is running properly and a checkbox to turn it on and off to see if the transition between those two states works properly. Diffs - tests/components/progressbar.qml a43b113 Diff: https://git.reviewboard.kde.org/r/120491/diff/ Testing --- Showed that switching this to an Animator is not as trivial as I thought :) Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120489: Hide PrograssBar inner item when value is 0
On Okt. 4, 2014, 8:20 nachm., David Edmundson wrote: Your branch name in the review request doesn't make much sense, we're in frameworks here. There's a test file tests/components/progressbar.qml can you run that and check things still all look OK. (btw, if you *want* you can try using gerrit for this review request https://techbase.kde.org/Development/Gerrit we're trialling it for plasma-framework, it'd be nice to have the opinion from someone new.) Yeah didn't yet have the mood to try it. Ran the test and everything works as expected. - Kai Uwe --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/#review67930 --- On Okt. 4, 2014, 8:27 nachm., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- (Updated Okt. 4, 2014, 8:27 nachm.) Review request for Plasma. Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120489: Hide PrograssBar inner item when value is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/#review67932 --- Ship it! Ship It! - David Edmundson On Oct. 4, 2014, 8:27 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- (Updated Oct. 4, 2014, 8:27 p.m.) Review request for Plasma. Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120491: Add indeterminate ProgressBar to test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120491/#review67933 --- Ship it! Ship It! - David Edmundson On Oct. 4, 2014, 8:29 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120491/ --- (Updated Oct. 4, 2014, 8:29 p.m.) Review request for Plasma. Repository: plasma-framework Description --- Adds an indeterminate ProgressBar to verify the animation is running properly and a checkbox to turn it on and off to see if the transition between those two states works properly. Diffs - tests/components/progressbar.qml a43b113 Diff: https://git.reviewboard.kde.org/r/120491/diff/ Testing --- Showed that switching this to an Animator is not as trivial as I thought :) Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120491: Add indeterminate ProgressBar to test
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120491/ --- (Updated Oct. 4, 2014, 8:41 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- Adds an indeterminate ProgressBar to verify the animation is running properly and a checkbox to turn it on and off to see if the transition between those two states works properly. Diffs - tests/components/progressbar.qml a43b113 Diff: https://git.reviewboard.kde.org/r/120491/diff/ Testing --- Showed that switching this to an Animator is not as trivial as I thought :) Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 120489: Hide PrograssBar inner item when value is 0
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120489/ --- (Updated Oct. 4, 2014, 8:42 p.m.) Status -- This change has been marked as submitted. Review request for Plasma. Repository: plasma-framework Description --- To prevent the SvgItem from leaking outside, there is a minimum size (being the margins) enforced. This leads to the situation where an empty progress bar still shows a little spot on the left. This patch fixes this. Diffs - src/declarativeimports/plasmacomponents/qml/ProgressBar.qml b872c97 Diff: https://git.reviewboard.kde.org/r/120489/diff/ Testing --- Change brightness to zero, no more couple of pixels area in the progress bar. Thanks, Kai Uwe Broulik ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Dark themes
Hello all, I just realized that in pushing the Breeze Dark color scheme to the Plasma/5.1 branch of the breeze repo, it likely violates the string freeze (the name of the color scheme). So when I pushed the new Breeze Dark icon theme I only pushed it to master since the icon theme name and description are new strings. The Breeze Dark icon theme allows the user to select an icon theme that provides appropriate monochrome icon contrast for dark application color schemes and also for the already-available Breeze Dark plasma theme. In the latter case it provides some remedy for the icon visibility issues where icons from the main icon theme are displayed (like on the Application Launcher Leave tab, taskbar, etc.). So now I'm not sure what the least bad result is; A. Leave the breeze repo Plasma/5.1 branch as is with no remedy for the main icon theme visibility issues with dark color schemes or the Breeze Dark plasma theme OR B. Revert the Breeze Dark color scheme commit in respect of string freeze with similar downsides as A OR C. Further violate the string freeze by pushing the Breeze Dark icon theme to the Plasma/5.1 branch to provide a remedy for the icon visibility issues with dark application color schemes and with the Breeze Dark plasma theme. OR D. ? Of course the best solution would have been to get these changes in before the string freeze. For that I apologize. But here we are, and I need some help making a decision. Thanks much for your patience and help, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dark themes
On 05.10.2014 00:29, Andrew Lake wrote: C. Further violate the string freeze by pushing the Breeze Dark icon theme to the Plasma/5.1 branch to provide a remedy for the icon visibility issues with dark application color schemes and with the I don't think violating string freeze is critical for this. Our theme selection UIs usually provide visual feedback to get an idea of what an entry actually is/does, and the name functions more as, well, a name, or a brand, or however you want to put it. Realistically, nobody is going to stare at the screen in puzzlement over what Dark means in this context. That said, the standard protocol is to mail kde-i18n-doc and ask for a string freeze exception - the people with the relevant opinion here are our translators, not actually you or me. Thanks much for your patience and help, Andrew Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dark themes
On Sat, Oct 4, 2014 at 3:35 PM, Eike Hein wrote: On 05.10.2014 00:29, Andrew Lake wrote: C. Further violate the string freeze by pushing the Breeze Dark icon theme to the Plasma/5.1 branch to provide a remedy for the icon visibility issues with dark application color schemes and with the I don't think violating string freeze is critical for this. Our theme selection UIs usually provide visual feedback to get an idea of what an entry actually is/does, and the name functions more as, well, a name, or a brand, or however you want to put it. Realistically, nobody is going to stare at the screen in puzzlement over what Dark means in this context. That said, the standard protocol is to mail kde-i18n-doc and ask for a string freeze exception - the people with the relevant opinion here are our translators, not actually you or me. Thanks much Eike. I'll make the request for an exception if there are no objections to option C from others here. Much respect, Andrew ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dark themes
Thanks much Eike. I'll make the request for an exception if there are no objections to option C from others here. No objections from me. We may as well ask translators anyway. If they say no then we'll at least know what our options are. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Dark themes
On 05.10.2014 00:49, Andrew Lake wrote: Thanks much Eike. I'll make the request for an exception if there are no objections to option C from others here. And thanks for the theme work, btw - big fan of the Dark versions :) Much respect, Andrew Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
