Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-03-01 Thread Achim Bohnet 
On Wednesday 14 Jan 2015 12:49:00 Kai Uwe Broulik wrote:
> > On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > > I really like this feature.
> > > 
> > > However, I think that UI wise, it looks a bit unpolished. It adds two
> > > checkboxes with long texts, that even I, being a domain expert, need
> > > some thinking to understand.
> > > 
> > > I wonder if we should offer these actions at all, or whether we should
> > > enable the features by default. They do seem useful, I can construct a
> > > use-case pretty easily, but we may get away without the UI options,
> > > still keeping the config keys, perhaps. Then wait until someone
> > > complains or reports unexpected behavior, and then rethink adding the
> > > options.
> > > 
> > > Inline, a few niggles about naming when reading the code and trying to
> > > understand it, nothing really major.
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody
> really knew from the UI what that really does anyway) is just tupid in my
> opinion. Why would you ever *not* want your notebook to suspend when you,
> all by yourself, close the lid?! That's no automatism interrupting you,
> it's you closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid is
> while watching a movie on your TV or when you put your notebook into a
> docking station, but that's what the other option is for. Using your laptop
> as a jukebox on a party might want you to play music, close it so nobody
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to
> inhibit suspend during playback) but I think most people would just opt to
> having the lid opened a bit rather than messing with complicated settings
> they probably don't know exist in the first place.

So instead of 'hiding' this option in a kcm that the average user maybe never 
visits, how about delivering it right to the user eyes?  For every external 
monitor connected only on the first lid close, ask the user what to do right 
now and on future lid close:

   [Suspend]  [Ignore]

with a 'standard' 30 sec countdown (on user request what's selected by default 
could be controlled with a config option without kcm item).   If the user
changes it's mind, the user has to visit the kscreen kcm to change the
default action for this monitor.

[snip-snap]

Achim
-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
  -- re...@lion.austin.ibm.com

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-26 Thread Kai Uwe Broulik 

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

(Updated Jan. 26, 2015, 6:19 nachm.)


Status
--

This change has been marked as submitted.


Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.


Repository: powerdevil


Description
---

Less sensational headline: Skip lid action when external monitor is connected.

This brings the KScreen killer feature in the 4.x times back. Now you can watch 
movies and safely close the lid again!

The confusing "Never prevent an action on lid close" is also moved to the main 
page since it only affects the lid action and is used nowhere else. I'm not 
happy with the wording but "inhibition" is a difficult thing to describe for 
the average user.


Diffs
-

  CMakeLists.txt 27f162c 
  daemon/CMakeLists.txt 454c681 
  daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
  daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
  daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
  daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
  
daemon/actions/bundled/org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.xml
 68b2165 
  kcmodule/global/GeneralPage.cpp 5d9ff10 
  kcmodule/global/generalPage.ui 26204cb 

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


Testing
---

Laptop only, monitor option on -> Suspend
Laptop only, monitor option off -> Suspend
TV connected, monitor option on -> No action
TV connected, monitor option off -> Suspend

PM enabled, inhibit option on -> Suspend
PM disabled, inhibit option on -> No suspend
PM enabled, inhibit option off -> Suspend
PM disabled, inhibit option off -> Suspend


File Attachments


Battery monitor hint
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/860157d4-5e21-45e7-8d0c-0f31e9d75428__externalmonitor1.png
New setting
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/7ea3d406-0f0a-491b-9539-9de93e42bb4b__powerdevilstuff2.png


Thanks,

Kai Uwe Broulik

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-24 Thread Thomas Pfeiffer 

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


Just these two things, rest looks fine to me!


File Attachment: New setting - powerdevilstuff2.png


I'd change the label to "Even when a external monitor is connected." Yes, 
this sounds a bit colloquial, but it makes clear that this doesn't mean "only 
when"



File Attachment: New setting - powerdevilstuff2.png


Checkboxes always have labels on their _right_ side. Left-align the 
checkbox with the label above


- Thomas Pfeiffer


On Jan. 24, 2015, 3:25 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 24, 2015, 3:25 p.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   daemon/CMakeLists.txt 454c681 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   
> daemon/actions/bundled/org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.xml
>  68b2165 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Battery monitor hint
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/860157d4-5e21-45e7-8d0c-0f31e9d75428__externalmonitor1.png
> New setting
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/7ea3d406-0f0a-491b-9539-9de93e42bb4b__powerdevilstuff2.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-24 Thread Kai Uwe Broulik 

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

(Updated Jan. 24, 2015, 3:25 nachm.)


Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.


Changes
---

Expose whether the lid action will actually be triggered over dbus so battery 
monitor can display a hint (also Dan said he would've liked something like this 
for KScreen too). Lid action is now always explicit.

The hint does not say "currently will not suspend" because it's configured to 
never do that. There's a settings button in battery now to ease changing this 
setting.


Repository: powerdevil


Description
---

Less sensational headline: Skip lid action when external monitor is connected.

This brings the KScreen killer feature in the 4.x times back. Now you can watch 
movies and safely close the lid again!

The confusing "Never prevent an action on lid close" is also moved to the main 
page since it only affects the lid action and is used nowhere else. I'm not 
happy with the wording but "inhibition" is a difficult thing to describe for 
the average user.


Diffs (updated)
-

  CMakeLists.txt 27f162c 
  daemon/CMakeLists.txt 454c681 
  daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
  daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
  daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
  daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
  
daemon/actions/bundled/org.kde.Solid.PowerManagement.Actions.HandleButtonEvents.xml
 68b2165 
  kcmodule/global/GeneralPage.cpp 5d9ff10 
  kcmodule/global/generalPage.ui 26204cb 

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


Testing
---

Laptop only, monitor option on -> Suspend
Laptop only, monitor option off -> Suspend
TV connected, monitor option on -> No action
TV connected, monitor option off -> Suspend

PM enabled, inhibit option on -> Suspend
PM disabled, inhibit option on -> No suspend
PM enabled, inhibit option off -> Suspend
PM disabled, inhibit option off -> Suspend


File Attachments (updated)


Battery monitor hint
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/860157d4-5e21-45e7-8d0c-0f31e9d75428__externalmonitor1.png
New setting
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/24/7ea3d406-0f0a-491b-9539-9de93e42bb4b__powerdevilstuff2.png


Thanks,

Kai Uwe Broulik

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-23 Thread Kai Uwe Broulik 


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.
> 
> Kai Uwe Broulik wrote:
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be 
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody 
> really knew from the UI what that really does anyway) is just tupid in my 
> opinion. Why would you ever *not* want your notebook to suspend when you, all 
> by yourself, close the lid?! That's no automatism interrupting you, it's you 
> closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid 
> is while watching a movie on your TV or when you put your notebook into a 
> docking station, but that's what the other option is for. Using your laptop 
> as a jukebox on a party might want you to play music, close it so nobody 
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to 
> inhibit suspend during playback) but I think most people would just opt to 
> having the lid opened a bit rather than messing with complicated settings 
> they probably don't know exist in the first place.
> 
> Usability team, what do you think? Do we need settings for either of them?
> 
> Heiko Tietze wrote:
> It makes sense to hide options that nobody will use. But as you said 
> there might be some use cases. So what's about a setting like 'use it in this 
> way (on/off)' but 'allow application to override (on/off)'. I have OpenGL 
> antialiasing or the like in mind.
> 
> So my suggestion is
> Close lid: [Hibernate/Suspend/Shut down/Start Activity]
> [x] Allow applications to override setting
> 
> This makes KScreen responsible to handle the issue when an external 
> display is connected. 
> 
> About the label, HIG for checkboxes contains the advice "Checking a check 
> box should always "enable" an option or change the state of an option to 
> "on". Checking a negative or disabling option is a double negative and causes 
> confusion and errors." 
> (https://techbase.kde.org/Projects/Usability/HIG/Check_Box)
> 
> Sebastian Kügler wrote:
> Bit problematic here is that "inhibit" is already a negation. That may be 
> adding to possible confusion.
> 
> I' still in favor of not offering the option in the UI for now. Let's see 
> if someone needs it and lets us know.
> 
> Achim Bohnet wrote:
> Instead of 'hiding' this option in the kcm that the average user maybe 
> never visit, how about also delivering it to the user eyes just in the right 
> moment?
> 
> For every external monitor connected: only on the first lid close, ask 
> the user what to do right now and on future lid close:
> 
>[Suspend]  [Ignore]
> 
> with a 'standard' 30 sec countdown.  What's selected by default could be 
> controlled with a config option without a kcm item.   If the user
> changes it's mind, the user has to visit the kscreen kcm to change the 
> default action for this monitor.
> 
> Thomas Pfeiffer wrote:
> Achim's idea makes a lot of sense to me!
> I'd suggest the following dialog:
> "Laptop lid was closed. Suspending in 10 seconds" 
> with visuals like the "Confirm logout" dialog and the options "Do not 
> suspend" and "Suspend" and a checkbox "Remember my decision".
> That way users can either decide each time or keep the same decision. 
> This should then be synced with the KCM.
> 
> In this situation, I think giving users a choice does make sense, because 
> even people with a second monitor may want to use lid close as a quick way to 
> suspend when they're away from the computer, but then when they're indeed 
> e.g. watching a movie with the lid closed, they don't want it to suspend in 
> that situation.
> 
> Alternatively we might remove the option in the KCM as well as the 
> "Remember my decision" checkbox and just give the user the option to cancel 
> the suspend each time, but that might annoy users who never want to suspend 
> (while it should be fine with those who always want to suspend as they can 
> just leave the computer alone and it will suspend 10 seconds later.

Discussion with Dan showed that it's quite difficult to have it remembe

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-16 Thread Thomas Pfeiffer 


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.
> 
> Kai Uwe Broulik wrote:
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be 
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody 
> really knew from the UI what that really does anyway) is just tupid in my 
> opinion. Why would you ever *not* want your notebook to suspend when you, all 
> by yourself, close the lid?! That's no automatism interrupting you, it's you 
> closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid 
> is while watching a movie on your TV or when you put your notebook into a 
> docking station, but that's what the other option is for. Using your laptop 
> as a jukebox on a party might want you to play music, close it so nobody 
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to 
> inhibit suspend during playback) but I think most people would just opt to 
> having the lid opened a bit rather than messing with complicated settings 
> they probably don't know exist in the first place.
> 
> Usability team, what do you think? Do we need settings for either of them?
> 
> Heiko Tietze wrote:
> It makes sense to hide options that nobody will use. But as you said 
> there might be some use cases. So what's about a setting like 'use it in this 
> way (on/off)' but 'allow application to override (on/off)'. I have OpenGL 
> antialiasing or the like in mind.
> 
> So my suggestion is
> Close lid: [Hibernate/Suspend/Shut down/Start Activity]
> [x] Allow applications to override setting
> 
> This makes KScreen responsible to handle the issue when an external 
> display is connected. 
> 
> About the label, HIG for checkboxes contains the advice "Checking a check 
> box should always "enable" an option or change the state of an option to 
> "on". Checking a negative or disabling option is a double negative and causes 
> confusion and errors." 
> (https://techbase.kde.org/Projects/Usability/HIG/Check_Box)
> 
> Sebastian Kügler wrote:
> Bit problematic here is that "inhibit" is already a negation. That may be 
> adding to possible confusion.
> 
> I' still in favor of not offering the option in the UI for now. Let's see 
> if someone needs it and lets us know.
> 
> Achim Bohnet wrote:
> Instead of 'hiding' this option in the kcm that the average user maybe 
> never visit, how about also delivering it to the user eyes just in the right 
> moment?
> 
> For every external monitor connected: only on the first lid close, ask 
> the user what to do right now and on future lid close:
> 
>[Suspend]  [Ignore]
> 
> with a 'standard' 30 sec countdown.  What's selected by default could be 
> controlled with a config option without a kcm item.   If the user
> changes it's mind, the user has to visit the kscreen kcm to change the 
> default action for this monitor.

Achim's idea makes a lot of sense to me!
I'd suggest the following dialog:
"Laptop lid was closed. Suspending in 10 seconds" 
with visuals like the "Confirm logout" dialog and the options "Do not suspend" 
and "Suspend" and a checkbox "Remember my decision".
That way users can either decide each time or keep the same decision. This 
should then be synced with the KCM.

In this situation, I think giving users a choice does make sense, because even 
people with a second monitor may want to use lid close as a quick way to 
suspend when they're away from the computer, but then when they're indeed e.g. 
watching a movie with the lid closed, they don't want it to suspend in that 
situation.

Alternatively we might remove the option in the KCM as well as the "Remember my 
decision" checkbox and just give the user the option to cancel the suspend each 
time, but that might annoy users who never want to suspend (while it should be 
fine with those who always want to suspend as they can just leave the computer 
alone and it will suspend 10 seconds later.


- Thomas


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

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-15 Thread Achim Bohnet 


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.
> 
> Kai Uwe Broulik wrote:
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be 
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody 
> really knew from the UI what that really does anyway) is just tupid in my 
> opinion. Why would you ever *not* want your notebook to suspend when you, all 
> by yourself, close the lid?! That's no automatism interrupting you, it's you 
> closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid 
> is while watching a movie on your TV or when you put your notebook into a 
> docking station, but that's what the other option is for. Using your laptop 
> as a jukebox on a party might want you to play music, close it so nobody 
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to 
> inhibit suspend during playback) but I think most people would just opt to 
> having the lid opened a bit rather than messing with complicated settings 
> they probably don't know exist in the first place.
> 
> Usability team, what do you think? Do we need settings for either of them?
> 
> Heiko Tietze wrote:
> It makes sense to hide options that nobody will use. But as you said 
> there might be some use cases. So what's about a setting like 'use it in this 
> way (on/off)' but 'allow application to override (on/off)'. I have OpenGL 
> antialiasing or the like in mind.
> 
> So my suggestion is
> Close lid: [Hibernate/Suspend/Shut down/Start Activity]
> [x] Allow applications to override setting
> 
> This makes KScreen responsible to handle the issue when an external 
> display is connected. 
> 
> About the label, HIG for checkboxes contains the advice "Checking a check 
> box should always "enable" an option or change the state of an option to 
> "on". Checking a negative or disabling option is a double negative and causes 
> confusion and errors." 
> (https://techbase.kde.org/Projects/Usability/HIG/Check_Box)
> 
> Sebastian Kügler wrote:
> Bit problematic here is that "inhibit" is already a negation. That may be 
> adding to possible confusion.
> 
> I' still in favor of not offering the option in the UI for now. Let's see 
> if someone needs it and lets us know.

Instead of 'hiding' this option in the kcm that the average user maybe never 
visit, how about also delivering it to the user eyes just in the right moment?

For every external monitor connected: only on the first lid close, ask the user 
what to do right now and on future lid close:

   [Suspend]  [Ignore]

with a 'standard' 30 sec countdown.  What's selected by default could be 
controlled with a config option without a kcm item.   If the user
changes it's mind, the user has to visit the kscreen kcm to change the default 
action for this monitor.


- Achim


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


On Jan. 13, 2015, 11:16 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 nachm.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6e

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Martin Klapetek 


> On Jan. 14, 2015, 1:29 p.m., Sebastian Kügler wrote:
> > daemon/actions/bundled/handlebuttonevents.h, line 68
> > 
> >
> > Off-hand, I don't understand what these vars ar e doing by reading 
> > their name. Would be nice if it was more clear for the next person to look 
> > at this code. Perhaps a comment?
> 
> Kai Uwe Broulik wrote:
> Right, I didn't want to make the variable name even longer but I'll try 
> to come up with sth.
> 
> Sebastian Kügler wrote:
> Life-Pro-Tip: Don't optimize your code for short variable names, optimize 
> for readability. If that means super long names, so be it. Autocompletion is 
> your friend. :)

^This.


- Martin


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


On Jan. 14, 2015, 12:16 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 14, 2015, 12:16 a.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Config option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Sebastian Kügler 


> On Jan. 14, 2015, 12:29 p.m., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.
> 
> Kai Uwe Broulik wrote:
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be 
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody 
> really knew from the UI what that really does anyway) is just tupid in my 
> opinion. Why would you ever *not* want your notebook to suspend when you, all 
> by yourself, close the lid?! That's no automatism interrupting you, it's you 
> closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid 
> is while watching a movie on your TV or when you put your notebook into a 
> docking station, but that's what the other option is for. Using your laptop 
> as a jukebox on a party might want you to play music, close it so nobody 
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to 
> inhibit suspend during playback) but I think most people would just opt to 
> having the lid opened a bit rather than messing with complicated settings 
> they probably don't know exist in the first place.
> 
> Usability team, what do you think? Do we need settings for either of them?
> 
> Heiko Tietze wrote:
> It makes sense to hide options that nobody will use. But as you said 
> there might be some use cases. So what's about a setting like 'use it in this 
> way (on/off)' but 'allow application to override (on/off)'. I have OpenGL 
> antialiasing or the like in mind.
> 
> So my suggestion is
> Close lid: [Hibernate/Suspend/Shut down/Start Activity]
> [x] Allow applications to override setting
> 
> This makes KScreen responsible to handle the issue when an external 
> display is connected. 
> 
> About the label, HIG for checkboxes contains the advice "Checking a check 
> box should always "enable" an option or change the state of an option to 
> "on". Checking a negative or disabling option is a double negative and causes 
> confusion and errors." 
> (https://techbase.kde.org/Projects/Usability/HIG/Check_Box)

Bit problematic here is that "inhibit" is already a negation. That may be 
adding to possible confusion.

I' still in favor of not offering the option in the UI for now. Let's see if 
someone needs it and lets us know.


- Sebastian


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


On Jan. 13, 2015, 11:16 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 p.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> P

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Sebastian Kügler 


> On Jan. 14, 2015, 12:29 p.m., Sebastian Kügler wrote:
> > daemon/actions/bundled/handlebuttonevents.h, line 68
> > 
> >
> > Off-hand, I don't understand what these vars ar e doing by reading 
> > their name. Would be nice if it was more clear for the next person to look 
> > at this code. Perhaps a comment?
> 
> Kai Uwe Broulik wrote:
> Right, I didn't want to make the variable name even longer but I'll try 
> to come up with sth.

Life-Pro-Tip: Don't optimize your code for short variable names, optimize for 
readability. If that means super long names, so be it. Autocompletion is your 
friend. :)


- Sebastian


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


On Jan. 13, 2015, 11:16 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 p.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Config option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Heiko Tietze 


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.
> 
> Kai Uwe Broulik wrote:
> That's why I added the usability group. :)
> 
> You are right that actually neither of these features really needs to be 
> optional. Turning off that "Do not inhibit on lid close" (I guess nobody 
> really knew from the UI what that really does anyway) is just tupid in my 
> opinion. Why would you ever *not* want your notebook to suspend when you, all 
> by yourself, close the lid?! That's no automatism interrupting you, it's you 
> closing the lid.
> 
> Usecases I could imagine you not wanting to suspend when closing the lid 
> is while watching a movie on your TV or when you put your notebook into a 
> docking station, but that's what the other option is for. Using your laptop 
> as a jukebox on a party might want you to play music, close it so nobody 
> spills beer on the keyboard and not have it suspend (Amarok eg. allows to 
> inhibit suspend during playback) but I think most people would just opt to 
> having the lid opened a bit rather than messing with complicated settings 
> they probably don't know exist in the first place.
> 
> Usability team, what do you think? Do we need settings for either of them?

It makes sense to hide options that nobody will use. But as you said there 
might be some use cases. So what's about a setting like 'use it in this way 
(on/off)' but 'allow application to override (on/off)'. I have OpenGL 
antialiasing or the like in mind.

So my suggestion is
Close lid: [Hibernate/Suspend/Shut down/Start Activity]
[x] Allow applications to override setting

This makes KScreen responsible to handle the issue when an external display is 
connected. 

About the label, HIG for checkboxes contains the advice "Checking a check box 
should always "enable" an option or change the state of an option to "on". 
Checking a negative or disabling option is a double negative and causes 
confusion and errors." 
(https://techbase.kde.org/Projects/Usability/HIG/Check_Box)


- Heiko


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


On Jan. 13, 2015, 11:16 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 nachm.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Config option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Kai Uwe Broulik 


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > I really like this feature.
> > 
> > However, I think that UI wise, it looks a bit unpolished. It adds two 
> > checkboxes with long texts, that even I, being a domain expert, need some 
> > thinking to understand.
> > 
> > I wonder if we should offer these actions at all, or whether we should 
> > enable the features by default. They do seem useful, I can construct a 
> > use-case pretty easily, but we may get away without the UI options, still 
> > keeping the config keys, perhaps. Then wait until someone complains or 
> > reports unexpected behavior, and then rethink adding the options.
> > 
> > Inline, a few niggles about naming when reading the code and trying to 
> > understand it, nothing really major.

That's why I added the usability group. :)

You are right that actually neither of these features really needs to be 
optional. Turning off that "Do not inhibit on lid close" (I guess nobody really 
knew from the UI what that really does anyway) is just tupid in my opinion. Why 
would you ever *not* want your notebook to suspend when you, all by yourself, 
close the lid?! That's no automatism interrupting you, it's you closing the lid.

Usecases I could imagine you not wanting to suspend when closing the lid is 
while watching a movie on your TV or when you put your notebook into a docking 
station, but that's what the other option is for. Using your laptop as a 
jukebox on a party might want you to play music, close it so nobody spills beer 
on the keyboard and not have it suspend (Amarok eg. allows to inhibit suspend 
during playback) but I think most people would just opt to having the lid 
opened a bit rather than messing with complicated settings they probably don't 
know exist in the first place.

Usability team, what do you think? Do we need settings for either of them?


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > daemon/actions/bundled/handlebuttonevents.h, line 68
> > 
> >
> > Off-hand, I don't understand what these vars ar e doing by reading 
> > their name. Would be nice if it was more clear for the next person to look 
> > at this code. Perhaps a comment?

Right, I didn't want to make the variable name even longer but I'll try to come 
up with sth.


> On Jan. 14, 2015, 12:29 nachm., Sebastian Kügler wrote:
> > daemon/actions/bundled/handlebuttoneventsconfig.cpp, line 141
> > 
> >
> > No super-happy with how these strings look like.
> > 
> > Idea:
> > 
> > Do not  when external monitor is connected
> > 
> > As to the second option, is it clear that the lid close depends on 
> > power management being enabled? Do we need this option at all? (Both are 
> > open questions.)

See above.


- Kai Uwe


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


On Jan. 13, 2015, 11:16 nachm., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 nachm.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled,

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Sebastian Kügler 

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


I really like this feature.

However, I think that UI wise, it looks a bit unpolished. It adds two 
checkboxes with long texts, that even I, being a domain expert, need some 
thinking to understand.

I wonder if we should offer these actions at all, or whether we should enable 
the features by default. They do seem useful, I can construct a use-case pretty 
easily, but we may get away without the UI options, still keeping the config 
keys, perhaps. Then wait until someone complains or reports unexpected 
behavior, and then rethink adding the options.

Inline, a few niggles about naming when reading the code and trying to 
understand it, nothing really major.


PowerDevilSettings.kcfg


Why not inhibitOnLidClose? Less negations make it more readable. (I had to 
think about what it meant.)



daemon/actions/bundled/handlebuttonevents.h


Off-hand, I don't understand what these vars ar e doing by reading their 
name. Would be nice if it was more clear for the next person to look at this 
code. Perhaps a comment?



daemon/actions/bundled/handlebuttoneventsconfig.cpp


No super-happy with how these strings look like.

Idea:

Do not  when external monitor is connected

As to the second option, is it clear that the lid close depends on power 
management being enabled? Do we need this option at all? (Both are open 
questions.)


- Sebastian Kügler


On Jan. 13, 2015, 11:16 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 13, 2015, 11:16 p.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Config option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-14 Thread Daniel Vrátil 

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


+1, looks good to me

- Daniel Vrátil


On Jan. 14, 2015, 12:16 a.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122048/
> ---
> 
> (Updated Jan. 14, 2015, 12:16 a.m.)
> 
> 
> Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.
> 
> 
> Repository: powerdevil
> 
> 
> Description
> ---
> 
> Less sensational headline: Skip lid action when external monitor is connected.
> 
> This brings the KScreen killer feature in the 4.x times back. Now you can 
> watch movies and safely close the lid again!
> 
> The confusing "Never prevent an action on lid close" is also moved to the 
> main page since it only affects the lid action and is used nowhere else. I'm 
> not happy with the wording but "inhibition" is a difficult thing to describe 
> for the average user.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 27f162c 
>   PowerDevilSettings.kcfg 1bc7ce1 
>   daemon/CMakeLists.txt f1e6efb 
>   daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
>   daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
>   daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
>   daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
>   kcmodule/global/GeneralPage.cpp 5d9ff10 
>   kcmodule/global/generalPage.ui 26204cb 
> 
> Diff: https://git.reviewboard.kde.org/r/122048/diff/
> 
> 
> Testing
> ---
> 
> Laptop only, monitor option on -> Suspend
> Laptop only, monitor option off -> Suspend
> TV connected, monitor option on -> No action
> TV connected, monitor option off -> Suspend
> 
> PM enabled, inhibit option on -> Suspend
> PM disabled, inhibit option on -> No suspend
> PM enabled, inhibit option off -> Suspend
> PM disabled, inhibit option off -> Suspend
> 
> 
> File Attachments
> 
> 
> Config option
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel

[Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid and an external monitor is connected

2015-01-13 Thread Kai Uwe Broulik 

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

Review request for Solid, KDE Usability, Àlex Fiestas, and Daniel Vrátil.


Repository: powerdevil


Description
---

Less sensational headline: Skip lid action when external monitor is connected.

This brings the KScreen killer feature in the 4.x times back. Now you can watch 
movies and safely close the lid again!

The confusing "Never prevent an action on lid close" is also moved to the main 
page since it only affects the lid action and is used nowhere else. I'm not 
happy with the wording but "inhibition" is a difficult thing to describe for 
the average user.


Diffs
-

  CMakeLists.txt 27f162c 
  PowerDevilSettings.kcfg 1bc7ce1 
  daemon/CMakeLists.txt f1e6efb 
  daemon/actions/bundled/handlebuttonevents.h 8ea23f6 
  daemon/actions/bundled/handlebuttonevents.cpp ac280f4 
  daemon/actions/bundled/handlebuttoneventsconfig.h a55bca7 
  daemon/actions/bundled/handlebuttoneventsconfig.cpp 92f0cef 
  kcmodule/global/GeneralPage.cpp 5d9ff10 
  kcmodule/global/generalPage.ui 26204cb 

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


Testing
---

Laptop only, monitor option on -> Suspend
Laptop only, monitor option off -> Suspend
TV connected, monitor option on -> No action
TV connected, monitor option off -> Suspend

PM enabled, inhibit option on -> Suspend
PM disabled, inhibit option on -> No suspend
PM enabled, inhibit option off -> Suspend
PM disabled, inhibit option off -> Suspend


File Attachments


Config option
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/01/13/e0956548-0a0f-4c41-b3dd-68a5f17815a5__powerdevilstuff.png


Thanks,

Kai Uwe Broulik

___
Kde-hardware-devel mailing list
Kde-hardware-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-hardware-devel