Handle windows popping above the slimlock better. #14
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
|
I just realized that it's not going to work with compositing enabled. So I should probably add a periodic call to XRaiseWindow as a fallback for such a case. |
Contributor
Author
|
Added another commit to raise window in the old way. Which is needed as I said above when compositing is enabled. |
Fix early free
Add config option to set password mask character
Add uninstall section to Makefile and several code cleanups
|
Hi, I know this has been made over a year ago, but as it is still open I thought I'dd my two cents here. @joelburget is no longer maintaining this project. Maybe it would be a good idea to submit this pull request to @dannyn /slimlock ? |
Certain windows (especially notifications like notify-osd, etc) tend to make their windows "override redirect". Such windows can't be prevented from popping on top of slimlock. Previous approach of handling this was to raise our window every second. This is definitely better than nothing but potentially sensitive information is still revealed for some time. And it didn't work at least for me anyway: for some reason XRaiseWindow would not send Expose event. Probably it has something to do with the fact that this XRaiseWindow is send from another thread and Xlib is infamous for its multithreading support. So the new approach is to handle VisibilityNotify events and raise the window in case the event states that our window is partially or fully obscured. This is still not perfect since popping window will be seen as noticeable artifact. But it seems that x11 does not give a way to handle it better.
This change supplements a previous attempt to handle popping windows better. I realized that approach based on mere handling of visibility events doesn't work when compositing is enabled. Thus it's still needed to raise slimlock window from time to time. So I added `raise_interval' configuration option which specifies how often the window must be raised (default value is every 1000ms). It's possible to disable raising completely by setting `raise_interval' to zero. Everything is implemented in a single thread to avoid notorious Xlib multi-threading issues.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Certain windows (especially notifications like notify-osd, etc) tend
to make their windows "override redirect". Such windows can't be
prevented from popping on top of slimlock. Previous approach of
handling this was to raise our window every second. This is definitely
better than nothing but potentially sensitive information is still
revealed for some time. And actually it didn't work at least for me
anyway: for some reason XRaiseWindow would not send Expose
event. Probably it has something to do with the fact that this
XRaiseWindow is send from another thread and Xlib is infamous for its
multithreading support. So the new approach is to handle
VisibilityNotify events and raise the window in case the event states
that our window is partially or fully obscured. This is still not
perfect since popping window will be seen as noticeable artifact. But
it seems that x11 does not give a way to handle it better.