Implement filter-based TableViewer as a counterpart to the FilteredTree #2567
Conversation
|
See eclipse-pde/eclipse.pde#1497 for a potential use-case. Note: This also works with virtual tables: recording.webm |
|
Did you also consider the FilteredTree from the E4 package? This way this class could also be used in pure e4 rcp apps. |
Not for the time being. And looking at it, it really is just a copy-paste of the E3 class. So ideally, I'd like to get some feedback on the current implementation before I repeat the same for the E4 one. |
|
IIRC we copied it and removed the E3 reference (IIRC the help system) and added the option to enable/ disable the filter at runtime. If it's functionality is the same I think we should only add one class ( to the E4 package so that it can be used in ide and E4 RCP). |
|
Is there an E4 counterpart for the TextMatcher? Would it perhaps make sense to move it to e.g. |
I'm not aware of an e4 counterpart. Would be great to move this to an API package that everyone can use. |
By the way it is confusing to talk about E3/E4 "counterparts" here as these are completely independent from the used technique (e.g. it does not require any DI at all nor does it requires E3 extension points). So making the class somewhere more generic available would be beneficial and as it is a final class let the "old" extend the "new" should work flawlessly. |
| * | ||
| * @since 3.135 | ||
| */ | ||
| public non-sealed class FilteredTable extends AbstractFilteredViewer { |
There was a problem hiding this comment.
Just an idea but maybe having a JFace FilteredTableViewer could be a better place for this so it can be used even outside of Eclipse Platform in SWT/JFace Applications.
Maybe even one can abstract the whole thing to use a StructuredViewer then it can be used with any table/tree/grid ...
There was a problem hiding this comment.
Just an idea but maybe having a JFace
FilteredTableViewercould be a better place for this so it can be used even outside of Eclipse Platform in SWT/JFace Applications.
The FilteredTable/FilteredTree depend on the WorkbenchJob/BasicUIJob, so there is an inherent dependency to the E3/E4 workbench, which effectively prevents them to be moved to JFace.
Though it might be possible to specify a plain Job in the abstract base class and then have the implementations provide their respective instances... This would at the very least avoid the code duplication.
Maybe even one can abstract the whole thing to use a
StructuredViewerthen it can be used with any table/tree/grid ...
The base class only specifies a ColumnViewer but one could probably go even lower...
There was a problem hiding this comment.
I thought about it a little bit more and in general, it still holds that the dependency to the Eclipse runtime prevents those filters to be moved to org.eclipse.jface. However, it would be possible to move them to e.g. org.eclipse.jface.text. I'm certainly not a huge fan of having a separate copy specifically for pure E4 applications. wdyt?
It is not, new elements which can be used in E3 and pure E4 must of have dependencies to the old workbench implementation, as the e3 initialization code does not run in pure E4. |
Them mentioned class do not have any dependencies to a (E3 or E4) workbench as far as I can see... |
ptziegler
force-pushed
the
filtered-table
branch
from
5ccbcda to
763212e
Compare
|
In principle, the TextMatcher class should work regardless of whether an E3 or E4 workbench is used. I've therefore moved the class from org.eclipse.ui.workbench to org.eclipse.jface.text. The same is true for the abstract base class I've created for the FilteredTable/Tree, so that I don't have to duplicate the implementation for the E4 classes. Though I still have to think about how to best adapt the E4 classes... |
|
This pull request changes some projects for the first time in this development cycle. An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch. Git patchFurther information are available in Common Build Issues - Missing version increments. |
Interestingly enough I found we already have |
ptziegler
force-pushed
the
filtered-table
branch
from
f36df7f to
0835105
Compare
Given that this is an internal class in can be freely moved to wherever it's needed. But as far as I know, it's only used for UI stuff, so I don't think it makes sense to move it out of the UI repo. |
|
I've tought about this PR a little bit more and I'd like to split it into three parts:
|
I have probably oversaw something, but can you please explain why this is necessary? |
|
@ptziegler with the Equinox change in, can you update this PR? |
The functionality of the TextMatcher has been integrated in the StringMatcher class from the Equinox bundle, which allows this class to be used without a dependency to the Eclipse UI bundle. Note: To get the same behavior as the TextMatcher, one needs to call matchWords() instead of match(). Furthermore, the pattern needs to be trimmed explicitly, where needed. Contributes to eclipse-platform#2567
The functionality of the TextMatcher has been integrated in the StringMatcher class from the Equinox bundle, which allows this class to be used without a dependency to the Eclipse UI bundle. Note: To get the same behavior as the TextMatcher, one needs to call matchWords() instead of match(). Furthermore, the pattern needs to be trimmed explicitly, where needed. Contributes to eclipse-platform#2567
The functionality of the TextMatcher has been integrated in the StringMatcher class from the Equinox bundle, which allows this class to be used without a dependency to the Eclipse UI bundle. Note: To get the same behavior as the TextMatcher, one needs to call matchWords() instead of match(). Furthermore, the pattern needs to be trimmed explicitly, where needed. Contributes to #2567
This moves the duplicate code of the E3.x and E4.x based FilteredTree class and moves it into an AbstractFilteredViewerComposite class located in the JFace component. The base class is currently only implementing a tree-based filter, but is structured in such a way that it can easily be extended to also support e.g. table-based filters. Due to being unused, the following fields and methods have been marked as deprecated: - filterToolBar - clearButtonControl - updateToolbar(boolean) Contributes to eclipse-platform#2567
This moves the duplicate code of the E3.x and E4.x based FilteredTree class and moves it into an AbstractFilteredViewerComposite class located in the JFace component. The base class is currently only implementing a tree-based filter, but is structured in such a way that it can easily be extended to also support e.g. table-based filters. Due to being unused, the following fields and methods have been marked as deprecated: - filterToolBar - clearButtonControl - updateToolbar(boolean) Contributes to #2567
ptziegler
force-pushed
the
filtered-table
branch
2 times, most recently
from
e78984c to
121a156
Compare
ptziegler
changed the title
| <?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||
| <component id="org.eclipse.e4.ui.dialogs" version="2"> | ||
| <resource path="src/org/eclipse/e4/ui/dialogs/filteredtree/FilteredTable.java" type="org.eclipse.e4.ui.dialogs.filteredtree.FilteredTable$NotifyingTableViewer"> | ||
| <filter id="571473929"> | ||
| <message_arguments> | ||
| <message_argument value="TableViewer"/> | ||
| <message_argument value="NotifyingTableViewer"/> | ||
| </message_arguments> | ||
| </filter> | ||
| </resource> | ||
| </component> |
There was a problem hiding this comment.
Not sure how to handle the API warning because the UI bundles are implementing the JFace viewers directly (just like the existing FilteredTree does).
Reason being that the filter cache is not properly cleared when e.g. a node is no longer filtered. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=187200
ptziegler
force-pushed
the
filtered-table
branch
from
121a156 to
e07227b
Compare
Projects such as PDE currently use the FilteredTree in combination with a child-less ITreeContentProvider to simulate a filtered table. This approach brings a big performance overhead, as the tree still has to handle functionality such as expansion and contraction of the (flat) tree structure which especially large trees/tables causes a significant overhead.
ptziegler
force-pushed
the
filtered-table
branch
from
e07227b to
1354ba4
Compare
|
That should hopefully be all. I've rebased everything and adapted the code to use the new API introduced in previous commits. |
|
Could the new FilteredTable also live in the e4 bundle? |
Projects such as PDE currently use the FilteredTree in combination with a child-less ITreeContentProvider to simulate a filtered table. This approach brings a big performance overhead, as the tree still has to handle functionality such as expansion and contraction of the (flat) tree structure which especially large trees/tables causes a significant overhead.