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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
