[KDE Bugtracking System] REMINDER: current Plasma regressions

2014-10-02 Thread bugzilla_noreply
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

2014-10-02 Thread Jens Reuterberg
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

2014-10-02 Thread KDE CI System
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

2014-10-02 Thread Eike Hein



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

2014-10-02 Thread Martin Klapetek
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

2014-10-02 Thread Marco Martin
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

2014-10-02 Thread KDE CI System
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

2014-10-02 Thread Martin Klapetek

---
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

2014-10-02 Thread Martin Klapetek

---
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

2014-10-02 Thread Marco Martin

---
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

2014-10-02 Thread Sebastian Kügler

---
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

2014-10-02 Thread Kai Uwe Broulik

---
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

2014-10-02 Thread Kai Uwe Broulik

---
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

2014-10-02 Thread Martin Klapetek


 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

2014-10-02 Thread Martin Klapetek


 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

2014-10-02 Thread Martin Klapetek

---
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

2014-10-02 Thread Andrew Lake
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

2014-10-02 Thread Aleix Pol
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

2014-10-02 Thread Jens Reuterberg
[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

2014-10-02 Thread Lukáš Tinkl

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

2014-10-02 Thread Marco Martin
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

2014-10-02 Thread Andrew Lake
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

2014-10-02 Thread Albert Astals Cid
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

2014-10-02 Thread Weng Xuetian
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

2014-10-02 Thread Ben Cooksley
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

2014-10-02 Thread Albert Astals Cid
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

2014-10-02 Thread Aleix Pol
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

2014-10-02 Thread Víctor Blázquez
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

2014-10-02 Thread Albert Astals Cid
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

2014-10-02 Thread Aleix Pol
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

2014-10-02 Thread Sebastian Kügler

---
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