> On Jan. 14, 2013, 9:52 p.m., Dario Freddi wrote: > > ksmserver/screenlocker/greeter/greeterapp.cpp, lines 272-275 > > <http://git.reviewboard.kde.org/r/108417/diff/1/?file=107301#file107301line272> > > > > Just in case: should we check for the existence of the interface? I can > > picture a case where powerdevil is inactive. I guess in that case asyncCall > > would simply silently fail, but better safe than sorry. > > Thomas Lübking wrote: > It'll silently fail whereas the query for the interface is a synchronous > (blocking) call which needs either to be performed off-thread > (pendingcallwatcher) or can timeout for (by default) 25 seconds in case > something's wrong with dbus. > > It would only be worth it in order to use a fallback routine then (ie. > calling DPMS directly, but than we would not have to perform the dbus trip > anyway...)
Addendum: of course that would be required in case we'd show a message and use a timered dpms off instead (we cannot lie to the user) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108417/#review25531 ----------------------------------------------------------- On Jan. 14, 2013, 9:12 p.m., Thomas Lübking wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/108417/ > ----------------------------------------------------------- > > (Updated Jan. 14, 2013, 9:12 p.m.) > > > Review request for Plasma and Dario Freddi. > > > Description > ------- > > Requires https://git.reviewboard.kde.org/r/108416/ > This calls powerdevil to turn off the display when the user presses escape, > or rather every second time s/he does so. > > Afaics the powerdevil infrastructure does not allow us to query this value > from the DPMS Action (different from the stuff that is implemented in > backend) so to check whether the screen is currently active (and i actually > believe, this is gonna fail as well, because the state is likely reset on > wakeup before we receive the event, esp. for a dbus call) we'd either have to > link DPMS in the locker ... or invoke a cheap trick, ie. > "s/conditionally/every other time/g" > > Another way i could think off would be to add a message on the QML (like the > caps lock) that the screen is gonna be turned off in 10 seconds and skip that > when the user starts to interact (any mouse or key events) > That's probably the more fair way to say that we cannot otherwise reasonably > handle screenstate toggling - i just worry nobody actually reads such > messages *shrug* > > > Diffs > ----- > > ksmserver/screenlocker/greeter/greeterapp.h f332bfc > ksmserver/screenlocker/greeter/greeterapp.cpp c8e95bd > > Diff: http://git.reviewboard.kde.org/r/108417/diff/ > > > Testing > ------- > > Yes, reliably toggles the screen even after press-holding the escape key > (then wait for the actual screen state and then controlled toggling it) > > > Thanks, > > Thomas Lübking > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
