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

Change default idle attribute to false #25

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

slovdahl
Copy link
Contributor

@slovdahl slovdahl commented Feb 19, 2024

Right now when the companion app is started, the status sensor will have the idle attribute set to unknown until the computer has been put in suspend or is shut down. I'm suggesting that we change the default value to false instead, because unless I'm mistaken, it should be safe to assume that the computer is not idle when the companion app starts.

Having only two valid states of the idle attribute simplifies using it in e.g. automations.

Right now when the companion app is started, the status sensor will have the
`idle` attribute set to `unknown` until the computer has been put in suspend
or is shut down. I'm suggesting that we change the default value to `false`
instead, because unless I'm mistaken, it should be safe to assume that the
computer is _not_ idle when the companion app starts. Having only two valid
states of the `idle` attribute simplifies using it in e.g. automations.
@slovdahl
Copy link
Contributor Author

Maybe there are some edge cases around this after all 🤔 If for some reason the companion app is restarted while the user running it has the screen locked for example.

@slovdahl
Copy link
Contributor Author

Can the state be queried?

@muniter
Copy link
Owner

muniter commented Feb 25, 2024

🤔 we would need to implement the query to be sure.

@muniter
Copy link
Owner

muniter commented Feb 25, 2024

@slovdahl slovdahl marked this pull request as draft February 25, 2024 19:32
@slovdahl
Copy link
Contributor Author

I think we do need querying for quite normal cases too. With this PR, when the computer wakes up the status is immediately considered "active". Only after logging in and locking the screen the status will be correct.

I noticed this because I sometimes get my desktop computer woken up (kids, wife, etc) when I'm not sitting there.

@slovdahl slovdahl marked this pull request as ready for review September 16, 2024 16:50
@slovdahl slovdahl marked this pull request as draft September 16, 2024 16:50
@slovdahl
Copy link
Contributor Author

I think we do need querying for quite normal cases too. With this PR, when the computer wakes up the status is immediately considered "active". Only after logging in and locking the screen the status will be correct.

I noticed this because I sometimes get my desktop computer woken up (kids, wife, etc) when I'm not sitting there.

Hmm, or has this been caused by some kind of timing issue/race condition somewhere.. I made a minimal Python script listening to the various DBus events and AFAICT the events arrive at the right times and in the right order. But I'm now testing it on an Ubuntu 24.04 laptop, and my desktop where I have been using it before is on Ubuntu 22.04. Need to dig a bit more.

@slovdahl
Copy link
Contributor Author

@muniter I managed to query the state from org.gnome.ScreenSaver at least. It doesn't seem like org.freedesktop.ScreenSaver exposes the current state. At least not on my Ubuntu 24.04.

bus = Dbus()
await bus.init()
screensaver_interface = await bus.get_interface("org.gnome.ScreenSaver")
is_active = await screensaver_interface.call_get_active()

Now I just wonder how or where to hook it in.

One idea I got was to query the state in status.py's updater method if self.attributes["idle"] == "unknown". But 1) the DBus instance is not available there 2) the method is not async.

Or we could try to do something similar to SIGNALS in dbus.py.. But I'm not sure how one would tell dbus.py when the querying should be done, unless we query it every refresh_interval, but that feels a bit overkill.

If you have some rough idea of how it could be done in a good way I'm all ears.

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.

2 participants