Update to use the new API?

lmaotrigine commented 8 months ago

I don't really plan on making big changes to the Rust rewrite, other than fighting with GitHub Actions for release automation, and finding a way to make the book generally available other than through my profile (which might involve not building the book at all).

Given this, what would the roadmap look like for deprecating the current state of the client in favour of the changes made for the API exposed by the rewrite?

I would like this migration to have as little friction as possible, so this is still an RFC.

5HT2 commented 8 months ago

I'm more than happy to help with Actions stuff, I'll take a look at it! I'd like to deprecate the Go version as well as this client entirely, I mentioned rewriting this client in Rust in #7 but if we can just expose an API in heartbeat-rirr that works too

lmaotrigine commented 7 months ago

Hi, sorry I'm a bit busy these days, so I may be slow to respond to things :)

I actually do have a cross-platform Rust client in the works. It's currently in a horrible state, I'd like to resume work on it when I do get the time.

xprintidle is essentially a single C file, it was easy enough to rewrite in Rust. For macOS, I just translated the implementation in this client to use the frameworks directly instead of shelling out. Windows is already in Rust, so that doesn't change. To be screenlocker agnostic, I thought of using libdbus to query screensaver status. This does make this part of it support Wayland, sort of; but requires a pretty chonky (albeit common-ish on desktops) library at runtime.

I came across the library linked in #7 but the subtle difference in that it waits for an idle time of X before yielding would result in a naive implementation along those lines to be a long running client, which maintains its own internal timer instead of delegating to systemd (I was thinking of using tokio::select!), which I'm kind of iffy about.

I haven't dived very deep into this, but I don't think there's a "stable" API to query screensaver info from Wayland itself. Some of the symbols I used initially to make my own client (while I was still using the Go version of the server), which was incredibly jank, don't even exist anymore.

I would like help with the release automation if you have the time. What I have now, does work. And it does support Windows, Mac, and Linux. But I want to increase the platform support because.. well, I have the credits to spare (which is why I want your opinion before I upstream this because I don't think this org is covered by either of our Pro plans)

I would also ideally like a place to host the documentation built by mdbook, but failing that I think I can just maintain it separately using GitHub's Wiki feature or something (I just like mdbook's look-and-feel and search is better).

5HT2 commented 6 months ago

I think not relying on systemd / maintaining an internal timing seems to be preferable, here? I'm happy to help with the release automation, we should discuss that in more detail :)

lmaotrigine commented 6 months ago

using an internal timer with a subset of the functionality of wayidle seems very plausible. unfortunately I don't have a Wayland setup to test this. I'll get to it next week maybe as I'm swamped for now lol.

I'm happy to discuss release automation in a separate issue

5HT2B / heartbeat-unix

Update to use the new API? #9