Re: Review Request 122533: Port accessibility kcm somewhat to xcb xkb

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122533/#review75900
---



kcms/access/kaccess.h


we normally use camel case:  without any prefix



kcms/access/kaccess.cpp


Is there no event type defined in xkb?



kcms/access/kaccess.cpp


Please use the xcb enum values instead of the Xlib defines:
*  XCB_XKB_EVENT_TYPE_STATE_NOTIFY
*  XCB_XKB_EVENT_TYPE_BELL_NOTIFY
*  XCB_XKB_EVENT_TYPE_CONTROLS_NOTIFY



kcms/access/kaccess.cpp


we normally use reinterpret_cast instead of c-casts



kcms/access/kaccess.cpp


here I would also suggest to switch to the enum values from xcb.


- Martin Gräßlin


On Feb. 11, 2015, 10:25 p.m., Frederik Gladhorn wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122533/
> ---
> 
> (Updated Feb. 11, 2015, 10:25 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> I don't really speak xcb, so I'd appreciate if someone could look over this 
> for sanity's sake. The patch seems relatively straight forward to me though. 
> I wonder how broken the old code was, it seems to have been rotting for a 
> while.
> 
> 
> Diffs
> -
> 
>   kcms/access/kaccess.h e101de4 
>   kcms/access/kaccess.cpp 2419efb 
> 
> Diff: https://git.reviewboard.kde.org/r/122533/diff/
> 
> 
> Testing
> ---
> 
> After this change sticky keys and some of the other features seem to work 
> again.
> 
> 
> Thanks,
> 
> Frederik Gladhorn
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122510: [screenlocker] Mark session as idle in logind while screen is locked

[Martin Gräßlin]

> On Feb. 10, 2015, 2:29 p.m., David Edmundson wrote:
> > I'm not convinced this is right.
> > 
> > From the doc you linked: 
> >  This is necessary for the system to implement auto-suspend when all 
> > sessions are idle.
> >  
> > When we lock the screen, powerdevil is still running, no?
> > 
> > Powerdevil has an inhibition blocking logind suspending, so I think overall 
> > this will just do nothing.
> 
> Martin Gräßlin wrote:
> The linked bug report gives another use case: cross-desktop check to see 
> whether the session is idle.
> 
> > Powerdevil has an inhibition blocking logind suspending, so I think 
> overall this will just do nothing.
> 
> Why is powerdevil holding an inhibition lock?
> 
> David Edmundson wrote:
> So we can implement auto suspend / key handling based on the user's KDE 
> configs, not based on some global configs.
> 
> Kai Uwe Broulik wrote:
> PowerDevil inhibits the following: 
> ["handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch",
>  "PowerDevil", "KDE handles power events", "block"]
> Also, "IdleAction" is "ignore" here.

If I understand that correctly David's concern doesn't hold?


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122510/#review75777
---


On Feb. 10, 2015, 2:21 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122510/
> ---
> 
> (Updated Feb. 10, 2015, 2:21 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 271731
> https://bugs.kde.org/show_bug.cgi?id=271731
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> See the idle recommendations on [1]. Binding it to the lock screen does
> not exactly match the recommendation, but it has some advantages:
> * we know it's idle when it's locked
> * it kicks in after the user's configured idle timeout
> * if the user unlocks we know it's no longer idle
> 
> FEATURE: 271731
> FIXED-IN: 5.3.0
> 
> [1] 
> http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp e23b50fbcaac659bb6ef1b36a4de6efc63573978 
>   ksmserver/screenlocker/logind.h 99836734923740a1f0b23144f9effd815f104b74 
>   ksmserver/screenlocker/logind.cpp 5335b150bce8f38aee75ad30055bc0e248ed1bf1 
> 
> Diff: https://git.reviewboard.kde.org/r/122510/diff/
> 
> 
> Testing
> ---
> 
> Run the test application and verified using loginctl from tty1 while the 
> screen was locked and after unlocked.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122331: Add libinput support to kcm-touchpad

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122331/#review75896
---

Ship it!


Built my X with libinput support.

Without this patch I get an erro, with this I get at least some options, though 
quite a few seemed disabled as they're just not available in libinput.

- David Edmundson


On Jan. 30, 2015, 7:41 p.m., Rajeesh K Nambiar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122331/
> ---
> 
> (Updated Jan. 30, 2015, 7:41 p.m.)
> 
> 
> Review request for Plasma, Alexander Mezin and Martin Gräßlin.
> 
> 
> Repository: kcm-touchpad
> 
> 
> Description
> ---
> 
> ibinput is a library to handle input devices in Wayland compositors and to 
> provide a generic X.Org input driver. Add libinput support to kcm-touchpad.
> Patch authored by Peter Hutterer.
> 
> 
> Diffs
> -
> 
>   src/kcm/touchpad.kcfg 2afe642 
>   src/kcm/ui/tap.ui 8e081ad 
>   src/touchpadbackend.cpp 93e3dc2 
>   src/backends/x11.cmake f208281 
>   src/backends/x11/libinputproperties.c PRE-CREATION 
>   src/backends/x11/synclientproperties.h 5b32b9f 
>   src/backends/x11/xlibbackend.h 3692a60 
>   src/backends/x11/xlibbackend.cpp 3b5e5be 
>   src/kcm/customconfigdialogmanager.cpp 75b03ab 
> 
> Diff: https://git.reviewboard.kde.org/r/122331/diff/
> 
> 
> Testing
> ---
> 
> Fedora 21 RPM built and tested with Plasma 5.2.
> RPMs available here for testing: 
> https://copr-be.cloud.fedoraproject.org/results/rajeeshknambiar/kf5-kde-apps/fedora-21-x86_64/kf5-kcm_touchpad-5.1.96-1.fc21/
> 
> 
> Thanks,
> 
> Rajeesh K Nambiar
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 122540: Add screen reader to Accessibility KCM

[Frederik Gladhorn]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122540/
---

Review request for Plasma, Jonathan Riddell, Sebastian Sauer, and Jeremy 
Whiting.


Repository: plasma-desktop


Description
---

This patch adds a simple check box to the KCM which enables the screen
reader.
It additionally sets up the default shortcut - Meta-Alt-S which is the
same as in Gnome. Using the same shortcut is of course extremely
important, since blind users rely on an easy way to activeate the screen
reader.

For now the whole process is hard-coded to Orca since there are no real
alternatives for Linux screen readers at the moment.

The gconfig call which disables the screen reader will make Orca exit.
It still needs to be launched manually.

I don't have much time for cleaning up the KCM, so help would be very much 
appreciated.
There are a lot of low hanging fruits for cleanup there. Also the port to kf5, 
away from deprecated stuff is by far not complete.


Diffs
-

  kcms/access/CMakeLists.txt 55990d2 
  kcms/access/accessibility.ui 2e0db83 
  kcms/access/kaccess.h e101de4 
  kcms/access/kaccess.cpp 2419efb 
  kcms/access/kcmaccess.cpp 7e0217d 

Diff: https://git.reviewboard.kde.org/r/122540/diff/


Testing
---

This allows me to start and stop Orca using meta-alt-s or the kcm.


Thanks,

Frederik Gladhorn

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Change in plasma-framework[master]: Put all non tiled frame textures in the atlas

[David Edmundson (Code Review)]

David Edmundson has uploaded a new change for review.

  https://gerrit.vesnicky.cesnet.cz/r/370

Change subject: Put all non tiled frame textures in the atlas
..

Put all non tiled frame textures in the atlas

Change-Id: I2525998ab3c1c76870fe8e395051127a673979af
---
M src/declarativeimports/core/framesvgitem.cpp
1 file changed, 17 insertions(+), 3 deletions(-)


  git pull ssh://gerrit.vesnicky.cesnet.cz:29418/plasma-framework 
refs/changes/70/370/1

diff --git a/src/declarativeimports/core/framesvgitem.cpp 
b/src/declarativeimports/core/framesvgitem.cpp
index 589b103..fff1a89 100644
--- a/src/declarativeimports/core/framesvgitem.cpp
+++ b/src/declarativeimports/core/framesvgitem.cpp
@@ -121,7 +121,11 @@
 
 void updateTexture(const QSize &size, const QString &elementId)
 {
-setTexture(s_cache->loadTexture(m_frameSvg->window(), 
m_frameSvg->frameSvg()->image(size, elementId)));
+QQuickWindow::CreateTextureOptions options;
+if (m_fitMode != Tile) {
+options = QQuickWindow::TextureCanUseAtlas;
+}
+setTexture(s_cache->loadTexture(m_frameSvg->window(), 
m_frameSvg->frameSvg()->image(size, elementId), options));
 }
 
 void reposition(const QRect& frameGeometry, QSize& fullSize)
@@ -132,11 +136,18 @@
 if(!nodeRect.isValid() || nodeRect.isEmpty())
 nodeRect = QRect();
 
-QRectF textureRect = QRectF(0,0,1,1);
+//the position of the relevant texture within this texture ID.
+//for atlas' this will only be a small part of the texture
+QRectF textureRect;
+
 if (m_fitMode == Tile) {
+textureRect = QRectF(0,0,1,1); //we can never be in an atlas for 
tiled images.
+
+//if tiling horizontally
 if (m_border == FrameSvg::TopBorder || m_border == 
FrameSvg::BottomBorder || m_border == FrameSvg::NoBorder) {
 textureRect.setWidth(nodeRect.width() / 
m_elementNativeSize.width());
 }
+//if tiling vertically
 if (m_border == FrameSvg::LeftBorder || m_border == 
FrameSvg::RightBorder || m_border == FrameSvg::NoBorder) {
 textureRect.setHeight(nodeRect.height() / 
m_elementNativeSize.height());
 }
@@ -147,7 +158,10 @@
 
 //re-render the SVG at new size
 updateTexture(nodeRect.size(), elementId);
-} // for fast stretch, we don't have to do anything
+textureRect = texture()->normalizedTextureSubRect();
+} else if (texture()) { // for fast stretch.
+textureRect = texture()->normalizedTextureSubRect();
+}
 
 QSGGeometry::updateTexturedRectGeometry(geometry(), nodeRect, 
textureRect);
 markDirty(QSGNode::DirtyGeometry);

-- 
To view, visit https://gerrit.vesnicky.cesnet.cz/r/370
To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I2525998ab3c1c76870fe8e395051127a673979af
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: David Edmundson 
Gerrit-Reviewer: Aleix Pol Gonzalez 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Thomas Pfeiffer]

> On Feb. 10, 2015, 11:50 p.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.
> 
> Emmanuel Pescosta wrote:
> 0% means backlight off on this notebook, but the user interface doesn't 
> allow to turn it off on Windows (maybe they check if a screen off/on key is 
> available?)
> When I test it with Powerdevil, then the screen turns off when I drag the 
> slider to 0%.
> 
> So there is a difference between 0% on the UI and 0% on the hardware side 
> on Windows.
> 
> Heiko Tietze wrote:
> I'd like to suppport Thomas position be mentioning Android's behaviour: 
> you switch off the backlight by hardware key but adjust the setting 
> differently per slider. Two use cases, two ways of interaction.
> 
> If we only could discuss all settings in such a depth... ;-)
> 
> Martin Klapetek wrote:
> I really don't think you can compare laptops and (touch)phones. That's 
> apples (but not only;) and oranges.
> 
> Thomas Pfeiffer wrote:
> Martin: Does OS-X really allow to turn the screen off by pushing the 
> brightness slider to zero? With the only way to turn it back on being via 
> hardware keys? Even if they do, though, there is still a difference: Apple 
> _knows_ for a fact that all devices (legally) running OS X have those 
> hardware buttons. We can't be sure.
> 
> Really, it's a simple logic: Don't allow the user to make a change that 
> can't be reversed by the same means. Therefore, don't allow to switch off the 
> screen via the slider. If a laptop has brightness keys, users can switch the 
> screen off using those keys, and switch it back on using the same keys.
> 
> And no, we don't need an expert setting to still allow sliding to off. I 
> simply cannot believe that any user would be seriously pissed off because 
> they need to use the keyboard to turn off their screen. It's not difficult.
> 
> We can discuss that as long as you guys want, but I won't back down on 
> basic usability principles.
> 
> Martin Klapetek wrote:
> > Martin: Does OS-X really allow to turn the screen off by pushing the 
> brightness slider to zero? 
> 
> Yes. But as you say, this will *always* work (I'm not even sure if they 
> have a slider at all).
> 
> > Really, it's a simple logic: Don't allow the user to make a change that 
> can't be reversed by the same means. Therefore, don't allow to switch off the 
> screen via the slider. 
> 
> Yes, I totally agree with that (I was also supporting this cha

Re: Review Request 122533: Port accessibility kcm somewhat to xcb xkb

[Frederik Gladhorn]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122533/
---

(Updated Feb. 11, 2015, 9:25 p.m.)


Review request for Plasma.


Changes
---

and actually remove the debug output...


Repository: plasma-desktop


Description
---

I don't really speak xcb, so I'd appreciate if someone could look over this for 
sanity's sake. The patch seems relatively straight forward to me though. I 
wonder how broken the old code was, it seems to have been rotting for a while.


Diffs (updated)
-

  kcms/access/kaccess.h e101de4 
  kcms/access/kaccess.cpp 2419efb 

Diff: https://git.reviewboard.kde.org/r/122533/diff/


Testing
---

After this change sticky keys and some of the other features seem to work again.


Thanks,

Frederik Gladhorn

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122533: Port accessibility kcm somewhat to xcb xkb

[Frederik Gladhorn]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122533/
---

(Updated Feb. 11, 2015, 9:24 p.m.)


Review request for Plasma.


Changes
---

removed useless debug output


Repository: plasma-desktop


Description
---

I don't really speak xcb, so I'd appreciate if someone could look over this for 
sanity's sake. The patch seems relatively straight forward to me though. I 
wonder how broken the old code was, it seems to have been rotting for a while.


Diffs (updated)
-

  kcms/access/kaccess.h e101de4 
  kcms/access/kaccess.cpp 2419efb 

Diff: https://git.reviewboard.kde.org/r/122533/diff/


Testing
---

After this change sticky keys and some of the other features seem to work again.


Thanks,

Frederik Gladhorn

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.
> 
> Emmanuel Pescosta wrote:
> 0% means backlight off on this notebook, but the user interface doesn't 
> allow to turn it off on Windows (maybe they check if a screen off/on key is 
> available?)
> When I test it with Powerdevil, then the screen turns off when I drag the 
> slider to 0%.
> 
> So there is a difference between 0% on the UI and 0% on the hardware side 
> on Windows.
> 
> Heiko Tietze wrote:
> I'd like to suppport Thomas position be mentioning Android's behaviour: 
> you switch off the backlight by hardware key but adjust the setting 
> differently per slider. Two use cases, two ways of interaction.
> 
> If we only could discuss all settings in such a depth... ;-)
> 
> Martin Klapetek wrote:
> I really don't think you can compare laptops and (touch)phones. That's 
> apples (but not only;) and oranges.
> 
> Thomas Pfeiffer wrote:
> Martin: Does OS-X really allow to turn the screen off by pushing the 
> brightness slider to zero? With the only way to turn it back on being via 
> hardware keys? Even if they do, though, there is still a difference: Apple 
> _knows_ for a fact that all devices (legally) running OS X have those 
> hardware buttons. We can't be sure.
> 
> Really, it's a simple logic: Don't allow the user to make a change that 
> can't be reversed by the same means. Therefore, don't allow to switch off the 
> screen via the slider. If a laptop has brightness keys, users can switch the 
> screen off using those keys, and switch it back on using the same keys.
> 
> And no, we don't need an expert setting to still allow sliding to off. I 
> simply cannot believe that any user would be seriously pissed off because 
> they need to use the keyboard to turn off their screen. It's not difficult.
> 
> We can discuss that as long as you guys want, but I won't back down on 
> basic usability principles.

> Martin: Does OS-X really allow to turn the screen off by pushing the 
> brightness slider to zero? 

Yes. But as you say, this will *always* work (I'm not even sure if they have a 
slider at all).

> Really, it's a simple logic: Don't allow the user to make a change that can't 
> be reversed by the same means. Therefore, don't allow to switch off the 
> screen via the slider. 

Yes, I totally agree with that (I was also supporting this change all along).

> We can discuss that as long as you guys want, but I 

Re: Review Request 122505: Warn about brightness getting too low

[Thomas Pfeiffer]

> On Feb. 10, 2015, 9:01 a.m., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the 

Re: Review Request 122505: Warn about brightness getting too low

[Kai Uwe Broulik]

> On Feb. 10, 2015, 9:01 vorm., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the

Re: Review Request 122505: Warn about brightness getting too low

[Ken Vermette]

> On Feb. 10, 2015, 9:01 a.m., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the 

Review Request 122533: Port accessibility kcm somewhat to xcb xkb

[Frederik Gladhorn]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122533/
---

Review request for Plasma.


Repository: plasma-desktop


Description
---

I don't really speak xcb, so I'd appreciate if someone could look over this for 
sanity's sake. The patch seems relatively straight forward to me though. I 
wonder how broken the old code was, it seems to have been rotting for a while.


Diffs
-

  kcms/access/kaccess.h e101de4 
  kcms/access/kaccess.cpp 2419efb 

Diff: https://git.reviewboard.kde.org/r/122533/diff/


Testing
---

After this change sticky keys and some of the other features seem to work again.


Thanks,

Frederik Gladhorn

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Thomas Pfeiffer]

> On Feb. 10, 2015, 11:50 p.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.
> 
> Emmanuel Pescosta wrote:
> 0% means backlight off on this notebook, but the user interface doesn't 
> allow to turn it off on Windows (maybe they check if a screen off/on key is 
> available?)
> When I test it with Powerdevil, then the screen turns off when I drag the 
> slider to 0%.
> 
> So there is a difference between 0% on the UI and 0% on the hardware side 
> on Windows.
> 
> Heiko Tietze wrote:
> I'd like to suppport Thomas position be mentioning Android's behaviour: 
> you switch off the backlight by hardware key but adjust the setting 
> differently per slider. Two use cases, two ways of interaction.
> 
> If we only could discuss all settings in such a depth... ;-)
> 
> Martin Klapetek wrote:
> I really don't think you can compare laptops and (touch)phones. That's 
> apples (but not only;) and oranges.

Martin: Does OS-X really allow to turn the screen off by pushing the brightness 
slider to zero? With the only way to turn it back on being via hardware keys? 
Even if they do, though, there is still a difference: Apple _knows_ for a fact 
that all devices (legally) running OS X have those hardware buttons. We can't 
be sure.

Really, it's a simple logic: Don't allow the user to make a change that can't 
be reversed by the same means. Therefore, don't allow to switch off the screen 
via the slider. If a laptop has brightness keys, users can switch the screen 
off using those keys, and switch it back on using the same keys.

And no, we don't need an expert setting to still allow sliding to off. I simply 
cannot believe that any user would be seriously pissed off because they need to 
use the keyboard to turn off their screen. It's not difficult.

We can discuss that as long as you guys want, but I won't back down on basic 
usability principles.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 10:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 10:25 p.m.)
> 
> 
> Review request for Plasm

Re: theme mixing

[Jens Reuterberg]

Well there was talk about some easy way to edit colors and spacing of 
individual SVG-files (I mean it IS reaaally complex to edit themes)... 
Might be worth looking into?


Pedro: I can only suggest that you try to edit them in Karbon instead 
of Inkscape since it contains a better sorting of objects in files. 
(although saving it is a pest in Karbon)


On Mon, 9 Feb, 2015 at 2:04 PM, Sebastian Kügler  wrote:

Hi Pedro,

On Sunday, February 08, 2015 12:10:12 Pedro Rosado wrote:
 I don't know if this is the right place, but I wanted to suggest 
something.


 KDE is by far the most modern and efficient desktop I've came to 
know (not
 dissing all the others), but regarding customization it's falling a 
little
 behind. Compared to gnome-look org, KDE look feels abandoned and 
there
 aren't many themes available at all, most are not even online 
anymore (host
 site doesn't have the file anymore). Most themes work like a charm 
on
 plasma 5, it's not like gnome that breaks a theme everytime it's 
updated.


 So, could the kde development theme  give end users a tool to 
combine or
 make their own themes with a user friendly interface? I've tried 
myself to
 make a kwin theme - only found despair and wasted time looking 
inside svg

 files (I'm an end user, not an IT guy :c  )
 Also, it would be nice to have all those themes shared if you want 
to, so
 that the whole community can use them. Instead of searching themes 
on the
 settings (that most times doesn't work because the files aren't 
hosted
 anymore at kde look.org), users could have this "customization" 
tool that
 allows users to search and create themes and share them into a repo 
or
 github so that anyone can find them and use them, independent of 
distro (as

 long as you are using kde)

 Summary:
 - Easy tool to make kwin and desktop themes for kde
 - Able to share and download the themes from the desktop app
 - kde kicks ass


You can mix-and-match workspace themes in systemsettings, go to 
"Workspace
Theme" -> "Desktop Theme" -> "Details". This allows you to combine 
elements
from different themes convienently in the UI. If that doesn't allow 
you to do
what you'd like to, it indeed comes down to managing SVG files and 
combining
them into a new theme. You've already found that out, it's a bit 
fiddly, but
so is anything advanced enough to satisfy the complex need for a 
complete

theming system.

As to the quality of kde-look.org, we cannot do much about it, since 
it's a
community-run site, which doesn't receive much love in terms of 
maintainance

and content curation, unfortunately.

Cheers,
--
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
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: Review Request 122510: [screenlocker] Mark session as idle in logind while screen is locked

[Kai Uwe Broulik]

> On Feb. 10, 2015, 1:29 nachm., David Edmundson wrote:
> > I'm not convinced this is right.
> > 
> > From the doc you linked: 
> >  This is necessary for the system to implement auto-suspend when all 
> > sessions are idle.
> >  
> > When we lock the screen, powerdevil is still running, no?
> > 
> > Powerdevil has an inhibition blocking logind suspending, so I think overall 
> > this will just do nothing.
> 
> Martin Gräßlin wrote:
> The linked bug report gives another use case: cross-desktop check to see 
> whether the session is idle.
> 
> > Powerdevil has an inhibition blocking logind suspending, so I think 
> overall this will just do nothing.
> 
> Why is powerdevil holding an inhibition lock?
> 
> David Edmundson wrote:
> So we can implement auto suspend / key handling based on the user's KDE 
> configs, not based on some global configs.

PowerDevil inhibits the following: 
["handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch", 
"PowerDevil", "KDE handles power events", "block"]
Also, "IdleAction" is "ignore" here.


- Kai Uwe


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122510/#review75777
---


On Feb. 10, 2015, 1:21 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122510/
> ---
> 
> (Updated Feb. 10, 2015, 1:21 nachm.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 271731
> https://bugs.kde.org/show_bug.cgi?id=271731
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> See the idle recommendations on [1]. Binding it to the lock screen does
> not exactly match the recommendation, but it has some advantages:
> * we know it's idle when it's locked
> * it kicks in after the user's configured idle timeout
> * if the user unlocks we know it's no longer idle
> 
> FEATURE: 271731
> FIXED-IN: 5.3.0
> 
> [1] 
> http://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/
> 
> 
> Diffs
> -
> 
>   ksmserver/screenlocker/ksldapp.cpp e23b50fbcaac659bb6ef1b36a4de6efc63573978 
>   ksmserver/screenlocker/logind.h 99836734923740a1f0b23144f9effd815f104b74 
>   ksmserver/screenlocker/logind.cpp 5335b150bce8f38aee75ad30055bc0e248ed1bf1 
> 
> Diff: https://git.reviewboard.kde.org/r/122510/diff/
> 
> 
> Testing
> ---
> 
> Run the test application and verified using loginctl from tty1 while the 
> screen was locked and after unlocked.
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Marco Martin]

> On Feb. 11, 2015, 4:14 p.m., Andrew Lake wrote:
> > It might be worth investigating the use-case a bit further to try to 
> > understand if this is the best way to solve this. Is it useful? Yes. But 
> > there are potentiall negative impacts that should be balanced against the 
> > relative increase in utility.
> > 
> > We also need to belly up to identifying primary and secondary target 
> > personas and scenarios for Plasma (maybe a thing for the upcomign sprint). 
> > At best, I'd suggest that exposing the host name here would target a 
> > secondary persona and any associated scenarios. 
> > 
> > While I can't argue that the scenario in the bug report isn't legitimate, 
> > I'm not sure it warrants adding information to the lock-screen that is of 
> > little-to-no value to primary target personas and scenarios. The cost we're 
> > trying to mitigate in the bug report is that the user logs in/unlocks to 
> > identify the computer versus knowing it one interaction step earlier. 
> > 
> > For the lab/shared computers, the scenario requires that more than one 
> > computer is shared (probably in relative proximity to each other) and some 
> > particular need that requires knowing the computer identity *before* 
> > logging in/unlocking. Even in corporate environments that seems like quite 
> > a marginal scenario.
> > 
> > So for me, I'm struggling to see how the potentially negative impact of 
> > added information noise for what I think are the primary target personas 
> > and scenarios balances what is, I think, a marginal increase in utility for 
> > a marginal scenario for a secondary target persona.
> > 
> > Hope this helps!
> 
> Martin Gräßlin wrote:
> Thanks for your feedback. I'm wondering whether we could make the 
> information easily available without adding noise in general. I really think 
> it's worth to invest the effort to provide this data as it's important in the 
> situations when it's needed (e.g. labs).
> 
> Aleix Pol Gonzalez wrote:
> Would it be possible to use something like Kiosk to decide what 
> information to show?
> Such deployments usually mingle with Kiosk.

yeah, didn't chime in on this one so far but i agree with Andrew
could be enabled as aleix says with kiosk (that would mean pretty much an 
hidden config option, which poses the problem that will make it bitrot.
or could be just supposed for deployers to customize the look and feel 
package.. will ask them to maintain qml code that's a bit nasty as well


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75870
---


On Feb. 11, 2015, 1:59 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 1:59 p.m.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Aleix Pol Gonzalez]

> On Feb. 11, 2015, 5:14 p.m., Andrew Lake wrote:
> > It might be worth investigating the use-case a bit further to try to 
> > understand if this is the best way to solve this. Is it useful? Yes. But 
> > there are potentiall negative impacts that should be balanced against the 
> > relative increase in utility.
> > 
> > We also need to belly up to identifying primary and secondary target 
> > personas and scenarios for Plasma (maybe a thing for the upcomign sprint). 
> > At best, I'd suggest that exposing the host name here would target a 
> > secondary persona and any associated scenarios. 
> > 
> > While I can't argue that the scenario in the bug report isn't legitimate, 
> > I'm not sure it warrants adding information to the lock-screen that is of 
> > little-to-no value to primary target personas and scenarios. The cost we're 
> > trying to mitigate in the bug report is that the user logs in/unlocks to 
> > identify the computer versus knowing it one interaction step earlier. 
> > 
> > For the lab/shared computers, the scenario requires that more than one 
> > computer is shared (probably in relative proximity to each other) and some 
> > particular need that requires knowing the computer identity *before* 
> > logging in/unlocking. Even in corporate environments that seems like quite 
> > a marginal scenario.
> > 
> > So for me, I'm struggling to see how the potentially negative impact of 
> > added information noise for what I think are the primary target personas 
> > and scenarios balances what is, I think, a marginal increase in utility for 
> > a marginal scenario for a secondary target persona.
> > 
> > Hope this helps!
> 
> Martin Gräßlin wrote:
> Thanks for your feedback. I'm wondering whether we could make the 
> information easily available without adding noise in general. I really think 
> it's worth to invest the effort to provide this data as it's important in the 
> situations when it's needed (e.g. labs).

Would it be possible to use something like Kiosk to decide what information to 
show?
Such deployments usually mingle with Kiosk.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75870
---


On Feb. 11, 2015, 2:59 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:59 p.m.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Martin Gräßlin]

> On Feb. 11, 2015, 5:14 nachm., Andrew Lake wrote:
> > It might be worth investigating the use-case a bit further to try to 
> > understand if this is the best way to solve this. Is it useful? Yes. But 
> > there are potentiall negative impacts that should be balanced against the 
> > relative increase in utility.
> > 
> > We also need to belly up to identifying primary and secondary target 
> > personas and scenarios for Plasma (maybe a thing for the upcomign sprint). 
> > At best, I'd suggest that exposing the host name here would target a 
> > secondary persona and any associated scenarios. 
> > 
> > While I can't argue that the scenario in the bug report isn't legitimate, 
> > I'm not sure it warrants adding information to the lock-screen that is of 
> > little-to-no value to primary target personas and scenarios. The cost we're 
> > trying to mitigate in the bug report is that the user logs in/unlocks to 
> > identify the computer versus knowing it one interaction step earlier. 
> > 
> > For the lab/shared computers, the scenario requires that more than one 
> > computer is shared (probably in relative proximity to each other) and some 
> > particular need that requires knowing the computer identity *before* 
> > logging in/unlocking. Even in corporate environments that seems like quite 
> > a marginal scenario.
> > 
> > So for me, I'm struggling to see how the potentially negative impact of 
> > added information noise for what I think are the primary target personas 
> > and scenarios balances what is, I think, a marginal increase in utility for 
> > a marginal scenario for a secondary target persona.
> > 
> > Hope this helps!

Thanks for your feedback. I'm wondering whether we could make the information 
easily available without adding noise in general. I really think it's worth to 
invest the effort to provide this data as it's important in the situations when 
it's needed (e.g. labs).


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75870
---


On Feb. 11, 2015, 2:59 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:59 nachm.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Build failed in Jenkins: plasma-workspace_master_qt5 #1307

[KDE CI System]

See 

Changes:

[notmart] port package structures to KPackage

[notmart] start porting the widget explorer to KPackage

[notmart] port image wallpaper to KPackage

[notmart] port plasmashell to KPackage

[notmart] port plasmawindowed to KPackage

[notmart] port ksplash to KPackage

[notmart] port screenlocker kcm to KPackage

[notmart] port screen locker greeter to KPackage

[notmart] port shutdown dialog to KPackage

[notmart] port krunner to KPackage::Package

[notmart] port Share package and engine to KPackage

[notmart] port interactiveconsole to KPackage

[notmart] fix wallpaper types list

[notmart] const-ify

[notmart] remove deprecated block

--
[...truncated 2592 lines...]

 ^
[ 72%] Built target plasma_engine_activities
[ 72%] Building CXX object 
dataengines/keystate/CMakeFiles/plasma_engine_keystate.dir/plasma_engine_keystate_automoc.cpp.o
Scanning dependencies of target plasma_engine_packagekit
[ 72%] Building CXX object 
dataengines/packagekit/CMakeFiles/plasma_engine_packagekit.dir/packagekitjob.cpp.o
[ 72%] Building CXX object 
dataengines/packagekit/CMakeFiles/plasma_engine_packagekit.dir/packagekitengine.cpp.o
Linking CXX shared module plasma_engine_hotplug.so
[ 72%] Built target plasma_engine_hotplug
Linking CXX shared library libsystemtrayplugin.so
[ 72%] Building CXX object 
dataengines/packagekit/CMakeFiles/plasma_engine_packagekit.dir/packagekitservice.cpp.o
Linking CXX shared module plasma_engine_keystate.so
Scanning dependencies of target plasma_engine_soliddevice
[ 72%] Building CXX object 
dataengines/soliddevice/CMakeFiles/plasma_engine_soliddevice.dir/soliddeviceengine.cpp.o
[ 72%] Built target plasma_engine_keystate
[ 73%] [ 73%] Building CXX object 
dataengines/soliddevice/CMakeFiles/plasma_engine_soliddevice.dir/devicesignalmapper.cpp.o
Generating krunner_interface.cpp, krunner_interface.h
[ 73%] Generating krunner_interface.cpp, krunner_interface.h
[ 73%] Generating krunner_interface.moc
[ 73%] Built target systemtrayplugin
[ 73%] Building CXX object 
dataengines/packagekit/CMakeFiles/plasma_engine_packagekit.dir/plasma_engine_packagekit_automoc.cpp.o
Scanning dependencies of target plasma_engine_powermanagement
[ 73%] Building CXX object 
dataengines/powermanagement/CMakeFiles/plasma_engine_powermanagement.dir/powermanagementengine.cpp.o
Scanning dependencies of target plasma_engine_places
[ 73%] Building CXX object 
dataengines/places/CMakeFiles/plasma_engine_places.dir/placesengine.cpp.o
[ 73%] Building CXX object 
dataengines/soliddevice/CMakeFiles/plasma_engine_soliddevice.dir/devicesignalmapmanager.cpp.o
Scanning dependencies of target plasma_engine_time
[ 73%] Building CXX object 
dataengines/time/CMakeFiles/plasma_engine_time.dir/timeengine.cpp.o
Linking CXX shared module plasma_engine_packagekit.so
:
 In member function ‘virtual bool 
PowermanagementEngine::sourceRequestEvent(const QString&)’:
:209:41:
 warning: ‘Solid::PowerManagement::Notifier* 
Solid::PowerManagement::notifier()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154)
 [-Wdeprecated-declarations]
 connect(Solid::PowerManagement::notifier(), 
SIGNAL(appShouldConserveResourcesChanged(bool)),
 ^
:209:50:
 warning: ‘Solid::PowerManagement::Notifier* 
Solid::PowerManagement::notifier()’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:154)
 [-Wdeprecated-declarations]
 connect(Solid::PowerManagement::notifier(), 
SIGNAL(appShouldConserveResourcesChanged(bool)),
  ^
:211:51:
 warning: ‘bool Solid::PowerManagement::appShouldConserveResources()’ is 
deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/solid/powermanagement.h:66)
 [-Wdeprecated-declarations]
 
updateAcPlugState(Solid::PowerManagement::appShouldConserveResources());
   ^
:211:78:
 warning: ‘bool Solid::PowerManagement::appShou

Re: Review Request 122524: Port to KPackage and away from sycoca

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/
---

(Updated Feb. 11, 2015, 5:01 p.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

this is the branch mart/KPackage.
it ports away the various stuff (shell, krunner, screenlocker.. ) using 
Plasma::Package to KPackage directly
the widget explorer/alternatives is also ported away from sycoca, using the new 
kpackage cache mechanism to query for applets


Diffs
-

  shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
  shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
48a6d52 
  shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
  shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
  
shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
 f870e0d 
  components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
  components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
  components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
  components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
  dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
  dataengines/share/packagestructure/share_package.h 31d0f6f 
  dataengines/share/packagestructure/share_package.cpp bd8567e 
  dataengines/share/shareservice.h 8f6aa76 
  dataengines/share/shareservice.cpp 2529878 
  krunner/view.cpp 9d33fe5 
  ksmserver/CMakeLists.txt 84a8aa3 
  ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
  ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
  ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
  ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
  ksmserver/screenlocker/kcm/kcm.h 6741e47 
  ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
  ksmserver/shutdowndlg.cpp 1c00f19 
  ksplash/ksplashqml/CMakeLists.txt 16c58a0 
  ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
  plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
  shell/CMakeLists.txt cb48ab8 
  shell/containmentconfigview.cpp 3ec7efe 
  shell/desktopview.h ea9e555 
  shell/desktopview.cpp bbe16f2 
  shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
  shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
  shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
  shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
  shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
98faa6b 
  CMakeLists.txt d9fc33c 
  shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
  shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
  shell/packageplugins/shell/CMakeLists.txt 9b15426 
  shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
c001334 
  shell/packageplugins/shell/shellpackage.h 744e26c 
  shell/packageplugins/shell/shellpackage.cpp ad815c1 
  shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
  
shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
 6f105d9 
  shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
  shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
  shell/scripting/scriptengine.cpp ceb7afc 
  shell/shellcorona.h 3321adf 
  shell/shellcorona.cpp 187b68c 
  shell/standaloneappcorona.cpp e98499c 
  wallpapers/image/backgroundlistmodel.h 0fa0d92 
  wallpapers/image/backgroundlistmodel.cpp 0042c3c 
  wallpapers/image/image.h 4fb87d2 
  wallpapers/image/image.cpp 209ed67 

Diff: https://git.reviewboard.kde.org/r/122524/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122524: Port to KPackage and away from sycoca

[Marco Martin]

> On Feb. 11, 2015, 2:25 p.m., Sebastian Kügler wrote:
> > components/shellprivate/widgetexplorer/widgetexplorer.cpp, line 33
> > 
> >
> > Is this still needed?
> 
> Marco Martin wrote:
> right, widgetsMenuActions() is still not really ported, still have to 
> finish that

that part was completely deprecated (was used to show the alternative widget 
explorer of googlegadgets so.. kill)


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/#review75858
---


On Feb. 11, 2015, 1:44 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122524/
> ---
> 
> (Updated Feb. 11, 2015, 1:44 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this is the branch mart/KPackage.
> it ports away the various stuff (shell, krunner, screenlocker.. ) using 
> Plasma::Package to KPackage directly
> the widget explorer/alternatives is also ported away from sycoca, using the 
> new kpackage cache mechanism to query for applets
> 
> 
> Diffs
> -
> 
>   shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
>   shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
> 48a6d52 
>   shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
>   shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
>   
> shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
>  f870e0d 
>   components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
>   components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
>   components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
>   components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
>   dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
>   dataengines/share/packagestructure/share_package.h 31d0f6f 
>   dataengines/share/packagestructure/share_package.cpp bd8567e 
>   dataengines/share/shareservice.h 8f6aa76 
>   dataengines/share/shareservice.cpp 2529878 
>   krunner/view.cpp 9d33fe5 
>   ksmserver/CMakeLists.txt 84a8aa3 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
>   ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
>   ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
>   ksmserver/screenlocker/kcm/kcm.h 6741e47 
>   ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
>   ksmserver/shutdowndlg.cpp 1c00f19 
>   ksplash/ksplashqml/CMakeLists.txt 16c58a0 
>   ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
>   plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
>   shell/CMakeLists.txt cb48ab8 
>   shell/containmentconfigview.cpp 3ec7efe 
>   shell/desktopview.h ea9e555 
>   shell/desktopview.cpp bbe16f2 
>   shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
>   shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
>   shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
>   shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
>   
> shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
> 98faa6b 
>   CMakeLists.txt d9fc33c 
>   shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
>   shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
>   shell/packageplugins/shell/CMakeLists.txt 9b15426 
>   shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
> c001334 
>   shell/packageplugins/shell/shellpackage.h 744e26c 
>   shell/packageplugins/shell/shellpackage.cpp ad815c1 
>   shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
>   
> shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
>  6f105d9 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
>   shell/scripting/scriptengine.cpp ceb7afc 
>   shell/shellcorona.h 3321adf 
>   shell/shellcorona.cpp 187b68c 
>   shell/standaloneappcorona.cpp e98499c 
>   wallpapers/image/backgroundlistmodel.h 0fa0d92 
>   wallpapers/image/backgroundlistmodel.cpp 0042c3c 
>   wallpapers/image/image.h 4fb87d2 
>   wallpapers/image/image.cpp 209ed67 
> 
> Diff: https://git.reviewboard.kde.org/r/122524/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122331: Add libinput support to kcm-touchpad

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122331/#review75871
---


I tried testing the change. I added some debug into XlibBackend* 
XlibBackend::initialize(QObject *parent) to make sure it was loading the new 
backend. 

It didn't.

xprop -root wasn't showing an "libinput Tapping Enabled" atom, any idea what 
needs changing to use/test?

- David Edmundson


On Jan. 30, 2015, 7:41 p.m., Rajeesh K Nambiar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122331/
> ---
> 
> (Updated Jan. 30, 2015, 7:41 p.m.)
> 
> 
> Review request for Plasma, Alexander Mezin and Martin Gräßlin.
> 
> 
> Repository: kcm-touchpad
> 
> 
> Description
> ---
> 
> ibinput is a library to handle input devices in Wayland compositors and to 
> provide a generic X.Org input driver. Add libinput support to kcm-touchpad.
> Patch authored by Peter Hutterer.
> 
> 
> Diffs
> -
> 
>   src/kcm/touchpad.kcfg 2afe642 
>   src/kcm/ui/tap.ui 8e081ad 
>   src/touchpadbackend.cpp 93e3dc2 
>   src/backends/x11.cmake f208281 
>   src/backends/x11/libinputproperties.c PRE-CREATION 
>   src/backends/x11/synclientproperties.h 5b32b9f 
>   src/backends/x11/xlibbackend.h 3692a60 
>   src/backends/x11/xlibbackend.cpp 3b5e5be 
>   src/kcm/customconfigdialogmanager.cpp 75b03ab 
> 
> Diff: https://git.reviewboard.kde.org/r/122331/diff/
> 
> 
> Testing
> ---
> 
> Fedora 21 RPM built and tested with Plasma 5.2.
> RPMs available here for testing: 
> https://copr-be.cloud.fedoraproject.org/results/rajeeshknambiar/kf5-kde-apps/fedora-21-x86_64/kf5-kcm_touchpad-5.1.96-1.fc21/
> 
> 
> Thanks,
> 
> Rajeesh K Nambiar
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Andrew Lake]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75870
---


It might be worth investigating the use-case a bit further to try to understand 
if this is the best way to solve this. Is it useful? Yes. But there are 
potentiall negative impacts that should be balanced against the relative 
increase in utility.

We also need to belly up to identifying primary and secondary target personas 
and scenarios for Plasma (maybe a thing for the upcomign sprint). At best, I'd 
suggest that exposing the host name here would target a secondary persona and 
any associated scenarios. 

While I can't argue that the scenario in the bug report isn't legitimate, I'm 
not sure it warrants adding information to the lock-screen that is of 
little-to-no value to primary target personas and scenarios. The cost we're 
trying to mitigate in the bug report is that the user logs in/unlocks to 
identify the computer versus knowing it one interaction step earlier. 

For the lab/shared computers, the scenario requires that more than one computer 
is shared (probably in relative proximity to each other) and some particular 
need that requires knowing the computer identity *before* logging in/unlocking. 
Even in corporate environments that seems like quite a marginal scenario.

So for me, I'm struggling to see how the potentially negative impact of added 
information noise for what I think are the primary target personas and 
scenarios balances what is, I think, a marginal increase in utility for a 
marginal scenario for a secondary target persona.

Hope this helps!

- Andrew Lake


On Feb. 11, 2015, 1:59 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 1:59 p.m.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122331: Add libinput support to kcm-touchpad

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122331/#review75869
---


+1 from me.

- David Edmundson


On Jan. 30, 2015, 7:41 p.m., Rajeesh K Nambiar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122331/
> ---
> 
> (Updated Jan. 30, 2015, 7:41 p.m.)
> 
> 
> Review request for Plasma, Alexander Mezin and Martin Gräßlin.
> 
> 
> Repository: kcm-touchpad
> 
> 
> Description
> ---
> 
> ibinput is a library to handle input devices in Wayland compositors and to 
> provide a generic X.Org input driver. Add libinput support to kcm-touchpad.
> Patch authored by Peter Hutterer.
> 
> 
> Diffs
> -
> 
>   src/kcm/touchpad.kcfg 2afe642 
>   src/kcm/ui/tap.ui 8e081ad 
>   src/touchpadbackend.cpp 93e3dc2 
>   src/backends/x11.cmake f208281 
>   src/backends/x11/libinputproperties.c PRE-CREATION 
>   src/backends/x11/synclientproperties.h 5b32b9f 
>   src/backends/x11/xlibbackend.h 3692a60 
>   src/backends/x11/xlibbackend.cpp 3b5e5be 
>   src/kcm/customconfigdialogmanager.cpp 75b03ab 
> 
> Diff: https://git.reviewboard.kde.org/r/122331/diff/
> 
> 
> Testing
> ---
> 
> Fedora 21 RPM built and tested with Plasma 5.2.
> RPMs available here for testing: 
> https://copr-be.cloud.fedoraproject.org/results/rajeeshknambiar/kf5-kde-apps/fedora-21-x86_64/kf5-kcm_touchpad-5.1.96-1.fc21/
> 
> 
> Thanks,
> 
> Rajeesh K Nambiar
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122400: Add timedated support into the clock KCM as an optional dependency

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122400/
---

(Updated Feb. 11, 2015, 2:51 p.m.)


Review request for Plasma.


Changes
---

Don't do the stupid 5 second wait for ktimezoned if we're in timedated mode

Add comments in bool KclockModule::timedatedSave()


Repository: plasma-desktop


Description
---

The current time setting helper is incredibly broken.

It manually tries to run a range of NTP utilities, all of which are
deprecated.

We can just call timedated directly and cut out the middleman as it has
uses polkit anyway.

This is currently an optional dependency, and the original helper still
exists. It makes the code messy, but we have users to support for now.

Finding timedated is an cmake option rather than querying for systemd
libs to make it easier for those deploying shims, such as BSD.


(code is in two commits, first abstracting the saving from the dtime class; 
then adding in the second save mechanism) 


Diffs (updated)
-

  kcms/dateandtime/CMakeLists.txt 4a987ae 
  kcms/dateandtime/dateandtime.ui c073b5e 
  kcms/dateandtime/dtime.h 1a90698 
  kcms/dateandtime/dtime.cpp 482e483 
  kcms/dateandtime/main.h c1e5234 
  kcms/dateandtime/main.cpp 0041a9d 
  kcms/dateandtime/timedated1.xml PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/122400/diff/


Testing
---


Thanks,

David Edmundson

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122400: Add timedated support into the clock KCM as an optional dependency

[David Edmundson]

> On Feb. 10, 2015, 7:51 p.m., Xuetian Weng wrote:
> > kcms/dateandtime/main.cpp, line 146
> > 
> >
> > This part can be async.
> > 
> > You can do it by chain two different callback if it need to be done one 
> > after another. Lambda would be helpful in this case to keep code short.
> 
> David Edmundson wrote:
> I wrote on line 137 why I did this...
> but given lots of people keep commenting, but I'll change it and the 
> legacy version too
> 
> Note that on line 195 we block the entire UI for 5 seconds anyway, so 
> changing this isn't going to have any noticable impact given that problem 
> exists.
> 
> Xuetian Weng wrote:
> so also check if (m_haveTimedated) for line 195?
> 
> David Edmundson wrote:
> I didn't because we still use ktimezone in the UI for displaying... but I 
> could just fix that too.
> 
> New patch incoming.

Update: We need to block save() finishing.
Otherwise when you click OK the app will exit before the save finishes, and 
there's no sensible way to stop that.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122400/#review75801
---


On Feb. 10, 2015, 3:55 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122400/
> ---
> 
> (Updated Feb. 10, 2015, 3:55 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-desktop
> 
> 
> Description
> ---
> 
> The current time setting helper is incredibly broken.
> 
> It manually tries to run a range of NTP utilities, all of which are
> deprecated.
> 
> We can just call timedated directly and cut out the middleman as it has
> uses polkit anyway.
> 
> This is currently an optional dependency, and the original helper still
> exists. It makes the code messy, but we have users to support for now.
> 
> Finding timedated is an cmake option rather than querying for systemd
> libs to make it easier for those deploying shims, such as BSD.
> 
> 
> (code is in two commits, first abstracting the saving from the dtime class; 
> then adding in the second save mechanism) 
> 
> 
> Diffs
> -
> 
>   kcms/dateandtime/CMakeLists.txt 4a987ae 
>   kcms/dateandtime/dateandtime.ui c073b5e 
>   kcms/dateandtime/dtime.h 1a90698 
>   kcms/dateandtime/dtime.cpp 482e483 
>   kcms/dateandtime/main.h c1e5234 
>   kcms/dateandtime/main.cpp 0041a9d 
>   kcms/dateandtime/timedated1.xml PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/122400/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build is back to normal : plasma-desktop_master_qt5 #994

[KDE CI System]

See 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Jenkins build is back to normal : plasma-desktop_stable_qt5 #69

[KDE CI System]

See 

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122524: Port to KPackage and away from sycoca

[Marco Martin]

> On Feb. 11, 2015, 2:25 p.m., Sebastian Kügler wrote:
> > components/shellprivate/widgetexplorer/widgetexplorer.cpp, line 33
> > 
> >
> > Is this still needed?

right, widgetsMenuActions() is still not really ported, still have to finish 
that


> On Feb. 11, 2015, 2:25 p.m., Sebastian Kügler wrote:
> > shell/scripting/scriptengine.cpp, line 42
> > 
> >
> > This include can go away, I suppose.

there as well is still using pluginloader::listcontainmentsoftype that's fine


- Marco


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/#review75858
---


On Feb. 11, 2015, 1:44 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122524/
> ---
> 
> (Updated Feb. 11, 2015, 1:44 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this is the branch mart/KPackage.
> it ports away the various stuff (shell, krunner, screenlocker.. ) using 
> Plasma::Package to KPackage directly
> the widget explorer/alternatives is also ported away from sycoca, using the 
> new kpackage cache mechanism to query for applets
> 
> 
> Diffs
> -
> 
>   shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
>   shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
> 48a6d52 
>   shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
>   shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
>   
> shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
>  f870e0d 
>   components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
>   components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
>   components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
>   components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
>   dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
>   dataengines/share/packagestructure/share_package.h 31d0f6f 
>   dataengines/share/packagestructure/share_package.cpp bd8567e 
>   dataengines/share/shareservice.h 8f6aa76 
>   dataengines/share/shareservice.cpp 2529878 
>   krunner/view.cpp 9d33fe5 
>   ksmserver/CMakeLists.txt 84a8aa3 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
>   ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
>   ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
>   ksmserver/screenlocker/kcm/kcm.h 6741e47 
>   ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
>   ksmserver/shutdowndlg.cpp 1c00f19 
>   ksplash/ksplashqml/CMakeLists.txt 16c58a0 
>   ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
>   plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
>   shell/CMakeLists.txt cb48ab8 
>   shell/containmentconfigview.cpp 3ec7efe 
>   shell/desktopview.h ea9e555 
>   shell/desktopview.cpp bbe16f2 
>   shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
>   shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
>   shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
>   shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
>   
> shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
> 98faa6b 
>   CMakeLists.txt d9fc33c 
>   shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
>   shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
>   shell/packageplugins/shell/CMakeLists.txt 9b15426 
>   shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
> c001334 
>   shell/packageplugins/shell/shellpackage.h 744e26c 
>   shell/packageplugins/shell/shellpackage.cpp ad815c1 
>   shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
>   
> shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
>  6f105d9 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
>   shell/scripting/scriptengine.cpp ceb7afc 
>   shell/shellcorona.h 3321adf 
>   shell/shellcorona.cpp 187b68c 
>   shell/standaloneappcorona.cpp e98499c 
>   wallpapers/image/backgroundlistmodel.h 0fa0d92 
>   wallpapers/image/backgroundlistmodel.cpp 0042c3c 
>   wallpapers/image/image.h 4fb87d2 
>   wallpapers/image/image.cpp 209ed67 
> 
> Diff: https://git.reviewboard.kde.org/r/122524/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-deve

Build failed in Jenkins: plasma-desktop_master_qt5 #993

[KDE CI System]

See 

Changes:

[jr] add subdirectories optionally for documentation because translations may 
be incomplete

--
[...truncated 37 lines...]
KDE Continuous Integration Build
== Building Project: plasma-desktop - Branch master
== Build Dependencies:
 kdesignerplugin - Branch master
 breeze - Branch master
 kdoctools - Branch master
 plasma-workspace - Branch master
 kservice - Branch master
 kwallet - Branch master
 kguiaddons - Branch master
 ktexteditor - Branch master
 kwayland - Branch master
 kio - Branch master
 kinit - Branch master
 kemoticons - Branch master
 kwidgetsaddons - Branch master
 attica - Branch master
 sonnet - Branch master
 libksysguard - Branch master
 kunitconversion - Branch master
 ktextwidgets - Branch master
 kded - Branch master
 kjsembed - Branch master
 ki18n - Branch master
 kpty - Branch master
 kcompletion - Branch master
 knotifications - Branch master
 kwindowsystem - Branch master
 khtml - Branch master
 kdecoration - Branch master
 knotifyconfig - Branch master
 threadweaver - Branch master
 qt5 - Branch 5.4.1
 kauth - Branch master
 frameworkintegration - Branch master
 kplotting - Branch master
 kconfig - Branch master
 kwin - Branch master
 kactivities - Branch master
 kdelibs4support - Branch master
 kidletime - Branch master
 cmake - Branch master
 kitemmodels - Branch master
 systemsettings - Branch master
 phonon - Branch master
 kbookmarks - Branch master
 kpackage - Branch master
 kcoreaddons - Branch master
 poppler - Branch master
 kcmutils - Branch master
 kitemviews - Branch master
 kconfigwidgets - Branch master
 milou - Branch master
 baloo - Branch master
 kparts - Branch master
 khelpcenter - Branch master
 kcrash - Branch master
 oxygen - Branch master
 kross - Branch master
 kiconthemes - Branch master
 libdbusmenu-qt - Branch master
 kdeclarative - Branch master
 libgit2 - Branch master
 extra-cmake-modules - Branch master
 kdbusaddons - Branch master
 polkit-qt-1 - Branch master
 kio-extras - Branch master
 powerdevil - Branch master
 kfilemetadata - Branch master
 kxmlgui - Branch master
 plasma-framework - Branch master
 knewstuff - Branch master
 krunner - Branch master
 kjobwidgets - Branch master
 kcodecs - Branch master
 kglobalaccel - Branch master
 kdewebkit - Branch master
 ksysguard - Branch master
 kjs - Branch master
 kdesupport-svn - Branch master
 dogtail - Branch master
 kde-cli-tools - Branch master
 libssh - Branch master
 kdnssd - Branch master
 karchive - Branch master
 libkscreen - Branch master
 solid - Branch master
 kdesu - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found KF5Auth: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kauth/inst/lib64/cmake/KF5Auth/KF5AuthConfig.cmake
 (found version "5.7.0") 
-- Found KF5Plasma: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/plasma-framework/inst/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake
 (found version "5.7.0") 
-- Found KF5PlasmaQuick: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/plasma-framework/inst/lib64/cmake/KF5PlasmaQuick/KF5PlasmaQuickConfig.cmake
 (found version "5.7.0") 
-- Found KF5DocTools: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdoctools/inst/lib64/cmake/KF5DocTools/KF5DocToolsConfig.cmake
 (found version "5.7.0") 
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.3") 
-- Found KF5I18n: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/ki18n/inst/lib64/cmake/KF5I18n/KF5I18nConfig.cmake
 (found version "5.7.0") 
-- Found KF5KCMUtils: 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kcmutils/inst/lib64/cmake/KF5KCMUtils/KF5KCMUtilsConfig.cmake
 (found version

Review Request 122528: [screenlocker] Grab XServer while establishing the grab

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122528/
---

Review request for Plasma.


Repository: plasma-workspace


Description
---

By grabbing the XServer we can ensure that no other client is
sending X events. This eliminates a possible timing attack in
the time frame between grabbing keyboard and pointer.

At the same time the waiting and try again becomes useless as the
XServer is grabbed and no other client could release the hold
input device grab.


Diffs
-

  ksmserver/screenlocker/ksldapp.cpp e23b50fbcaac659bb6ef1b36a4de6efc63573978 

Diff: https://git.reviewboard.kde.org/r/122528/diff/


Testing
---


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Build failed in Jenkins: plasma-desktop_stable_qt5 #68

[KDE CI System]

See 

Changes:

[jr] add subdirectories optionally for documentation because translations may 
be incomplete

--
[...truncated 36 lines...]

KDE Continuous Integration Build
== Building Project: plasma-desktop - Branch Plasma/5.2
== Build Dependencies:
 khelpcenter - Branch Plasma/5.2
 attica - Branch master
 kparts - Branch master
 karchive - Branch master
 ktextwidgets - Branch master
 libksysguard - Branch Plasma/5.2
 kjobwidgets - Branch master
 threadweaver - Branch master
 frameworkintegration - Branch master
 knotifications - Branch master
 libgit2 - Branch master
 kdewebkit - Branch master
 kcoreaddons - Branch master
 kwallet - Branch master
 khtml - Branch master
 kpty - Branch master
 kwidgetsaddons - Branch master
 kjs - Branch master
 kauth - Branch master
 kpackage - Branch master
 libdbusmenu-qt - Branch master
 kdnssd - Branch master
 systemsettings - Branch Plasma/5.2
 kdesignerplugin - Branch master
 kbookmarks - Branch master
 kconfigwidgets - Branch master
 sonnet - Branch master
 kemoticons - Branch master
 milou - Branch Plasma/5.2
 cmake - Branch master
 kguiaddons - Branch master
 kcompletion - Branch master
 kidletime - Branch master
 kde-cli-tools - Branch Plasma/5.2
 kiconthemes - Branch master
 kitemviews - Branch master
 libssh - Branch master
 knotifyconfig - Branch master
 kplotting - Branch master
 extra-cmake-modules - Branch master
 breeze - Branch Plasma/5.2
 kdbusaddons - Branch master
 kjsembed - Branch master
 kdeclarative - Branch master
 kitemmodels - Branch master
 krunner - Branch master
 polkit-qt-1 - Branch master
 kdecoration - Branch Plasma/5.2
 powerdevil - Branch Plasma/5.2
 kactivities - Branch master
 kdelibs4support - Branch master
 ki18n - Branch master
 kwindowsystem - Branch master
 phonon - Branch master
 plasma-framework - Branch master
 kservice - Branch master
 qt5 - Branch 5.3.2
 kross - Branch master
 kcrash - Branch master
 kio - Branch master
 ksysguard - Branch Plasma/5.2
 kwin - Branch Plasma/5.2
 kded - Branch master
 kcmutils - Branch master
 kconfig - Branch master
 plasma-workspace - Branch Plasma/5.2
 kunitconversion - Branch master
 oxygen - Branch Plasma/5.2
 kdesu - Branch master
 knewstuff - Branch master
 kxmlgui - Branch master
 kfilemetadata - Branch Plasma/5.2
 libkscreen - Branch Plasma/5.2
 kwayland - Branch Plasma/5.2
 kdoctools - Branch master
 kio-extras - Branch Plasma/5.2
 kinit - Branch master
 dogtail - Branch master
 kglobalaccel - Branch master
 ktexteditor - Branch master
 baloo - Branch Plasma/5.2
 kdesupport-svn - Branch master
 kcodecs - Branch master
 solid - Branch master

== Applying Patches
=== No patches to apply

== Syncing Dependencies from Master Server


== Configuring Build

-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/jenkins/bin/cc
-- Check for working C compiler: /home/jenkins/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /home/jenkins/bin/c++
-- Check for working CXX compiler: /home/jenkins/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Found KF5Auth: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/kauth/inst/lib64/cmake/KF5Auth/KF5AuthConfig.cmake
 (found version "5.7.0") 
-- Found KF5Plasma: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/plasma-framework/inst/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake
 (found version "5.7.0") 
-- Found KF5PlasmaQuick: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/plasma-framework/inst/lib64/cmake/KF5PlasmaQuick/KF5PlasmaQuickConfig.cmake
 (found version "5.7.0") 
-- Found KF5DocTools: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/kdoctools/inst/lib64/cmake/KF5DocTools/KF5DocToolsConfig.cmake
 (found version "5.7.0") 
-- Found Gettext: /usr/bin/msgmerge (found version "0.18.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.3") 
-- Found KF5I18n: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/frameworks/ki18n/inst/lib64/cmake/KF5I18n/KF5I18nConfig.cmake
 (found version "5.7.0") 
-- Found KF5KCMUtils: 
/srv/jenkins/install/linux/x86_64/g++/stable-kf5-qt5/fra

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Sebastian Kügler]

> On Feb. 11, 2015, 1:43 p.m., Sebastian Kügler wrote:
> > What's the use case this satisfies?
> 
> Aleix Pol Gonzalez wrote:
> See the attached bug report.
> 
> Martin Gräßlin wrote:
> This used to be present IIRC in the old xscreensaver based greeter.
> 
> The use case is simple: e.g. distinguishing a system in a computer lab.
> 
> Aleix Pol Gonzalez wrote:
> Would it make sense to suggest them to use a different L&F theme over 
> there?
> 
> Martin Gräßlin wrote:
> > Would it make sense to suggest them to use a different L&F theme over 
> there?
> 
> no, clearly not. We do not even have the infrastructure to distribute L&F 
> packages and I think we should have a default which is usable for companies.

Ok, seems a valid use case to me. I'm OK with it going in, if Andrew finds it 
OK as well.


- Sebastian


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


On Feb. 11, 2015, 1:59 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 1:59 p.m.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122524: Port to KPackage and away from sycoca

[Sebastian Kügler]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/#review75858
---

Ship it!


A few const issues, and one possible crasher. Otherwise, it's good to go in IMO.


components/shellprivate/widgetexplorer/widgetexplorer.cpp


Is this still needed?



components/shellprivate/widgetexplorer/widgetexplorer.cpp


const?



components/shellprivate/widgetexplorer/widgetexplorer.cpp


const?



shell/scripting/scriptengine.cpp


This include can go away, I suppose.



wallpapers/image/backgroundlistmodel.cpp


This could explode. KPluginMetaData::isValid() doesn't check if there's at 
least one author.


A few sma

- Sebastian Kügler


On Feb. 11, 2015, 1:44 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122524/
> ---
> 
> (Updated Feb. 11, 2015, 1:44 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this is the branch mart/KPackage.
> it ports away the various stuff (shell, krunner, screenlocker.. ) using 
> Plasma::Package to KPackage directly
> the widget explorer/alternatives is also ported away from sycoca, using the 
> new kpackage cache mechanism to query for applets
> 
> 
> Diffs
> -
> 
>   shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
>   shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
> 48a6d52 
>   shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
>   shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
>   
> shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
>  f870e0d 
>   components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
>   components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
>   components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
>   components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
>   dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
>   dataengines/share/packagestructure/share_package.h 31d0f6f 
>   dataengines/share/packagestructure/share_package.cpp bd8567e 
>   dataengines/share/shareservice.h 8f6aa76 
>   dataengines/share/shareservice.cpp 2529878 
>   krunner/view.cpp 9d33fe5 
>   ksmserver/CMakeLists.txt 84a8aa3 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
>   ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
>   ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
>   ksmserver/screenlocker/kcm/kcm.h 6741e47 
>   ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
>   ksmserver/shutdowndlg.cpp 1c00f19 
>   ksplash/ksplashqml/CMakeLists.txt 16c58a0 
>   ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
>   plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
>   shell/CMakeLists.txt cb48ab8 
>   shell/containmentconfigview.cpp 3ec7efe 
>   shell/desktopview.h ea9e555 
>   shell/desktopview.cpp bbe16f2 
>   shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
>   shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
>   shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
>   shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
>   
> shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
> 98faa6b 
>   CMakeLists.txt d9fc33c 
>   shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
>   shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
>   shell/packageplugins/shell/CMakeLists.txt 9b15426 
>   shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
> c001334 
>   shell/packageplugins/shell/shellpackage.h 744e26c 
>   shell/packageplugins/shell/shellpackage.cpp ad815c1 
>   shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
>   
> shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
>  6f105d9 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
>   shell/scripting/scriptengine.cpp ceb7afc 
>   shell/shellcorona.h 3321adf 
>   shell/shellcorona.cpp 187b68c 
>   shell/standaloneappcorona.cpp e98499c 
>   wallpapers/image/backgroundlistmodel.h 0fa0d92 
>   wallpapers/image/backgroundlistmodel.cpp 0042c3c 
>   wallpapers/image/image.h 4fb87d2 
>   wallpapers/image/image.cpp 209ed67 
> 
> Diff: https://git.reviewboard.kde.org/r/122524/diff/
> 

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Martin Gräßlin]

> On Feb. 11, 2015, 2:43 nachm., Sebastian Kügler wrote:
> > What's the use case this satisfies?
> 
> Aleix Pol Gonzalez wrote:
> See the attached bug report.
> 
> Martin Gräßlin wrote:
> This used to be present IIRC in the old xscreensaver based greeter.
> 
> The use case is simple: e.g. distinguishing a system in a computer lab.
> 
> Aleix Pol Gonzalez wrote:
> Would it make sense to suggest them to use a different L&F theme over 
> there?

> Would it make sense to suggest them to use a different L&F theme over there?

no, clearly not. We do not even have the infrastructure to distribute L&F 
packages and I think we should have a default which is usable for companies.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


On Feb. 11, 2015, 2:59 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:59 nachm.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122524: Port to KPackage and away from sycoca

[Bhushan Shah]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/#review75856
---


Two things broken,

- no wallpaper plugin listing
- can not switch containment

- Bhushan Shah


On Feb. 11, 2015, 7:14 p.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122524/
> ---
> 
> (Updated Feb. 11, 2015, 7:14 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> this is the branch mart/KPackage.
> it ports away the various stuff (shell, krunner, screenlocker.. ) using 
> Plasma::Package to KPackage directly
> the widget explorer/alternatives is also ported away from sycoca, using the 
> new kpackage cache mechanism to query for applets
> 
> 
> Diffs
> -
> 
>   shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
>   shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
> 48a6d52 
>   shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
>   shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
>   
> shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
>  f870e0d 
>   components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
>   components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
>   components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
>   components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
>   dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
>   dataengines/share/packagestructure/share_package.h 31d0f6f 
>   dataengines/share/packagestructure/share_package.cpp bd8567e 
>   dataengines/share/shareservice.h 8f6aa76 
>   dataengines/share/shareservice.cpp 2529878 
>   krunner/view.cpp 9d33fe5 
>   ksmserver/CMakeLists.txt 84a8aa3 
>   ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
>   ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
>   ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
>   ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
>   ksmserver/screenlocker/kcm/kcm.h 6741e47 
>   ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
>   ksmserver/shutdowndlg.cpp 1c00f19 
>   ksplash/ksplashqml/CMakeLists.txt 16c58a0 
>   ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
>   plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
>   shell/CMakeLists.txt cb48ab8 
>   shell/containmentconfigview.cpp 3ec7efe 
>   shell/desktopview.h ea9e555 
>   shell/desktopview.cpp bbe16f2 
>   shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
>   shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
>   shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
>   shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
>   
> shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
> 98faa6b 
>   CMakeLists.txt d9fc33c 
>   shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
>   shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
>   shell/packageplugins/shell/CMakeLists.txt 9b15426 
>   shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
> c001334 
>   shell/packageplugins/shell/shellpackage.h 744e26c 
>   shell/packageplugins/shell/shellpackage.cpp ad815c1 
>   shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
>   
> shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
>  6f105d9 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
>   shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
>   shell/scripting/scriptengine.cpp ceb7afc 
>   shell/shellcorona.h 3321adf 
>   shell/shellcorona.cpp 187b68c 
>   shell/standaloneappcorona.cpp e98499c 
>   wallpapers/image/backgroundlistmodel.h 0fa0d92 
>   wallpapers/image/backgroundlistmodel.cpp 0042c3c 
>   wallpapers/image/image.h 4fb87d2 
>   wallpapers/image/image.cpp 209ed67 
> 
> Diff: https://git.reviewboard.kde.org/r/122524/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Aleix Pol Gonzalez]

> On Feb. 11, 2015, 2:43 p.m., Sebastian Kügler wrote:
> > What's the use case this satisfies?
> 
> Aleix Pol Gonzalez wrote:
> See the attached bug report.
> 
> Martin Gräßlin wrote:
> This used to be present IIRC in the old xscreensaver based greeter.
> 
> The use case is simple: e.g. distinguishing a system in a computer lab.

Would it make sense to suggest them to use a different L&F theme over there?


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


On Feb. 11, 2015, 2:59 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:59 p.m.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Martin Gräßlin]

> On Feb. 11, 2015, 2:43 nachm., Sebastian Kügler wrote:
> > What's the use case this satisfies?
> 
> Aleix Pol Gonzalez wrote:
> See the attached bug report.

This used to be present IIRC in the old xscreensaver based greeter.

The use case is simple: e.g. distinguishing a system in a computer lab.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


On Feb. 11, 2015, 2:59 nachm., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:59 nachm.)
> 
> 
> Review request for Plasma and Andrew Lake.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/
---

(Updated Feb. 11, 2015, 2:59 nachm.)


Review request for Plasma and Andrew Lake.


Changes
---

Adding Andrew for feedback


Bugs: 294778
https://bugs.kde.org/show_bug.cgi?id=294778


Repository: plasma-workspace


Description
---

FEATURE: 294778
FIXED-IN: 5.3.0


Diffs
-

  lookandfeel/contents/components/InfoPane.qml 
18739ad96724f520ce8467ba5d4c9595e8a9e9ed 

Diff: https://git.reviewboard.kde.org/r/122522/diff/


Testing
---


File Attachments


Screenshot of LockScreen with new info
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Change in plasma-framework[master]: Port to kpackage::package

[David Edmundson (Code Review)]

David Edmundson has uploaded a new change for review.

  https://gerrit.vesnicky.cesnet.cz/r/367

Change subject: Port to kpackage::package
..

Port to kpackage::package

Change-Id: Id52b8d6bf76ab964c02cec9f0bba1dcdf3950d76
---
M src/plasma/svg.cpp
1 file changed, 2 insertions(+), 2 deletions(-)


  git pull ssh://gerrit.vesnicky.cesnet.cz:29418/plasma-framework 
refs/changes/67/367/1

diff --git a/src/plasma/svg.cpp b/src/plasma/svg.cpp
index 28393e5..0a0db5e 100644
--- a/src/plasma/svg.cpp
+++ b/src/plasma/svg.cpp
@@ -409,8 +409,8 @@
 //FIXME: this maybe could be more efficient if we knew if the package 
was empty, e.g. for
 //C++; however, I'm not sure this has any real world runtime impact. 
something to measure
 //for.
-if (applet && applet->package().isValid()) {
-const Package package = applet->package();
+if (applet && applet->kPackage().isValid()) {
+const KPackage::Package package = applet->kPackage();
 path = package.filePath("images", themePath + ".svg");
 
 if (path.isEmpty()) {

-- 
To view, visit https://gerrit.vesnicky.cesnet.cz/r/367
To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id52b8d6bf76ab964c02cec9f0bba1dcdf3950d76
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: David Edmundson 
Gerrit-Reviewer: Aaron J. Seigo 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Aleix Pol Gonzalez]

> On Feb. 11, 2015, 2:43 p.m., Sebastian Kügler wrote:
> > What's the use case this satisfies?

See the attached bug report.


- Aleix


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


On Feb. 11, 2015, 2:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:05 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Change in plasma-framework[master]: Fix leak in ContainmentActions

[David Edmundson (Code Review)]

David Edmundson has uploaded a new change for review.

  https://gerrit.vesnicky.cesnet.cz/r/366

Change subject: Fix leak in ContainmentActions
..

Fix leak in ContainmentActions

Change-Id: I41c9b9c224b36b045034755b07a92f2bdfe9f40e
---
M src/plasma/containmentactions.cpp
1 file changed, 2 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.vesnicky.cesnet.cz:29418/plasma-framework 
refs/changes/66/366/1

diff --git a/src/plasma/containmentactions.cpp 
b/src/plasma/containmentactions.cpp
index 3abb7fe..f24bdac 100644
--- a/src/plasma/containmentactions.cpp
+++ b/src/plasma/containmentactions.cpp
@@ -50,6 +50,8 @@
 : d(new 
ContainmentActionsPrivate(KService::serviceByStorageId(args.count() > 0 ?
   args[0].toString() : QString()), this))
 {
+setParent(parentObject);
+
 // now remove first item since those are managed by Wallpaper and 
subclasses shouldn't
 // need to worry about them. yes, it violates the constness of this var, 
but it lets us add
 // or remove items later while applets can just pretend that their args 
always start at 0

-- 
To view, visit https://gerrit.vesnicky.cesnet.cz/r/366
To unsubscribe, visit https://gerrit.vesnicky.cesnet.cz/r/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I41c9b9c224b36b045034755b07a92f2bdfe9f40e
Gerrit-PatchSet: 1
Gerrit-Project: plasma-framework
Gerrit-Branch: master
Gerrit-Owner: David Edmundson 
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 122524: Port to KPackage and away from sycoca

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122524/
---

Review request for Plasma.


Repository: plasma-workspace


Description
---

this is the branch mart/KPackage.
it ports away the various stuff (shell, krunner, screenlocker.. ) using 
Plasma::Package to KPackage directly
the widget explorer/alternatives is also ported away from sycoca, using the new 
kpackage cache mechanism to query for applets


Diffs
-

  shell/packageplugins/qmlWallpaper/CMakeLists.txt cc6ece1 
  shell/packageplugins/qmlWallpaper/plasma-packagestructure-wallpaper.desktop 
48a6d52 
  shell/packageplugins/layouttemplate/layouttemplate.h a8a1f52 
  shell/packageplugins/layouttemplate/layouttemplate.cpp 50beeb2 
  
shell/packageplugins/layouttemplate/plasma-packagestructure-layouttemplate.desktop
 f870e0d 
  components/shellprivate/interactiveconsole/interactiveconsole.cpp 662e3de 
  components/shellprivate/widgetexplorer/openwidgetassistant.cpp ed1d0e3 
  components/shellprivate/widgetexplorer/plasmaappletitemmodel.cpp 42422d1 
  components/shellprivate/widgetexplorer/widgetexplorer.cpp a739a17 
  dataengines/share/packagestructure/CMakeLists.txt 9a8a8dd 
  dataengines/share/packagestructure/share_package.h 31d0f6f 
  dataengines/share/packagestructure/share_package.cpp bd8567e 
  dataengines/share/shareservice.h 8f6aa76 
  dataengines/share/shareservice.cpp 2529878 
  krunner/view.cpp 9d33fe5 
  ksmserver/CMakeLists.txt 84a8aa3 
  ksmserver/screenlocker/greeter/CMakeLists.txt 14a34f0 
  ksmserver/screenlocker/greeter/greeterapp.h 4a90faf 
  ksmserver/screenlocker/greeter/greeterapp.cpp 824ba60 
  ksmserver/screenlocker/kcm/CMakeLists.txt 41e04c9 
  ksmserver/screenlocker/kcm/kcm.h 6741e47 
  ksmserver/screenlocker/kcm/kcm.cpp 28f5e35 
  ksmserver/shutdowndlg.cpp 1c00f19 
  ksplash/ksplashqml/CMakeLists.txt 16c58a0 
  ksplash/ksplashqml/SplashWindow.cpp 807dc9b 
  plasma-windowed/plasmawindowedcorona.cpp 8096f9c 
  shell/CMakeLists.txt cb48ab8 
  shell/containmentconfigview.cpp 3ec7efe 
  shell/desktopview.h ea9e555 
  shell/desktopview.cpp bbe16f2 
  shell/packageplugins/layouttemplate/CMakeLists.txt ba85efb 
  shell/packageplugins/lookandfeel/CMakeLists.txt 68ff00f 
  shell/packageplugins/lookandfeel/lookandfeel.h e1c5605 
  shell/packageplugins/lookandfeel/lookandfeel.cpp 0f7d6d0 
  shell/packageplugins/lookandfeel/plasma-packagestructure-lookandfeel.desktop 
98faa6b 
  CMakeLists.txt d9fc33c 
  shell/packageplugins/qmlWallpaper/wallpaper.h f3cd5d6 
  shell/packageplugins/qmlWallpaper/wallpaper.cpp 4aa8c2a 
  shell/packageplugins/shell/CMakeLists.txt 9b15426 
  shell/packageplugins/shell/plasma-packagestructure-plasma-shell.desktop 
c001334 
  shell/packageplugins/shell/shellpackage.h 744e26c 
  shell/packageplugins/shell/shellpackage.cpp ad815c1 
  shell/packageplugins/wallpaperimages/CMakeLists.txt 9acafc8 
  
shell/packageplugins/wallpaperimages/plasma-packagestructure-wallpaperimages.desktop
 6f105d9 
  shell/packageplugins/wallpaperimages/wallpaperpackage.h 541e1f7 
  shell/packageplugins/wallpaperimages/wallpaperpackage.cpp 9231bce 
  shell/scripting/scriptengine.cpp ceb7afc 
  shell/shellcorona.h 3321adf 
  shell/shellcorona.cpp 187b68c 
  shell/standaloneappcorona.cpp e98499c 
  wallpapers/image/backgroundlistmodel.h 0fa0d92 
  wallpapers/image/backgroundlistmodel.cpp 0042c3c 
  wallpapers/image/image.h 4fb87d2 
  wallpapers/image/image.cpp 209ed67 

Diff: https://git.reviewboard.kde.org/r/122524/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Sebastian Kügler]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75849
---


What's the use case this satisfies?

- Sebastian Kügler


On Feb. 11, 2015, 1:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 1:05 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Aleix Pol Gonzalez]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75848
---


-2

This is not part of the original design. At least, this should be discussed 
with Andrew Lake.

Please, let's not add things only because a bug report says so or someone on 
the Internet wants it.

- Aleix Pol Gonzalez


On Feb. 11, 2015, 2:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 2:05 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/#review75846
---

Ship it!


Ship It!

- David Edmundson


On Feb. 11, 2015, 1:05 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122522/
> ---
> 
> (Updated Feb. 11, 2015, 1:05 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Bugs: 294778
> https://bugs.kde.org/show_bug.cgi?id=294778
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> FEATURE: 294778
> FIXED-IN: 5.3.0
> 
> 
> Diffs
> -
> 
>   lookandfeel/contents/components/InfoPane.qml 
> 18739ad96724f520ce8467ba5d4c9595e8a9e9ed 
> 
> Diff: https://git.reviewboard.kde.org/r/122522/diff/
> 
> 
> Testing
> ---
> 
> 
> File Attachments
> 
> 
> Screenshot of LockScreen with new info
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request 122522: [lookandfeel] Include hostname in InfoPane of LockScreen

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122522/
---

Review request for Plasma.


Bugs: 294778
https://bugs.kde.org/show_bug.cgi?id=294778


Repository: plasma-workspace


Description
---

FEATURE: 294778
FIXED-IN: 5.3.0


Diffs
-

  lookandfeel/contents/components/InfoPane.qml 
18739ad96724f520ce8467ba5d4c9595e8a9e9ed 

Diff: https://git.reviewboard.kde.org/r/122522/diff/


Testing
---


File Attachments


Screenshot of LockScreen with new info
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png


Thanks,

Martin Gräßlin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.
> 
> Emmanuel Pescosta wrote:
> 0% means backlight off on this notebook, but the user interface doesn't 
> allow to turn it off on Windows (maybe they check if a screen off/on key is 
> available?)
> When I test it with Powerdevil, then the screen turns off when I drag the 
> slider to 0%.
> 
> So there is a difference between 0% on the UI and 0% on the hardware side 
> on Windows.
> 
> Heiko Tietze wrote:
> I'd like to suppport Thomas position be mentioning Android's behaviour: 
> you switch off the backlight by hardware key but adjust the setting 
> differently per slider. Two use cases, two ways of interaction.
> 
> If we only could discuss all settings in such a depth... ;-)

I really don't think you can compare laptops and (touch)phones. That's apples 
(but not only;) and oranges.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mo

Re: Review Request 122505: Warn about brightness getting too low

[Heiko Tietze]

> On Feb. 10, 2015, 11:50 nachm., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.
> 
> Emmanuel Pescosta wrote:
> 0% means backlight off on this notebook, but the user interface doesn't 
> allow to turn it off on Windows (maybe they check if a screen off/on key is 
> available?)
> When I test it with Powerdevil, then the screen turns off when I drag the 
> slider to 0%.
> 
> So there is a difference between 0% on the UI and 0% on the hardware side 
> on Windows.

I'd like to suppport Thomas position be mentioning Android's behaviour: you 
switch off the backlight by hardware key but adjust the setting differently per 
slider. Two use cases, two ways of interaction.

If we only could discuss all settings in such a depth... ;-)


- Heiko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 10:25 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 10:25 nachm.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot 

Re: Review Request 122505: Warn about brightness getting too low

[Emmanuel Pescosta]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)
> 
> Martin Klapetek wrote:
> Yes, which matches what I said above about Windows. Some drivers on Linux 
> also don't turn backlight off when you set 0%.

0% means backlight off on this notebook, but the user interface doesn't allow 
to turn it off on Windows (maybe they check if a screen off/on key is 
available?)
When I test it with Powerdevil, then the screen turns off when I drag the 
slider to 0%.

So there is a difference between 0% on the UI and 0% on the hardware side on 
Windows.


- Emmanuel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

_

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.
> 
> Emmanuel Pescosta wrote:
> Just tested it on Windows: Turning off the screen by only using the 
> brightness slider or the brightness buttons doesn't work, the dedicated 
> screen on/off button is the only way to turn it off (http://goo.gl/3CLDGP 
> Fn+F6)

Yes, which matches what I said above about Windows. Some drivers on Linux also 
don't turn backlight off when you set 0%.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Emmanuel Pescosta]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.
> 
> Martin Klapetek wrote:
> Oh now I can speak for Windows :) --> 
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
>  --> "Brightness levels are represented as single-byte values in the range 
> from zero to 100 where zero is off and 100 is the maximum brightness that a 
> laptop computer supports [...] however, a laptop computer is not required to 
> support a level of zero.". So it's fully hardware/driver dependent, just like 
> it is on Linux.

Just tested it on Windows: Turning off the screen by only using the brightness 
slider or the brightness buttons doesn't work, the dedicated screen on/off 
button is the only way to turn it off (http://goo.gl/3CLDGP Fn+F6)


- Emmanuel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Emmanuel Pescosta]

> On Feb. 10, 2015, 10:01 a.m., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)
> 
> Martin Klapetek wrote:
> In my opinion, adding (yet another) option just complicates things more.
> 
> > same as on most other operating systems (0% != screen off).
> 
> I can't speak for Windows, but my OS X definitely turns screen off when 
> you go to 0%.

Oh now I can speak for Windows :) --> 
https://msdn.microsoft.com/en-us/library/windows/hardware/ff569755%28v=vs.85%29.aspx
 --> "Brightness levels are represented as single-byte values in the range from 
zero to 100 where zero is off and 100 is the maximum brightness that a laptop 
computer supports [...] however, a laptop computer is not required to support a 
level of zero.". So it's fully hardware/driver dependent, just like it is on 
Linux.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 10, 2015, 10:01 a.m., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the

Re: Review Request 122505: Warn about brightness getting too low

[Martin Klapetek]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.
> 
> Emmanuel Pescosta wrote:
> What about adding an option to "Adcanced Power Management Settings" that 
> allows the user to change between safe/full screen brightness range (default: 
> safe, minimum is 5% of the hw range)?
> 
> [x] Use the full screen brightness range provided by your hardware 
> (Warning: 0% may turn your screen off)
> 
> So the warning in the widget can be avoided and the default behavior is 
> the same as on most other operating systems (0% != screen off).
> 
> My 2 cents ;)

In my opinion, adding (yet another) option just complicates things more.

> same as on most other operating systems (0% != screen off).

I can't speak for Windows, but my OS X definitely turns screen off when you go 
to 0%.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Emmanuel Pescosta]

> On Feb. 10, 2015, 10:01 a.m., Mark Gaiser wrote:
> > I'm not quite sure if a user wants to see a warning message at all.
> > When i use my notebook in a dark environment i usually put the brightness 
> > all the way down (depending on the notebook).
> 
> Kai Uwe Broulik wrote:
> As I stated above, "all the way down" can mean "completely off", which I 
> wouldn't expect as a user. I've never seen any other device that does that, 
> apart from some black and white seven-segment display calculators.
> 
> Mark Gaiser wrote:
> Then it's device specific even!
> - My notebook: all the way down = still visible
> - My macbook: all the way down = off
> 
> Can you detect that?
> 
> You message does make sense if the lowest step = off. It doesn't if the 
> lowest step is still on.
> 
> Martin Klapetek wrote:
> Note that this is only for when you are dragging it by mouse - if you 
> drag it all the way down and your screen goes black, there's no way to 
> recover if your keys don't work. If your keys work and stuff, you probably 
> never use the slider, so this for a minority of users. It's the same reason 
> we ask confirmation when deleting a file.
> 
> Thomas Pfeiffer wrote:
> Wait wait wait wait... Could it be that we've come up with an overly 
> complex solution to a rather simple problem?
> Actually, those devices which turn the backlight off at 0% brightness are 
> the only ones doing it _right_. I always found it very weird when my screen 
> brightness OSD said "0%" but I could still see things. 0% brightness means 
> zero brightness means _dark_.
> So why should the user even be able to set the brightness to 0% anyway?
> Since turning off the backlight without turning off the screen doesn't 
> make sense practically, there just should be no way for the user to set the 
> brightness to 0%, period.
> So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> That solves two problems: Accidentally setting to zero _and_ that 
> semantic bullshit of "0% brightness but I can still see stuff".
> 
> Martin Klapetek wrote:
> > So why should the user even be able to set the brightness to 0% anyway?
> 
> To save battery time when the screen is not needed *right now*, perhaps? 
> I quite often compile things on my laptop when on battery, this can take up 
> to 5 minutes and it's already quite a battery drainer, why the screen 
> backlight should help it when it's not needed? I listen to music while 
> cooking, screen backlight not needed. Etc etc.
> 
> > So let the slider start at 1% and don't allow the brightness to go zero 
> neither via power management nor via brightness keys.
> 
> I disagree there. It's a hardware design after all, there's no reason the 
> software couldn't/shouldn't take advantage of that. Also setting it to 1% 
> does not really make a difference (not on my laptop at least), it's so dark 
> it's useless, so I'd have to be higher, like 5% or 10%, which is...weird, I 
> think.
> 
> Mark Gaiser wrote:
> Quote: "So let the slider start at 1% and don't allow the brightness to 
> go zero neither via power management nor via brightness keys."
> 
> Please, no! I don't really care if 0% is a hardware flaw or design. We 
> apparently are stuck with the fact that we have hardware behaving 
> differently. The software should not limit prevent me to use my hardware at 
> it's full capacity. If 0% in my case is still visible then so be it and that 
> should be allowed just fine. If you forbid this then i expect quite some bug 
> reports for that will flow in.
> 
> If you want 0% to be off then you should buy hardware that obeys that.
> 
> Thomas Pfeiffer wrote:
> > To save battery time when the screen is not needed right now, perhaps?
> 
> Turning the screen off when it's not in use is a perfectly useful thing 
> to do, but that is _not_ what a brightness slider is for. The brightness 
> slider is there to allow users to set the optimum brightness for their 
> current surroundings.
> Check out your mobile phone or tablet. Regardless of which OS it runs, I 
> am very confident that pushing the slider all the way to the left will _not_ 
> turn off the backlight.
> 
> With a sensible power setting, the screen will turn off after some idle 
> period when on battery anyway. If we want to allow the user to turn it off 
> manually, there should be a keyboard shortcut for it. It _must not_ be a 
> button in the GUI, because then there would be now way to turn it on again 
> because you could not see it.
> 
> Turning off the screen via brightness slider doesn't only have the 
> problem this patch is supposed to solve, but also the disadvantage that you 
> have to find your optimal brightness setting again afterwards. If the screen 
> is turned off by a shortcut or via power management, it should return to the

Re: Get panel list and hidding them via C++ module

[Sebastian Kügler]

On Tuesday, February 10, 2015 22:24:02 Evgeniy Alekseev wrote:
> On Tuesday 10 February 2015 12:32:49 Sebastian Kügler wrote:
> > Why not just add the ability to hide a panel with a shortcut?
> 
> Just an idea that some related items may be collected by one item (e.g. 
> Plasmoid) to prevent similar actions to configure item.
> 
> (BTW I didn't find ability to hide panel by configuring it, could you
> please  describe how can I do it?)

That would have to be added in the panel's code. I don't think it does that, 
yet.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122505: Warn about brightness getting too low

[Emmanuel Pescosta]

> On Feb. 11, 2015, 12:50 a.m., Thomas Pfeiffer wrote:
> > Basic rule from design for safety: Don't use a warning if you can prevent 
> > the dangerous action completely.
> > In this case that means: Setting the brightness to zero should only be 
> > possible via keyboard, because that ensures recoverability.
> > 
> > Don't display any warning. Instead, when the slider reaches the minimum, 
> > display a hint saying "To prevent switching off the screen by accident, 
> > setting the brightness lower than [sensible value]% is only possible using 
> > the keyboard".
> > 
> > That way, it's not possible to maneuver yourself in an unrecoverable 
> > position but people who like to switch off their screen backlight can still 
> > do so using the keyboard. And we don't need to show a scary warning, but a 
> > helpful hint instead.

What about adding an option to "Adcanced Power Management Settings" that allows 
the user to change between safe/full screen brightness range (default: safe, 
minimum is 5% of the hw range)?

[x] Use the full screen brightness range provided by your hardware (Warning: 0% 
may turn your screen off)

So the warning in the widget can be avoided and the default behavior is the 
same as on most other operating systems (0% != screen off).

My 2 cents ;)


- Emmanuel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122505/#review75824
---


On Feb. 9, 2015, 11:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122505/
> ---
> 
> (Updated Feb. 9, 2015, 11:25 p.m.)
> 
> 
> Review request for Plasma and KDE Usability.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> ---
> 
> Some graphics drivers, notably Intel, turn off the backlight completely when 
> brightness reached zero, which is also in the spec (0 = off, 1 = very dim) 
> but imho that's unexpected. To prevent the user from accidentally turnign the 
> screen off, especially when keyboard brightness controls don't work, which 
> sadly still happens quite often, the slider breaks free from the user's drag 
> (by becoming disable for two (perhaps 1 is enough?) seconds, so we also catch 
> the mouse wheel case) and displays a warning (which stays there until screen 
> brightness is dialed up again).
> 
> 
> Diffs
> -
> 
>   applets/batterymonitor/package/contents/ui/BrightnessItem.qml 546ab58 
>   applets/batterymonitor/package/contents/ui/PopupDialog.qml a2acf31 
> 
> Diff: https://git.reviewboard.kde.org/r/122505/diff/
> 
> 
> Testing
> ---
> 
> Works pretty well, I just realized I forgot the mousewheel-on-trayicon case. 
> Also, I'm open to wording suggestions since it sounds more like "we suck, 
> sorry about that". (Note in the screenshot I used the mouse wheel, hence the 
> displayed 4% rather than 5)
> 
> 
> File Attachments
> 
> 
> Screenshot
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/02/09/8b585088-e33e-4862-9c46-207d06f566f1__dimwarning.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122420: reimplement some of the systemmonitor plasmoids

[Marco Martin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122420/
---

(Updated Feb. 11, 2015, 9:31 a.m.)


Status
--

This change has been marked as submitted.


Review request for Plasma.


Repository: plasma-workspace


Description
---

this refactors the net systemmonitor plasmoid (hopefully fixing some of the 
bugs people had with it)
and brings back some other modules:
* cpu usage
* disk i/o activity
* memory usage
All applets share most of their stuff having as little duplication as possible


Diffs
-

  applets/CMakeLists.txt 25d774e 
  applets/systemmonitor/CMakeLists.txt PRE-CREATION 
  applets/systemmonitor/Messages.sh 2382ed6 
  applets/systemmonitor/common/contents/config/main.xml PRE-CREATION 
  applets/systemmonitor/common/contents/ui/Applet.qml PRE-CREATION 
  applets/systemmonitor/common/contents/ui/ConfigGeneral.qml PRE-CREATION 
  applets/systemmonitor/common/contents/ui/DoublePlotter.qml PRE-CREATION 
  applets/systemmonitor/common/contents/ui/SinglePlotter.qml PRE-CREATION 
  applets/systemmonitor/contents/config/config.qml 11944e5 
  applets/systemmonitor/contents/config/main.xml 57a30cb 
  applets/systemmonitor/contents/ui/configGeneral.qml 164e890 
  applets/systemmonitor/contents/ui/net.qml 20e1d47 
  applets/systemmonitor/cpu/Messages.sh PRE-CREATION 
  applets/systemmonitor/cpu/contents/config/config.qml PRE-CREATION 
  applets/systemmonitor/cpu/contents/ui/cpu.qml PRE-CREATION 
  applets/systemmonitor/cpu/contents/ui/cpuConfig.qml PRE-CREATION 
  applets/systemmonitor/cpu/metadata.desktop PRE-CREATION 
  applets/systemmonitor/diskactivity/Messages.sh PRE-CREATION 
  applets/systemmonitor/diskactivity/contents/config/config.qml PRE-CREATION 
  applets/systemmonitor/diskactivity/contents/ui/diskactivity.qml PRE-CREATION 
  applets/systemmonitor/diskactivity/contents/ui/diskactivityConfig.qml 
PRE-CREATION 
  applets/systemmonitor/diskactivity/metadata.desktop PRE-CREATION 
  applets/systemmonitor/diskusage/Messages.sh PRE-CREATION 
  applets/systemmonitor/diskusage/contents/config/config.qml PRE-CREATION 
  applets/systemmonitor/diskusage/contents/ui/diskusage.qml PRE-CREATION 
  applets/systemmonitor/diskusage/contents/ui/diskusageConfig.qml PRE-CREATION 
  applets/systemmonitor/diskusage/metadata.desktop PRE-CREATION 
  applets/systemmonitor/memory/Messages.sh PRE-CREATION 
  applets/systemmonitor/memory/contents/config/config.qml PRE-CREATION 
  applets/systemmonitor/memory/contents/ui/memory.qml PRE-CREATION 
  applets/systemmonitor/memory/contents/ui/memoryConfig.qml PRE-CREATION 
  applets/systemmonitor/memory/metadata.desktop PRE-CREATION 
  applets/systemmonitor/metadata.desktop 00965ab 
  applets/systemmonitor/net/Messages.sh PRE-CREATION 
  applets/systemmonitor/net/contents/config/config.qml PRE-CREATION 
  applets/systemmonitor/net/contents/ui/net.qml PRE-CREATION 
  applets/systemmonitor/net/contents/ui/netConfig.qml PRE-CREATION 
  applets/systemmonitor/net/metadata.desktop PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/122420/diff/


Testing
---


Thanks,

Marco Martin

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel