> On Jan. 16, 2013, 4:07 p.m., Oliver Henshaw wrote: > > I'm not sure about this. I do think that control of when to trigger e.g. > > dpms and dimming should shift from powerdevil to screenlocker (leaving the > > mechanism in powerdevil) but this seems a strange place to start. > > > > If this is a companion to https://git.reviewboard.kde.org/r/108375/ (but > > for the simple locker) then what about just dismissing the unlock dialog on > > Escape? This is what the old screensaver did if I read correctly. In fact, > > is that an approach that works for all varieties of locker? > > Thomas Lübking wrote: > The unlock dialog cannot be dismissed, it's what protects the screen > against content exposure - it /is/ the screenlocker by the new architecture > and afaiu. > The "screensaver" is just fancy stuff on top of it for whoever wants > that, but it's not relevant in the locking mechanism. > > I don't think dimming belongs into the locker at all (why?) and Aaron > preferred to keep the ability to dpms in one place and not link Xdpms from > the locker/greeter. > > As pointed out, i believe that in the long run dpms (and pot. dimming if > it's not) should be abstracted in solid, but for now it has to be done on the > workspace layer and (only) powerdevil already has it. > > I frankly don't know what the "simple locker" configures as screensaver > (no screensaver, no screensaver kcm, not gonna happen ;-) but if it disables > m_showScreenSaver in the locker app, then yes - this is gonna just turn off > your screen when you press escape from the locker instead of showing some > fancy animation. > > Notice that i'm a foreigner in this context - i've no idea who's in > charge of screenlocking / saving and just hooked on when there was this stir > on k-c-d. > > I'll hold the push back for the next 3 hours (20:30 CET) to resolve > pending questions. > > Oliver Henshaw wrote: > I've some familiarity with powerdevil but not much insight into the > architecture of the greeter part of the screenlocker. > > If the screenlocker DESIGN document is still valid, then it's the > fullscreen window provided by the LockScreen class that obscures the desktop. > The greeter goes over it. The simple locker is a qml thing managed by > greeterapp, the same thing that launches the legacy screensaver windows - I > think the simple locker is what is revealed when the screenlocker is hidden. > I think the Simple Locker and the plasma based Desktop Widgets use the same > qml password dialog. So it's this password dialog that should be > dismissable/hideable, leaving whatever is in the background intact. > > I believe the dialog needs to be hideable on: the Desktop Widgets locker, > since once you bring it up with "Leave Screen" it stays there indefinitely; > the Simple Locker, since it's always present and obscures the wallpaper > background. If my understanding in the paragraph above is correct, hiding it > in the legacy screensaver means hiding the whole simple locker, which is what > you have done in the other review. > > Oliver Henshaw wrote: > As for dpms, yes I agree that setting dpms modes should stay in > powerdevil for now, that's what I meant by "mechanism" above. I'm talking > about how currently both powerdevil and the screenlocker do things that > affect the screen on idle - unifying them in screenlocker allows things like > dimming as a warning the screenlocker is about to trigger (sadly this may > only be feasible on laptops) or more aggressive dpms-on-idle when the screen > is locked. > > I haven't put code to paper to test out these ideas, so I'm afraid I'm > slightly waffly when it comes to talking about shifting the balance of > responsibilities between powerdevil and screenlocker and what that would look > like.
OK, I never touched or checked the plasma locker process. The "simple locker" ie. kscreenlocker_greet is not hidden by the other patch, but instead the "legacy fancy show" (tm) is re-shown. I tested and there is NO OTHER WINDOW protecting the screen but the declarative views created in greeterapp.cpp - this part of the design document is dated or the implementation flawed (i had not expected, because in former tests a second screen got exposed when added automatically; but there's no window unless i show those views!) The dialog is part of the persistant kscreenlocker_greet window, the present code did never intend to hide that ever (but reshow the fancy show on top of it) Dimming screen to warn about screenlocker won't work on most non-mobile devices (and only if there's any infrastructure for DDC in KDE at all) nor when your display os dimmed anyway. I'm not sure whether it's requried to warn about a screenlocker being about to kick in, but if it's demanded, it has to happen in a more system agnostic way (eg. notification etc.) I intend to push the commits and expect you'll push the dpms fix as well for RC3 - is that ok for you? - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108417/#review25663 ----------------------------------------------------------- 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
