non-forking when fuzzy flag applied about i3lock-blur HOT 6 CLOSED

Well I don't have enough time right now to check the code, why not forking was a good idea.
But I am using a different approach for locking on suspend.
I use a program called xss-lock https://bitbucket.org/raymonad/xss-lock
It listens for systemd events and runs your supplied program when session is locked. In my i3 config file I have lines

# screenlocker
exec --no-startup-id xss-lock -- i3lock -f

from i3lock-blur.

No worries, if I felt a bit more up to speed with my meager C skills I would take a stab at it myself.
Your method using xss-lock however works just perfect, so I'll stick to that for the moment.

from i3lock-blur.

I looked into the code.
i3lock forks when the mapnotify event happens. This event happens when a (new) window is mapped to screen.
Without fuzzy option, the i3lock creates a new window for itself, and when that is mapped, i3lock forks.
With fuzzy option a new window is not created, an overlay window is used. This means that mapnotify event is not executed and i3lock doesn't fork right away. But it will fork, when some other application creates a window and that window gets mapped.

from i3lock-blur.

I made it fork with fuzzy option right away.

from i3lock-blur.

Sweet, I'll give it a spin first thing tomorrow morning :)
On Sep 18, 2014 8:55 PM, "karulont" [email protected] wrote:

Closed #4 #4.

—
Reply to this email directly or view it on GitHub
#4 (comment).

from i3lock-blur.

It works like a charm over here. Thanks for helping out!

from i3lock-blur.