Filtered tree is implemented for Marker Support Views.

[raghucssit]

Bookmarks View, Problems View and Tasks Views will have a search filter box.

see #4204

[raghucssit]

@iloveeclipse Initial implementation of filtered tree.. Please check if it looks good.

[Copilot]

Pull request overview

This PR adds a search-based filtering UI (a FilteredTree search box) to Marker Support Views (e.g., Bookmarks/Problems/Tasks) by wrapping the existing markers TreeViewer in a filtered tree and providing a marker-specific PatternFilter implementation.

Changes:

• Introduces a MarkersFilteredTree that hosts the existing MarkersTreeViewer while adding a filter text box.
• Adds MarkerPatternFilter to match markers against the values of all currently visible marker fields/columns.
• Externalizes the filter box initial text and adds the required bundle dependency for org.eclipse.e4.ui.dialogs.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/views/markers/internal/messages.properties	Adds an externalized string for the filter box initial text.
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/views/markers/internal/MarkerMessages.java	Adds the corresponding NLS field for the new message key.
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/views/markers/MarkersFilteredTree.java	New FilteredTree subclass that creates the markers-specific TreeViewer.
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/views/markers/MarkerPatternFilter.java	New PatternFilter that matches concrete markers based on visible column values.
bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/views/markers/ExtendedMarkersView.java	Replaces direct Tree creation with the new filtered tree and wires the initial text.
bundles/org.eclipse.ui.ide/META-INF/MANIFEST.MF	Adds org.eclipse.e4.ui.dialogs to Require-Bundle for FilteredTree/PatternFilter.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[iloveeclipse]

Is it possible to hide the filter line (like in the Error Log view)?

[github-actions]

Test Results

   858 files  ± 0     858 suites  ±0   47m 10s ⏱️ - 14m 3s
 8 138 tests +14   7 895 ✅ +14  243 💤 ±0  0 ❌ ±0 
20 316 runs  +42  19 662 ✅ +42  654 💤 ±0  0 ❌ ±0 

Results for commit aa5e173. ± Comparison against base commit 4cc7bb9.

♻️ This comment has been updated with latest results.

[raghucssit]

Is it possible to hide the filter line (like in the Error Log view)?

I will implement a preference for this like Error Log view. Which can be turned ON and OFF.

[iloveeclipse]

Functionality-wise looks good.

What I miss (as end user):

1. Preference whether the filter line should be initially shown or not in the Preferences -> General -> Initially show test filter in marker views (default: checked).
2. View description line is now inconsistent with the filtered view content. If the text filter line filtered the tree to show only a subset of markers, the view description still shows original number of shown markers. I believe this is "must have".
   See for example this, before:

and after

[vogella]

Looks like filtering happens after the marker limit. That would result in strange experience for the user. Please check if that is the case and fix or document it if that is the case.

[iloveeclipse]

Looks like filtering happens after the marker limit. That would result in strange experience for the user

Could you elaborate a bit, maybe with a screenshot of "strange" state?

[merks]

Just guessing, but if you limit to some small number, say 10, and the filter applies only to those 10 but not the actual 1000 in total, for example, then it would be pretty confusing and misleading.

[iloveeclipse]

Could it be we are not on same page?

The text filter is supposed to be applied on shown items after all possible filters are set, not to override whatever filters are set. It is not persisted and is supposed to be a quick and easy way to find something in a view.

See Errors view or Preferences page.

[vogella]

Just guessing, but if you limit to some small number, say 10, and the filter applies only to those 10 but not the actual 1000 in total, for example, then it would be pretty confusing and misleading.

That is a good use case. Also the view has IIRC some automatic grouping (was it 1000?) and loads only the the next list on request. So if I have 2000 warnings grouped and filter for "my error" I would expect to see all not not only the one in the first group.

I did not test it, no time for testing this change, just describing how I would expect it to work.

[iloveeclipse]

OK, thanks for clarification.

Let summarize here the main use case here & my understanding.

The problem with Problems/Tasks/Bookmarks view is that the filtering rules are not easy to change and need lot of clicks.
The intent for the proposed quick text filter was to quickly filter already shown items, without changing any complex filters defined.

So if user has some focused task, sees 100 problems on a project and "just" want filter by the package or file name or problem description, of course he could go to the "Filters" page, create new rule, define what should be shown/selected/which scope etc, and after ~20 clicks user will either give up or create a rule which he would need to disable few seconds later because he would want to restore "default" problems set visible for the project.

With the text filter, user can just type first letter of the package or file name or problem description and after typing 1-3 characters the task will be done. To see all problems again, "clear" the filter line - one click.

Now of course there could be 10.000 problems in the workspace and we only show some subset (for selected project), let say 100 problems in the tree. I would not expect that we now unset all the complicated filters user might have set in the view and start filtering only by the text. Suddently all 10.000 may be shown if text filter matches!

However, we also have two existing item limits in marker views which apply after all the filtering above is done.

1. First is the "hard" limit to the number of elements shown which is specified under the "Filters" dialog in the lower left corner:

2. Second is the general view element count limit defined in the Preferences -> General:

Similar like with the "complex" filter configurations above, I believe both limits must also remain, but the "quick" filter should be applied before these limits.

So the summary is:

• Don't touch any "filter configurations": "quick" filter should be applied after these filters
  -> already there
• After "filter configurations" are applied, apply "quick" filter before the item limits
  -> must be implemented