[kde-workspace] /: block until the lock windows are shown; prevents sleeping before locking

[Aaron J. Seigo]

On Thursday, March 14, 2013 20:21:59 Oliver Henshaw wrote:
> showLockWindows does seem to hide the screen at some point, because I
> can see the black window if I sleep for a few seconds after the lock
> process exits and before hiding the lock window when unlocking.

possible reason:

LockWindow::updateGeometry is called from the constructor (via 
LockWindow::initialize) .. then showLockWindow is called and QWidget::create 
gets called with the x11 window. the x11 window is being created with the 
geometry of the LockWindow, but i wonder if:

* on calling create, the geometry is getting reset to something else?
* the window is not actually painting anything at all?

> Sprinkling more sleeps around I can see that the screen stays visible
> until UnlockApp::desktopResized() is called by the lock process. But,

correct; this creates and then makes the lock screens. i really think it makes 
the most sense to have these already in place before sleeping.

> > diff --git a/ksmserver/screenlocker/ksldapp.cpp
> > b/ksmserver/screenlocker/ksldapp.cpp index 7f2e671..6a6fad8 100644
> > --- a/ksmserver/screenlocker/ksldapp.cpp
> > +++ b/ksmserver/screenlocker/ksldapp.cpp
> > @@ -277,10 +277,13 @@ bool KSldApp::startLockProcess()
> > 
> >      }
> >      m_lockProcess->start();
> >      // we wait one minute
> > 
> > -    if (!m_lockProcess->waitForStarted()) {
> > +    if (m_lockProcess->waitForStarted(60000)) {
> > +        m_lockProcess->waitForReadyRead(60000);
> 
> This blocks for 60 seconds.

well, up to 120 seconds in a worst-case scenario.

it actually returns as soon as it gets something on stdout from the lock 
process (ergo the cout now in the greeter app).

> I don't think the lockprocess is waiting
> on powerdevil  (see explanation below) so it must be waiting on
> ksmerver. 

lockprocess is not waiting on either thing. it's waiting for the spawned 
greeter process to output something to stdout.

> The old screensaver had the lock process communicate that it was ready
> by calling the org.kde.screensaver.saverLockReady() method over dbus;
> krunner delayed replying to the Lock() dbus call until it was
> notified. Perhaps that is the approach to take. I've rustled up some
> code to attempt this but might not be able to test it until tomorrow.

i'd like to avoid having multiple calls over dbus. it makes things complicated 
on both sides of the wire, when we can simply provide a blocking call that 
waits until all is good.
 
-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130315/e5fd9ef1/attachment.sig>