Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lockscreen handling? #193

Open
kristianvld opened this issue May 16, 2022 · 2 comments
Open

Lockscreen handling? #193

kristianvld opened this issue May 16, 2022 · 2 comments

Comments

@kristianvld
Copy link

This is partly question / partly feature request.

My current setup uses i3lock-color as the screen lock. This usually blocks anything else from being displayed, but notifications seems to still be displayed over it. Some might like this, but personally I would like to not show the notification content, so I have a custom script to enter and exit of the the lock screen which uses the pause/unpause popup notifications feature to stop notifications while the lock screen is active.

This works fine, but ideally it would be nice to still see notifications show up, but just redact out the content, similar to most phones or notifications in macOS.

image

As it is now, this is not really solvable through scripting either as modifying notifications with scripts would modify them permanently, even after unlocking the screen and checking them out in the notification area.

I would imagine a good solution to this would be to be able to trigger "redact mode" similar to the pause/unpause feature that could be integrated in screenlock scripts or similar. In such a "redact mode" it would also be nice with a new css class being applied, so the notifications could also be styled differently.

More advanced detection could also be cool, but maybe bloated, like auto detect if common screen lockers are active, or being able to specify a process name that will be scanned for, like pidof i3locks-color.

@kristianvld
Copy link
Author

kristianvld commented May 16, 2022

As is usually the case; right after I had written this I think I came up with a pretty decent solution that should be obvious if I had thought it out a bit more.

Basically, using the reload style feature, we can just update the css to hide content when we enter the lock screen and display it again when we exit.

To make it easy to maintain and update, I use the following:

Script to active the screen lock. The screen locker is blocking so the command exit at the time the user logs in:

#!/bin/sh

# deadd notification center handling
# hide notification text when locked
unlocked_css=$XDG_CONFIG_HOME/deadd/deadd-unlocked.css
locked_append_css=$XDG_CONFIG_HOME/deadd/deadd-locked-append.css
target_css=$XDG_CONFIG_HOME/deadd/deadd.css

cat "$unlocked_css" "$locked_append_css" > "$target_css"
notify-send -h byte:deadd-notification-center:1 -h string:type:reloadStyle a

i3lock-color \
        -i ~/.config/images/wallpaper.png \
        --scale \
  ... all lock options ...
        --nofork && cp -f "$unlocked_css" "$target_css" && notify-send -h byte:deadd-notification-center:1 -h string:type:reloadStyle a

Then I can still edit the deadd-unlocked.css as normal, as if it was the main css file. At the bottom it contains:

/* Unlocked Handling */
.title, .body,  image.image {
  opacity: 1;
}

And the deadd-locked-append.css simply contains:

/* Locked Handling */
.title, .body, image.image {
  opacity: 0;
}

The opacity: 1; is needed as styles are not properly reset when reloaded.


With this setup, the title, body and image is hidden in notifications on the lock screen, while other styling, application name and so on is still visible. As we are only reloading css, the notification is fully visible as normal in the sidebar notification center and instantly viewable when unlocked.

I suppose this mostly fixes the issue as there are workarounds, but would be nice with some proper support to not have to move around and reload the css files, like a custom css class that could be applied and triggered remotely.

@phuhl
Copy link
Owner

phuhl commented May 18, 2022

Nice workaround!

I don't see me building that feature any time soon, but if you build an PR that does what you proposed, I'd be happy to review it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants