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

Added Preferences UI widget #7105

Merged

Conversation

NicholasStenbeck
Copy link
Contributor

@NicholasStenbeck NicholasStenbeck commented Feb 7, 2020

Signed-off-by: Nicholas Stenbeck nicholas.stenbeck@ericsson.com

What it does

This package adds a UI view to Preferences. It is a work in progress and is meant as a reference to get community approval, so that we can continue work in this direction. All feedback is welcome.
Addresses #6985.

Features
  • Updates UI Similar to VS Code
  • Fuzzy search to filter preferences
  • Jump to category from navbar on the side
  • Revert to default option from context menu
  • Copy JSON code for preference from context menu

How to test

  1. Go to file > settings > Open Preferences (UI).
  2. Change a preference.
  3. Go to file > settings > Open Preferences (JSON).
  4. Confirm that the change is there.
  5. Try writing something in the Preferences UI search bar and make sure that the preferences are filtered properly.
  6. Click a category in the Preferences UI navbar and confirm that the Preferences UI widget scrolls to the right category.

Review checklist

Reminder for reviewers

@NicholasStenbeck NicholasStenbeck changed the title Added Preferences UI widget WIP: Added Preferences UI widget Feb 7, 2020
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.

Thank you for your contribution @NicholasStenbeck! 👍
There are unfortunately some build errors at the moment (CI is currently failing) which prevents the project from successfully verifying the functionality of the changes.

@vince-fugnitto vince-fugnitto added enhancement issues that are enhancements to current functionality - nice to haves preferences issues related to preferences labels Feb 7, 2020
Copy link
Member

@paul-marechal paul-marechal left a comment

Choose a reason for hiding this comment

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

Like @vince-fugnitto said, CI is red, and I wasn't able to build NicholasStenbeck:preferences-ui locally either. Not sure what went wrong.

@danieltomasku

This comment has been minimized.

@akosyakov
Copy link
Member

akosyakov commented Feb 10, 2020

Please make a PR as minimal as possible and avoid touching unrelated code, all new code should be aligned with our coding guidelines: https://github.com/eclipse-theia/theia/wiki/Coding-Guidelines Please ping when it is done, i.e. look at naming, styling, theming, check keyboard support, align it as much as possible with existing code based with minimal breaking changes then it would easy to accept it.

@akosyakov
Copy link
Member

@danieltomasku @NicholasStenbeck if you won’t have time to work on it, please let us know that someone can finish it up.

@akosyakov
Copy link
Member

akosyakov commented Feb 10, 2020

Important thing that we should use trees in the implementation if vscode does it, to avoid getting in the same maintenance troubles as we get with scm, i.e. trees will be improved to catch up with vscode and then if some feature is enabled for preference tree in vscode, it should be enabled the same way for Theia.

@NicholasStenbeck
Copy link
Contributor Author

NicholasStenbeck commented Feb 10, 2020

@akosyakov Thanks for the input! I've addressed some issues in the code for an update. Could you elaborate on the comment about using trees? As far as I know, we use pretty much the same method of populating the preferences widget as the current one. I didn't write that part of the package, but @SammyGP might have a better grasp of it.

@SammyGP
Copy link

SammyGP commented Feb 10, 2020

@akosyakov Thanks for the input! I've addressed some issues in the code for an update. Could you elaborate on the comment about using trees? As far as I know, we use pretty much the same method of populating the preferences widget as the current one. I didn't write that part of the package, but @SammyGP might have a better grasp of it.

I'm not sure how vscode does it behind the curtains but the way we implemented the tree we could make some minor changes to make it more visually aligned with how vscode does it.

The way its decoupled from the text view it should be safe to add features to the tree without to much trouble.

@marcdumais-work

This comment has been minimized.

@akosyakov

This comment has been minimized.

@NicholasStenbeck
Copy link
Contributor Author

I have pushed an update trying to address most issues mentioned by @akosyakov. I am planning on looking into removing the unnecessary files under preferences/ and adding a way to open a JSON-file with settings in the code editor from the preferences UI.

@akosyakov
Copy link
Member

It would be good to have follow-up issues for all points. Regarding context menu, ContextMenuRenderer makes sure that there is always only one context menu visible, if we work around such service will lose some logic.

Copy link
Member

@akosyakov akosyakov left a comment

Choose a reason for hiding this comment

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

Thanks for reverting irrelevant changes ❤️
Please have a look at comments below and #7105 (comment). Only core extension can style global elements, other extension must not.

packages/preferences/src/browser/preferences-decorator.ts Outdated Show resolved Hide resolved
--theia-settingsSticky-height: 100px;
}

html,
Copy link
Member

Choose a reason for hiding this comment

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

please get rid of styles to global element like html and body

@colin-grant-work
Copy link
Contributor

Many thanks for your comments. We will work to address them.

Co-authored-by: Nicholas Stenbeck <nicholas.stenbeck@ericsson.com>
Co-authored-by: Colin Grant <colin.grant@ericsson.com>
Co-authored-by: Kenneth Marut<kenneth.marut@ericsson.com>

Signed-off-by: Nicholas Stenbeck <nicholas.stenbeck@ericsson.com>
Signed-off-by: Colin Grant <colin.grant@ericsson.com>
Signed-off-by: Kenneth Marut <kenneth.marut@ericsson.com>
@kenneth-marut-work
Copy link
Contributor

@akosyakov

We've just pushed another update that has addressed your comments:

Regarding context menu, ContextMenuRenderer makes sure that there is always only one context menu visible, if we work around such service will lose some logic.

The context menu generation for the gear-icon and folder-tab has been refactored to use ContextMenuRenderer. We have noticed odd behavior in the core's electron-context-menu-renderer.ts where the values provided for the anchor are ignored, which causes the context menu to render at the location of the click, rather than the passed-in value. We will file an issue for this. This behavior is more noticeable for the folder-tab context-menu.

please get rid of styles to global element like html and body

Done

(nit) public is default, you don't need to type it

We have removed all mentions of public

it violates https://github.com/eclipse-theia/theia/wiki/Coding-Guidelines#no-bind-fn-in-event-handlers and break react caches. I've seen the same happening in other components.
please review all react components that you never use arrow functions, that's perf killer

We've extracted all arrow functions into class members where possible. We have used the React hook useCallback in functional components to prevent redeclaration of functions during rerenders.

(minor) https://github.com/eclipse-theia/theia/wiki/Coding-Guidelines#property-injection

In preference-tree-widget.tsx We have updated the constructor injection to property injection and moved all constructor logic to an @postConstruct function.
We noticed that this was also an issue in preferences-decorator.ts and have updated it as well. Please let us know if you would like this to be reverted.

Additionally we have looked at the coding-guidelines and updated any references to URI.displayName to use the LabelProvider.getName method instead.

@akosyakov akosyakov changed the title WIP: Added Preferences UI widget Added Preferences UI widget May 5, 2020
Copy link
Member

@akosyakov akosyakov left a comment

Choose a reason for hiding this comment

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

It works nicely for me.

I've noticed that the widget state is not preserved on reload like the search input. But It can be fixed as a follow-up issue. It could be also good idea to check whether this widget is not leaking by closing it, opening other widgets, triggering GC, taking a snapshot and checking whether everything related to preference UI is garbage collected.

(options: PreferenceFilterOptions, newScope?: Preference.SelectedScopeDetails) => this.updateUnderlyingData(options, newScope),
200
);
protected handleSearchChange = debounce((term: string) => this.updateDisplay(term), 100);
Copy link
Member

Choose a reason for hiding this comment

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

unused?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, this ended up going unused. Instead, the search event fire is debounced. Shall we remove it now before this gets merged?

}]
}] as [string, TreeDecoration.Data];
}));
if (preferences) {
Copy link
Member

Choose a reason for hiding this comment

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

what is a guard for? preferences are always defined

Copy link
Contributor

Choose a reason for hiding this comment

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

@NicholasStenbeck, I think you introduced this check. Can you shed some light here?

@akosyakov
Copy link
Member

@vince-fugnitto @lmcbout Would you have a look or we wait till tomorrow and merge?

@vince-fugnitto
Copy link
Member

@vince-fugnitto @lmcbout Would you have a look or we wait till tomorrow and merge?

I can have a look at the moment, we can merge tomorrow anyways and fix any issues/improvements we might encounter during the month.

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 great, it's a very nice improvement over the previous implementation!
I've opened some follow-up issues that we can tackle once the pull-request is merged :)

@akosyakov
Copy link
Member

@vince-fugnitto please merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement issues that are enhancements to current functionality - nice to haves preferences issues related to preferences
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants