-
Notifications
You must be signed in to change notification settings - Fork 14
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bilelmoussaoui I'm unsure if this is the correct way of using the receive_color_scheme_changed
method.
PR moved to #26 |
Implements
notify
function, which takes a sender and sends the current mode when it changes.notify
notify
Resolves #3