Thanks for the FFe approval, then: > I'm not sure why you introduced the lock-request signal?
I didn't want to make GSManager (that is a child of GSMonitor) to keep a reference (even a weak one) of its parent, so the quickest way and the one that wouldn't have involved too many changes to the GS code, was to emit a signal that returns a value if the lock is handled. So, in case unity is running and a lock has been requested, if nothing fails, unity will handle it and GS will ignore the lock. > What happens if the lock fails in manager_lock_request? I think you leak the GSignals too. If something fails here, the signal will return FALSE, an thus, the normal GS locking will happen; in case unity will be back (if it has ever been there), then we replace the g-s locking with the native unity locking again. > I think you leak the GSignals too. You mean the connections? Btw I've pushed a new version of the patch... ** Patch added: "33_unity_lockscreen_on_lock.patch" https://bugs.launchpad.net/unity/+bug/1282798/+attachment/4017110/+files/33_unity_lockscreen_on_lock.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1282798 Title: [FFe] Provide a lock screen and unlock dialogs in Unity To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/1282798/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
