As discussed in https://git.reviewboard.kde.org/r/117091/. Not using the
SA_RESTART flag might (in theory) cause the greeter to be aborted
(because certain syscalls may be interrupted and fail with EINTR).
SA_RESTART seems to be the BSD default and is used by "legacy" signal()
by default in glibc 2 and later as well anyway.
REVIEW: 118563
Together with adding back the KCM the settings are slightly adjusted to
have them fit the UI without needing a transformation in the KCM.
* timeout is stored in minutes (used to be seconds)
* grace time is stored in seconds (used to be msec)
* lock is enabled by default
Also disabling the locking after idle timeout is no longer possible. An
endless grace made some sense with the screensavers, but not with the
screenlocker. In order to not break an unknown but maybe valid use case
the option is still available, just not exposed through UI.
REVIEW: 118038
Instead of having the greeter read the settings of the KSLD, KSLD passes
the required values to the greeter as command line arguments. This
ensures that the greeter doesn't show a lock UI while the KSLD is still
in grace time and vice versa.
Two command line options are added:
--graceTime <milliseconds>
--nolock
The option --graceTime starts the timer to show the lock ui on timeout.
The option --nolock is for the case that the KSLD never locks the
screen.
REVIEW: 118214
The LockWindowTest checks whether the window is black.
We are only interested in the rgb value, so ignore the alpha channel.
This fixes the failing test on the CI system which uses a different
depth.
The LockWindow deep called into KSLDApp to unlock in case of user
activity during grace time. But LockWindow also emits a signal on user
activity. From an architectural point of view it's better to handle this
directly in the KSLDApp and connect to the signal to unlock if it's in
grace time.
Another advantage is that LockWindow now no longer pulls in the KSLDApp
which improves the unit test situation for the LockWindow as the
lockWindowTest no longer needs to link the complete ksld library.
REVIEW: 118160
So far the unit test verifies that:
* screen gets blanked as soon as the first lock window is mapped
* screen stays blanked when the lock window gets destroyed
* screen stays blanked if a window is raised on top of the stack
REVIEW: 118012
The unit test so far only tests establishGrab. This is a little bit
tricky as we need a different X Client which grabs pointer or keyboard
to make establishGrab fail. For that two small helper applications are
included which do nothing else than connecting to X and the one grabbing
keyboard the other grabbing pointer.
The applications are started from the test to get the keyboard/pointer
grabbed which results in ::establishGrab to return false.
What this test is not yet able to test is handling the sleep between two
grab attemps.
As the test is using doUnlock() from KSldApp, the implementation is
changed to use xcb for ungrab pointer/keyboard. With XLib the test would
have needed an XSync which would have required to either add the XLib
call to the test or doUnlock or implement the sync using xcb.
REVIEW: 117995
All QQuickWindows share a default format. By setting a custom format
it overwrites the default and this results in a format without a
stencil buffer being requested resulting in possible rendering errors.
This was used to get an alpha buffer. Instead use the static method
on QQuickWindow to request an alpha buffer.
REVIEW: 118123
It was used to ensure that the view which last got pressed on gets
keyboard events. This is no longer needed, after clicking a screen the
keyboard events end on the correct screen.
REVIEW: 118013
It's not a screensaver anymore so not save into a config file and group
which would indicate so. Also introduce a dedicated group for the options
relevant only in the greeter.
* we don't have screen savers any more
* it's only used if timeout is larger than 0
Thus the timeout itself is good enough. To make sure the timeout value is
sane it got a min of 0.
The idea behind this unit test is to verify that no matter which signal
is sent to the greeter it doesn't return an exit code of 0 which would
indicate a successful authentication.
The test starts the greeter (needs to be installed) and waits 5 sec to
make sure that the greeter is really up and running. If the signal is
sent to early it's causing a CrashExit, which is fine but not the
expected result. There's an additional test to verify that the early sent
signal results in CrashExit.
REVIEW: 117893
Wolfgang Bauer
Yuri Chornoivan
Aleix Pol
Martin Gräßlin
Sebastian Kügler
Jonathan Riddell
