[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: [KDE Usability] [Kde-hardware-devel] Review Request 122048: Don't suspend when closing the lid a
From:       Achim Bohnet <ach () mpe ! mpg ! de>
Date:       2015-01-15 19:06:27
Message-ID: 31588350.N4ZL8etC4K () allee
[Download RAW message or body]

On Wednesday 14 Jan 2015 12:49:00 Kai Uwe Broulik wrote:
> > On Jan. 14, 2015, 12:29 nachm., Sebastian K=FCgler 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 lapt=
op
> 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 nev=
er =

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 righ=
t =

now and on future lid close:

       [Suspend]  [Ignore]

with a 'standard' 30 sec countdown (on user request what's selected by defa=
ult =

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.
                                      -- reddy@lion.austin.ibm.com

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic