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

Re-apply window title on/off after screen unlocking #1370

Open
wants to merge 1 commit into
base: master_focal
Choose a base branch
from

Conversation

fhackenberger
Copy link

Before this change the window titles were still visible after
unlocking the screen, even if the setting was to off.

Before this change the window titles were still visible after
unlocking the screen, even if the setting was to off.
@mmstick
Copy link
Member

mmstick commented Mar 11, 2022

This adds methods to pop-shell's public DBus API. Did you mean to add these methods to the extension class instead?

@jacobgkau
Copy link
Member

Before this change the window titles were still visible after
unlocking the screen, even if the setting was to off.

I'm not able to recreate this issue on Pop!_OS 21.10, 20.04 LTS, or 22.04 LTS pre-release. I typically test this feature with Evolution, Thunderbird, or LibreOffice. I've tried manually locking, waiting for the screen to time out, and using a sleep command to launch a window while the screen's locked-- in all cases, the titlebar was still hidden when I unlocked the screen again. What OS and application are you seeing this behavior with?

@fhackenberger
Copy link
Author

fhackenberger commented Mar 14, 2022

I'm not able to recreate this issue on Pop!_OS 21.10, 20.04 LTS, or 22.04 LTS pre-release.

I'm using Ubuntu 20.04 LTS with pop-shell compiled from git master and experience it with Thunderbird for example. Most gnome apps are unaffected these days as they haven't got separate window titles anymore. I lock my screen with Ctrl-Alt-L or suspend the laptop.

This adds methods to pop-shell's public DBus API. Did you mean to add these methods to the extension class instead?

I was unsure where a DBus signal subscription would fit best. I didn't add this method to the DBus interface, so it's not a publicly (over DBus) callable method and prefixed with on... to indicate that it's an event handler. Do you think it should rather be in the Ext class?

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

Successfully merging this pull request may close these issues.

None yet

3 participants