-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Select current file in file picker #4905
Conversation
3c042b9
to
4785866
Compare
90bc020
to
91a6331
Compare
42ff822
to
a6f87c3
Compare
a6f87c3
to
af6c68f
Compare
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.
One minor comment, but otherwise I think this looks reasonable. It is generic enough that it allows for picking a different default in the other pickers as well in the future, should that be desirable.
I considered whether the default item member of the Picker
should be a closure, rather than a concrete value, but I think in all the contexts where pickers are made, they should be able to decide at the time of that picker's construction which actual concrete value to choose as the default.
I haven't tested this locally yet, but the code seems good.
@@ -112,9 +112,11 @@ impl<T: Item> FilePicker<T> { | |||
editor_data: T::Data, | |||
callback_fn: impl Fn(&mut Context, &T, Action) + 'static, | |||
preview_fn: impl Fn(&Editor, &T) -> Option<FileLocation> + 'static, | |||
initial_cursor: Option<T>, |
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.
Should this be called initial_item
instead?
closing this PR as stale. Ultimaetly I don't think this is the direction we would be going with the picker. Sorting is not possible anymore with a streaming picker and imo this usecase is better covered by Thank you for contributing! |
An attempt at implementing #3014