Skip to content
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

Merged
merged 19 commits into from May 28, 2020

Conversation

okratitan
Copy link
Member

@okratitan okratitan commented May 24, 2020

Description:

This adds the ability to filter files in Fyne's File Dialog

Fixes #893

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

Where applicable:

  • Public APIs match existing style.
  • Any breaking changes have a deprecation path or have been discussed.

@okratitan
Copy link
Member Author

okratitan commented May 24, 2020

Tests added.

Copy link
Member

@andydotxyz andydotxyz left a 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?

dialog/fileicon.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
Copy link
Member

@andydotxyz andydotxyz left a 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

cmd/fyne_demo/screens/window.go Outdated Show resolved Hide resolved
cmd/fyne_demo/screens/window.go Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file_test.go Outdated Show resolved Hide resolved
dialog/fileicon_test.go Outdated Show resolved Hide resolved
dialog/fileitem.go Outdated Show resolved Hide resolved
@okratitan
Copy link
Member Author

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.

@okratitan
Copy link
Member Author

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?

Done. Thanks!

@andydotxyz
Copy link
Member

Tests added.

This is all looking good, but I can't find the tests you mentioned above?

dialog/file.go Outdated Show resolved Hide resolved
Copy link
Member

@toaster toaster left a 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.

dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/fileicon.go Outdated Show resolved Hide resolved
storage/uri_test.go Show resolved Hide resolved
@okratitan
Copy link
Member Author

Looks good!
Just a couple of nits, a question and a suggestion.

Thanks! I think I resolved all of those points.

dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated
save bool
callback interface{}
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member

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

Copy link
Member

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

dialog/fileicon.go Outdated Show resolved Hide resolved
Copy link
Member

@andydotxyz andydotxyz left a 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 {
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member

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

dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
dialog/file.go Outdated Show resolved Hide resolved
@andydotxyz andydotxyz merged commit 3cf392a into fyne-io:develop May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants