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