Improve Preference Filtering

[colin-grant-work]

Signed-off-by: Colin Grant colin.grant@ericsson.com

What it does

This PR aims to make the filtering of nodes in the preference widget more performant, and to smooth the way for feature enhancements like #8252.

At the moment, filtering and scope changing actually modify the root of the TreeModel, rather than maintaining the same root and conditionally rendering tree nodes based on various criteria. The performance fix in #7936 improves the situation, but at the cost of some flexibility in scoping preferences. This PR moves that functionality into a modified TreeModel implementation and uses an iterative strategy parallel to the doUpdateRows function in the TreeWidget to determine which nodes to display. This will make filtering more performant as well as more flexible in response to changing demands.

In addition, this PR refactors away some of the not-well-encapsulated code from #7105 by eliminating the PreferenceEventService and locating emitters and state tracking in the classes logically responsible for them.

Also fixes #8689

How to test

It should retain the functionality of #7105, #7773, #7764, and #7936.

In addition:

• Switching from User/Workspace to Folder scope or vice versa should be faster.

1. Open a multi-root or saved workspace.
2. Open preferences widget.
3. Switch between User scope and Folder scope.
4. Observe that the transition is quick, with little visible delay.

• Filter performance is improved.

1. Open preference widget
2. Type a text query in the search bar.
3. Observe that the filter is smooth, with little delay.

• Node visibility is preserved better.

1. Open preferences widget.
2. Scroll in editor until some preference in the section css.lint is at the top of the visible window.
3. Switch to folder scope.
4. Observe that the same preference is still visible. (Formerly this would have caused a scroll to top.)
5. Type the name of the preference in the filter bar.
6. Observe that the preference is still at the top of the screen. (Formerly a filter would have caused a scroll to top.)

• User and Workspace scopes are distinguished properly

1. Follow the steps outlined in Switching preference scopes in Preference UI does not properly populate tree #8689
2. Observe that the transition between User and Workspace scopes is managed correctly.

Further:

• Filter behavior can now be customized by modifying or overriding the passesCurrentFilters() method of the PreferenceTreeModel. This will mean that implementing enhancements like [Preference]: Add show modified settings menu-item #8252 is straightforward and performant.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[colin-grant-work]

@kenneth-marut-work, would you be willing to take a look at this?

[kenneth-marut-work]

In the third set of steps, I can confirm that typing the name of a preference (css.lint for example) scrolls to the correct preference. However, deleting the search query does not revert the editor back to its default (scroll-to-top) position, instead I am seeing a quick flicker and the editor returns back to the previously searched query.
In VSCode, if a query is searched for, and a preference is selected, clearing the search query reverts the editor to its default state.

[colin-grant-work]

Thanks for the suggestions, @kenneth-marut-work. I have adjusted the editor to scroll to top when the text filter is cleared, as you indicated, and cleaned up the code you commented on.

[akosyakov]

The tree model should not had such representation. Why do you need it here? Flat rows should be computed in the widget based on nodes' attributes like visible.

[colin-grant-work]

Because this tree - and the rules about what should and shouldn't be displayed - are common to the PreferenceTreeWidget and PreferenceEditorWidget it's more convenient and more efficient to simply share that data in a location accessible to both widgets. Formerly, a separate service generated a tree that was consumed by both widgets, but that required that the downstream widgets implement logic determining visibility separately, even though the requirements are (nearly) identical.

If your concern is with the checks made elsewhere in the standard TreeModel implementation that use TreeNode.isVisible to determine whether to select a node, the function that generates the rows here can be altered to modify the .visible field on each node appropriately.

[colin-grant-work]

@vince-fugnitto, @marechal-p, I've brought this up to date with master and it looks like the functionality is working well. If you wouldn't mind taking a look, I'd appreciate it - and I think it'll improve the preference system a fair bit 😄.

[vince-fugnitto]

@colin-grant-work I verified the changes with the provided use-cases and it works as described 👍

• preferences are generally much more responsive and seamless
• switching between preference scopes works well (user, workspace and folder)
• searching is more responsive, switching scopes with a search term present is also quick

[paul-marechal]

LGTM, although I wasn't able to notice a difference with performance. Is there something to specifically do or is my computer just fast enough to make the diff negligible?

[colin-grant-work]

Yeah, on fast machines it isn't really noticeable - but the bugfix for workspace-scoped vs. user-scoped preferences still applies. The main difference is that in the old code, the entire tree was reconstructed for any update, and now it's just being filtered in a style similar to the way nodes are hidden or shown on expansion.