Skip to content

Change default idle attribute to false - #25

Draft
slovdahl wants to merge 1 commit into
muniter:masterfrom
slovdahl:default-status-idle-attribute-to-false
Draft

Change default idle attribute to false#25
slovdahl wants to merge 1 commit into
muniter:masterfrom
slovdahl:default-status-idle-attribute-to-false

Conversation

@slovdahl

@slovdahl slovdahl commented Feb 19, 2024

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
Contributor Author

Can the state be queried?

@muniter

muniter commented Feb 25, 2024

Copy link
Copy Markdown
Owner

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

@muniter

muniter commented Feb 25, 2024

Copy link
Copy Markdown
Owner

@slovdahl
slovdahl marked this pull request as draft February 25, 2024 19:32
@slovdahl

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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