-
Notifications
You must be signed in to change notification settings - Fork 568
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
Spinner widget #1003
Spinner widget #1003
Conversation
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.
Looks promising!
/// The argument can be either a `Color` or a [`Key<Color>`]. | ||
/// | ||
/// [`Key<Color>`]: ../struct.Key.html | ||
pub fn set_color(&mut self, color: impl Into<KeyOrValue<Color>>) { |
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.
These two color methods should mention in their docs that the alpha channel is ignored.
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.
Ah that was an oversight. Fixed it to use the color's alpha.
druid/src/widget/spinner.rs
Outdated
|
||
impl Default for Spinner { | ||
fn default() -> Self { | ||
Spinner::new() |
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.
Can't we use theme::LABEL_COLOR.into(),
in the Default
implementation?
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.
Not sure what you're proposing here.
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.
So the reason you got that clippy warning was because the new
function doesn't take any arguments and could be equal to default
. So what I'm thinking is that we could do the following:
impl Spinner {
/// Create a spinner widget
pub fn new() -> Spinner {
Spinner::default()
}
}
impl Default for Spinner {
fn default() -> Self {
Spinner {
t: 0.0,
color: theme::LABEL_COLOR.into(),
}
}
}
It ends up being the same result for now, but if the new
method gets arguments added to it then it'll be an easier change. This doesn't matter too much, but I'm just thinking I might somewhat prefer to have the default
function be explicit.
Your call.
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.
Ah, that makes sense! Thanks for explaining.
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 think it's in a good enough state to be merged.
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.
Looks good.
This is pretty basic except for the spinning math, which I wish I'd commented while I was writing it!
My layout strategy for this is to only match its container size if that container has a constrained height and width. Otherwise it uses the default widget height key to size itself. Does that sound reasonable?