Color scheme change notifications #10
Conversation
examples/notify.rs
Outdated
| @@ -0,0 +1,8 @@ | |||
| #[tokio::main] | |||
| async fn main() -> anyhow::Result<()> { | |||
| dark_light::notify(&change_color_scheme).await | |||
There was a problem hiding this comment.
This API of an async function running a synchronous callback in an infinite loop feels strange. I haven't seen a future that is expected to never resolve and keep running an infinite loop. I would expect a future from a library to actually return a value. Would it be better for the library to have an async function that returns a Mode value? That way, it would be the application's responsibility to await the future in a loop. I'm not sure about this. @frewsxcv what do you think?
There was a problem hiding this comment.
Thinking about this again, why not both? The library could provide an async function which returns a Mode and the implementation of this notify function could be refactored to use it.
There was a problem hiding this comment.
I updated the code to use tokio channels instead of a callback.
|
@bilelmoussaoui I'm getting an error when calling Using The key is present in my system and works if I call it on version |
|
I will investigate, please open an issue against ashpd |
|
I've been thinking it might be best to ask for a What do you think @frewsxcv? |
Can you explain more what that would look like? Would |
|
Yeah, we ask for a |
|
@edfloreshz Yep! That sounds good to me |
Implemented callback functions for freedesktop and non-freedesktop. Partitioned freedesktop into a module. New module structure Implemented new module structure to macOS and Windows Fix for doc test Ensured that all possible cases are being handled within `Mode` match.
`notify` is now an async function. Modified example to use `tokio` Renamed `Mode::rgb` to `Mode::from_rgb` `freedesktop_watch` now uses `ashpd` beta. Changed signature for `notify` function in macOS and Windows files.
- Updated ashpd
- Removed Settings struct as it was not necessary. - Removed `Settings` parameter from `freedesktop_watch`. - `get_freedesktop_color_scheme` matches `ColorScheme` instead of `u32`
|
I'm currently facing an issue with I created an issue to investigate before continuing with this PR |
When the settings proxy is unable to init, legacy is used as fallback.
|
I marked this PR as ready for review, don't merge until the issue with |
- Upgraded to the master branch of ashpd - Moved the thread spawning to `notify` - Made the async methods return `anyhow::Result<T>`
| while let Ok(color_scheme) = proxy.receive_color_scheme_changed().await { | ||
| let mode = match color_scheme { | ||
| ColorScheme::NoPreference => Mode::Default, | ||
| ColorScheme::PreferDark => Mode::Dark, | ||
| ColorScheme::PreferLight => Mode::Light, | ||
| }; | ||
| tx.send(mode).await?; | ||
| } |
There was a problem hiding this comment.
@bilelmoussaoui I'm unsure if this is the correct way of using the receive_color_scheme_changed method.
|
PR moved to #26 |
Implements
notifyfunction, which takes a sender and sends the current mode when it changes.notifynotifyResolves #3