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

File dialog Enhancements #8748

Conversation

kenneth-marut-work
Copy link
Contributor

@kenneth-marut-work kenneth-marut-work commented Nov 12, 2020

Signed-off-by: Kenneth Marut [email protected]

new-file-dialog

What it does

Fixes: #2815

Addresses #2815 by improving the browser file dialog to allow for absolute path text input (with directory auto suggestion) in addition to the existing select input , also adds a new icon to "Navigate Upward" and fixes minor styling issue with navigation icon focus on enabled/disabled states. Tested on Linux and Windows.

How to test

  • Pull this branch and build, start in Browser Mode
  • Use the file picker, you should see 2 new icons, an up arrow and a 'edit' icon inside the select input
  • Test that the up arrow behaves as it would on a native file picker, also observe that the existing icons' appearance remain disabled even when they are focused (this is not the case on master)
  • Use the file picker as you normally would, navigate to various directories
  • Switch to the text-input method by clicking the 'edit' icon, you should be brought to the absolute path of where you left off
  • Navigate using text input (the input only allows absolute paths), the first matched (alphabetical order) directory will be auto suggested as you type. Press 'Tab' to accept the suggestion and press 'Enter' to navigate to the specified directory, 'Escape' will cancel your input .
  • Observe the backward/forward/up/home behavior, does it behave as expected?
  • Switch back to the select input by blurring the text input, clicking the icon, or by pressing escape. The input should revert to its original state.

Review checklist

Reminder for reviewers

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch 3 times, most recently from cf9db8b to fbc77c3 Compare November 13, 2020 18:58
@kenneth-marut-work kenneth-marut-work changed the title WIP: File dialog Enhancements File dialog Enhancements Nov 13, 2020
@kenneth-marut-work kenneth-marut-work marked this pull request as ready for review November 13, 2020 21:24
@colin-grant-work
Copy link
Contributor

colin-grant-work commented Nov 17, 2020

Very nice work, and a vast improvement over the current dialog. Some thoughts on the functionality:

  • there's an icon to get into editing mode, so I think maybe there should be an icon to get out of editing mode, too.
  • it might be nice to automatically transition to editing mode if the user has focused the select element and then starts typing.
  • alternatively, this may be a case for an input-with-select type interaction, where the user can easily use either mode without having to switch explicitly
  • I know we discussed the challenges involved, but I think it would be nice to have an auto-complete list / suggestions in edit mode.

@colin-grant-work colin-grant-work added enhancement issues that are enhancements to current functionality - nice to haves dialogs issues related to dialogs file dialog issues related to the file dialog ui/ux issues related to user interface / user experience labels Nov 17, 2020
@kenneth-marut-work
Copy link
Contributor Author

Thanks for taking a look @colin-grant-work. I agree with your requests on keeping the icon around in both input fields, and also adding automatic toggle to input mode when the user starts typing.
I think after some discussion, autocomplete functionality would be the preferable way to go since the current way this new feature works might not be too intuitive (file dialog automatically navigates as path is edited and resolved). I'll spend some exploring this idea.

@kenneth-marut-work kenneth-marut-work changed the title File dialog Enhancements WIP: File dialog Enhancements Dec 3, 2020
@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch 7 times, most recently from 7fd234e to ca0b37b Compare December 7, 2020 16:55
@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from ca0b37b to 6de2965 Compare December 7, 2020 17:43
@kenneth-marut-work
Copy link
Contributor Author

kenneth-marut-work commented Dec 7, 2020

Very nice work, and a vast improvement over the current dialog. Some thoughts on the functionality:

  • there's an icon to get into editing mode, so I think maybe there should be an icon to get out of editing mode, too.
  • it might be nice to automatically transition to editing mode if the user has focused the select element and then starts typing.
  • alternatively, this may be a case for an input-with-select type interaction, where the user can easily use either mode without having to switch explicitly
  • I know we discussed the challenges involved, but I think it would be nice to have an auto-complete list / suggestions in edit mode.

I've pushed a new revision that changes the input behavior to autosuggest the closest matched directory. Additionally I've addressed your comments above:

  • Added a icon to toggle back to 'select' mode
  • If dropdown is selected and user starts typing, the input field will transition to a the text input

@colin-grant-work would you mind taking another look when you have a chance?

@kenneth-marut-work kenneth-marut-work changed the title WIP: File dialog Enhancements File dialog Enhancements Dec 7, 2020
Copy link
Contributor

@colin-grant-work colin-grant-work left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working very nicely. I have a few minor comments about the code, but I think the functionality is all in place.

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch 2 times, most recently from 7e99b8c to a194c8c Compare December 21, 2020 20:14
@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch 3 times, most recently from b5c2cee to f707600 Compare January 4, 2021 17:28
@kenneth-marut-work
Copy link
Contributor Author

@vince-fugnitto thanks for the review, I have addressed your comments as follows:

nit: it should be placed under a new ## v1.10.0 entry, but I can always update it when preparing the changelog for the upcoming release.

I have updated the changelog with the next release 👍

Ideally we should not hardcode values (such as height and width) but rather calculate them

I have added variable names for new rules that I have introduced (where acceptable) and also updated some existing rules that were relevant

I believe this should be added to the changelog as a breaking change since downstream clients who extend the file-dialog will be broken. It is also a breaking change due to: https://github.com/eclipse-theia/theia/wiki/Coding-Guidelines#property-injection.

Thanks for pointing this out, I've made some slight adjustments to the file-dialog constructor and the location-renderer constructor to make the FileService a required constructor argument. I had originally made this optional (along with some conditional logic inside the location-renderer to avoid breaking changes (and slightly overcomplicate the logic), but I think it's best to simplify the logic and accept the breaking change. I've pushed this change and updated the changelog.

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes work very well, I tried multiple different use-cases and they all seem correctly handled. If possible I'd like someone else to review as well to see if I may have missed something during the review.

CHANGELOG.md Outdated Show resolved Hide resolved
@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from f707600 to 03528ba Compare January 11, 2021 14:06
@colin-grant-work
Copy link
Contributor

Pulled the code to have another look and found that I'm not getting any focus behavior as I tab through the buttons. There's a rule to that effect on master and in the new code:

.dialogContent .theia-NavigationPanel span:focus 
{
    outline: none;
    border: none;
    box-shadow: none;
}

But I'm not sure that's desirable? Perhaps this rule should only apply, like this one, when those buttons are disabled:

.dialogContent .theia-NavigationBack.theia-mod-disabled:focus,
.dialogContent .theia-NavigationForward.theia-mod-disabled:focus,
.dialogContent .theia-NavigationHome.theia-mod-disabled:focus,
.dialogContent .theia-NavigationUp.theia-mod-disabled:focus
{
    opacity: var(--theia-mod-disabled-opacity) !important;
}

Otherwise it looks and feels good. Fix the conflict in the CHANGELOG, and it should be good to go.

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from 03528ba to 09aa93f Compare January 21, 2021 23:13
@kenneth-marut-work
Copy link
Contributor Author

Pulled the code to have another look and found that I'm not getting any focus behavior as I tab through the buttons. There's a rule to that effect on master and in the new code:

.dialogContent .theia-NavigationPanel span:focus 
{
    outline: none;
    border: none;
    box-shadow: none;
}

But I'm not sure that's desirable? Perhaps this rule should only apply, like this one, when those buttons are disabled:

.dialogContent .theia-NavigationBack.theia-mod-disabled:focus,
.dialogContent .theia-NavigationForward.theia-mod-disabled:focus,
.dialogContent .theia-NavigationHome.theia-mod-disabled:focus,
.dialogContent .theia-NavigationUp.theia-mod-disabled:focus
{
    opacity: var(--theia-mod-disabled-opacity) !important;
}

Otherwise it looks and feels good. Fix the conflict in the CHANGELOG, and it should be good to go.

I've rebased and fixed the changelog, also made some modifications to the CSS to allow the toolbar elements to apply focus only when enabled. See below:
focusing

The focus is only applied when an enabled toolbar item is clicked or tabbed too. Note that the focus border stays visible until something else is focused (even on click). For accessibility reasons, this is nice, but it's not necessarily pretty.

@vince-fugnitto do you have any input on how to best handle focusing toolbar items in Theia? It seems that in some places focus is applied on click, and not in others. Also note that on master there is no focus behavior for the file dialog toolbar items.

@vince-fugnitto
Copy link
Member

I've rebased and fixed the changelog, also made some modifications to the CSS to allow the toolbar elements to apply focus only when enabled. See below:
focusing

The focus is only applied when an enabled toolbar item is clicked or tabbed too. Note that the focus border stays visible until something else is focused (even on click). For accessibility reasons, this is nice, but it's not necessarily pretty.

@vince-fugnitto do you have any input on how to best handle focusing toolbar items in Theia? It seems that in some places focus is applied on click, and not in others. Also note that on master there is no focus behavior for the file dialog toolbar items.

@kenneth-marut-work @colin-grant-work I'm agree with you that the outline is not necessarily pretty but for accessibility when tabbing it is likely the best solution, I just wish the icons were all of equal size (square) similarly to vscode:

toggle.mov

As for onClick, I'm thinking we can do something similar to the toolbar items by providing visual feedback ('bounce') to end-users when a toolbar item is clicked (but not the outline), similarly to #6099. Let me know if this is an interesting proposal.

feedback.mov

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from 09aa93f to 3a81f56 Compare January 22, 2021 17:11
@kenneth-marut-work
Copy link
Contributor Author

@vince-fugnitto thanks for the suggestions, both are great ideas. I went ahead and pushed a change that includes:

  • 'bounce' effect on clicking an active item
  • Evenly sized focus borders
  • Focus only on keyboard access (using the focus-visible rule)

new-behavior

@colin-grant-work and @vince-fugnitto let me know what you think. I know that there is still room to improve the file dialog, but I don't want to go too far beyond the scope of this MR 🙂

@vince-fugnitto
Copy link
Member

@colin-grant-work and @vince-fugnitto let me know what you think. I know that there is still room to improve the file dialog, but I don't want to go too far beyond the scope of this MR

I think it looks much better, happy the suggestion was useful! 👍 I'll perform another round of review just to be sure that everything works as intended.

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good to me 👍

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from 3a81f56 to f3191b0 Compare January 26, 2021 22:41
const latestInput = this.pendingResolvedDirectories.get(directoryToResolve)?.input || '';
const childDirectories = children.filter(child => child.isDirectory)
.map(directory => `${directory.resource.path}/`)
.sort();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do they come out of (alphabetical) order to begin with? Usually fs.readDir returns things in alphabetical order, but perhaps resolve behaves differently.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, I've removed .sort()

@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from f3191b0 to d47c8ff Compare February 10, 2021 20:03
@kenneth-marut-work
Copy link
Contributor Author

Thanks for the comments @colin-grant-work. I've made some changes that address your issues. I've tested in both low and high latency

@colin-grant-work
Copy link
Contributor

The new changes look good to me 👍

- Add text input to locationList Renderer
- Add 'navigate upward' icon
- Fix icon focus behavior when disabled

Signed-off-by: Kenneth Marut <[email protected]>
@kenneth-marut-work kenneth-marut-work force-pushed the feature/file-dialog-enhancements branch from d47c8ff to 4cd3cde Compare March 1, 2021 18:54
Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I verified the changes and they work really well 👍

I found a future improvement which can be made for both macos and linux. The idea to support ~ as a replacement for the user's home when editing the path (which is something that is supported in the native dialog).

@kenneth-marut-work
Copy link
Contributor Author

I verified the changes and they work really well 👍

I found a future improvement which can be made for both macos and linux. The idea to support ~ as a replacement for the user's home when editing the path (which is something that is supported in the native dialog).

Thanks for the review, I'm going ahead with the merge and I'll create an issue regarding the ~ suggestion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dialogs issues related to dialogs enhancement issues that are enhancements to current functionality - nice to haves file dialog issues related to the file dialog ui/ux issues related to user interface / user experience
Projects
None yet
Development

Successfully merging this pull request may close these issues.

As a user I would like to open a workspaces by copy pasting the desired FS path
4 participants