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
Add the ability to filter files in the File Dialog #1034
Conversation
Tests added. |
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.
Sorry I missed that a public API from before was not using URI, should probably change to be consistent.
Mostly i am not sure if the filter parameter should be part of the constructing method, and perhaps we should split out a New version for people who want to customise?
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.
You removed the old ShowFileOpen API, but I thought it was discussed that would stay in as a shortcut? And the new APIs gained a Dialog
suffix
I noticed that FileDialog does not implement Dialog, was that decided against?
Otherwise the API seems nice and clean
I added the old API back in as a shortcut and removed the Dialog suffix. FileDialog, now File, does not implement Dialog because I thought it would be messy to do with native pickers on mobile. For instance File is a type that can be used for both the desktop and mobile pickers to pass in configuration/settings. On Desktop, fileDialog is created from this. On mobile it will be used to setup options in the native picker. That being said, while we have a way to handle Show() gracefully if Dialog was implemented. I think other cases would get a little more complicated and I would need to look at the mobile side... For instance with Hide()... easiest enough to hide the fileDialog on desktop. Do we have a handle to the native filepicker that we could use to hide it? with SetOnClosed... The File type already takes in a callback that gets called on close as part of the design so that seems redundant. SetDismissText wouldn't be used either. So with all of that being the case and never reaching an agreement on it in the Slack channel - I just chose the simplest, cleanest way to solve the issue and that was just Show() without implementing the Dialog interface. I'm sure if there are objections, we could implement it simply enough. |
Done. Thanks! |
This is all looking good, but I can't find the tests you mentioned above? |
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!
Just a couple of nits, a question and a suggestion.
formatting/punctuation.
Thanks! I think I resolved all of those points. |
dialog/file.go
Outdated
save bool | ||
callback interface{} |
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 wonder if we should have openCallback and saveCallback to avoid the type casts later on
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 don't mind the type casts later, but perhaps others may have some thought 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.
Unresolving this to see if others have an opinion 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.
I didn't see that this had been reopened, sorry for that.
I agree that it could be improved, it has evolved a little since the first commit and we learned a lot along the way. Let's do a follow-on following discussion in Slack
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 approach seems fine, and inkeeping with the rest of the package.
I think this "isNative" is not needed though (comments inline).
One other thought is that the OnClosed is called sometimes before and sometimes after the file picking callback... it should porobably be consistent.
f.win.Hide() | ||
if f.file.onClosedCallback != nil { |
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 conditional on file.callback
not being nil?
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.
file.callback is the read/write closer callback ... file.onClosedCallback is the onClosed callbacks ... They are unrelated as far as I can tell
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.
Oh I see you were actually referring to code above. In that space we only hide immediately if there is no file.callback ... so we wouldn't want to call the onClosedCallback until the dialog is closed... in this case when file.callback is not nil, we go through things like validation that may keep the dialog open still - if validation passes we call the Hide() and onClosedCallbacks later in the method...
So long story short - I think this is appropriate.
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.
Thanks for the explanation, but I don't quite follow - there is a return here so I don't see where it falls through for the extra processes?
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.
Oh I see what you mean now sorry
Description:
This adds the ability to filter files in Fyne's File Dialog
Fixes #893
Checklist:
Where applicable: