Option in chevron dropdown to display the most recently active editors at the top of the list
Add a toggle button near the filter text area in the chevron drop down to show the most recently overflowed editors at the top for easy access.
In the workbench, the chevron dropdown shows all editors along with the one’s that cannot fit in the main editor area.By default, these editors have an order sorted out using a comparator ie ascending order. But with so many editors open in the workbench, it is harder to quickly navigate and locate the editors that recently moved into the chevron due to overflow.
This change introduces a toggle button in the chevron dropdown that allows users to switch the view so that editors that most recently moved into the chevron appear at the top. When the toggle is activated, these recently overflowed editors are displayed first, making it easier for users to quickly access them. Clicking the toggle again restores the normal display order of the chevron, providing a simple way to alternate between the default and recently overflowed editor order.
The toggle button click will display only the elements that went inside to the chevron pop up; Those that are already visible/shown in the workbench are not shown in the chevron pop up using the toggle button .The purpose of this toggle button is to show only the elements that overflowed to the chevron and that too in the order of most recently added elements to chevron pop.
This is especially useful when many editors are open in the workbench and editors overflow into the chevron.
The change introduces :
- A toggle button to the chevron dropdown.
- Clicking the toggle displays editors so that the most recently active editor appears at the top.
- Subsequent toggles alternate between the default order and the
most recent editor firstorder. - Improves visibility when many editors are open in the workbench and editors overflow to the chevron at the same time.
The toggle button is shown below :
Video :
https://github.com/user-attachments/assets/4f929fdf-4b67-4fbb-90b5-59ce4ce410ae
Could you provide some reproducible steps to understand how the current behavior is changed / verify the new behavior? Screenshots or video would be a plus.
This pull request changes some projects for the first time in this development cycle. Therefore the following files need a version increment:
bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
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 patch
From e434edc2998b04b1cb7e072c065300f310f73d94 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Mon, 15 Sep 2025 20:06:22 +0000
Subject: [PATCH] Version bump(s) for 4.38 stream
diff --git a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
index 9d5e27c11e..249542c521 100644
--- a/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.e4.ui.workbench.renderers.swt/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.eclipse.e4.ui.workbench.renderers.swt;singleton:=true
-Bundle-Version: 0.16.900.qualifier
+Bundle-Version: 0.16.1000.qualifier
Bundle-Name: %pluginName
Bundle-Vendor: %providerName
Bundle-Localization: plugin
--
2.51.0
Further information are available in Common Build Issues - Missing version increments.
Test Results
3 018 files ±0 3 018 suites ±0 2h 14m 33s ⏱️ + 4m 23s 8 234 tests ±0 7 985 ✅ +1 249 💤 ±0 0 ❌ - 1 23 622 runs ±0 22 828 ✅ +1 794 💤 ±0 0 ❌ - 1
Results for commit f37be0fe. ± Comparison against base commit d0ffa3e6.
:recycle: This comment has been updated with latest results.
Could you provide some reproducible steps to understand how the current behavior is changed / verify the new behavior? Screenshots or video would be a plus.
I am working on a corner case with the current PR. It’s still a work in progress, and I’ll share a screenshot or video once it’s completed.
A very useful feature @elsazac, Thanks for working on this!
That's indeed a nice feature. I have to following comments
- The button changes the sorting from "default" to "mast recent used". I did not understand that without your text. First I thought that it sorts according to the alphabet and toggles between ascending and descending sort order. So the question is: What's the correct way to express in the UI what sort order is used.
- Also I don't know that the "default" sort order is.
- In your screencast the list get's shorter when you press the button. So why does it initially contain 5 entries and after clicking the button does it contain only 2 entries? I would not expect that that a sorting-button changes the number of entries in a list.
- the icon does not seen suitable, also from the name it seem to be a different purpose can we use something else?
Yes it is doable.
- The button changes the sorting from "default" to "mast recent used". I did not understand that without your text. First I thought that it sorts according to the alphabet and toggles between ascending and descending sort order. So the question is: What's the correct way to express in the UI what sort order is used.
- Also I don't know that the "default" sort order is.
Each tab inserted into a CTabFolder is assigned an index, and all these indexes are stored. A priority list with the indexes are maintained that changes dynamically depending on the user activity. When deciding which editors to keep visible and which ones to move into the chevron popup, the algorithm looks at this priority list. The most inactive editor among the currently visible ones is chosen to move into the chevron. Once that happens, its index is pushed down to the bottom of the stack. The next most inactive editor will sit just above it in the stack, and so on. This way, the tabs that you interact with most frequently are kept visible in the editor area, while the least active ones gradually get pushed into the chevron popup in the order of their inactivity.
https://github.com/eclipse-platform/eclipse.platform.swt/blob/35119f0f863cacbd4568ac7e9e604cdebc39845e/bundles/org.eclipse.swt/Eclipse%20SWT%20Custom%20Widgets/common/org/eclipse/swt/custom/CTabFolder.java#L3125-L3140
Apart from this, the chevron pop list is sorted using a comparator in ascending order. In the chevron popup, the editors are shown in two groups. The first group lists the editors that are currently hidden from the editor tab, and the second group lists the editors that are still visible on the tab. Inside each group, the editors are arranged in alphabetical order using a comparator. This way, you always see hidden editors first in the list, and then the visible editors, both sorted by their names.
- In your screencast the list get's shorter when you press the button. So why does it initially contain 5 entries and after clicking the button does it contain only 2 entries? I would not expect that that a sorting-button changes the number of entries in a list.
When there are many editors in the workbench, editors may overflow into the chevron pop at the same time; so it will be difficult to track the editors that most recently got hidden inside the chevron; so in a way i am trying to display the list of items in the chevron pop in the order in which they were most recently added into the pop up; the most recently added item goes to the top and so on;
Sorry that i forgot to mention about this in the PR description. My use case is to display only the elements that went inside the chevron pop up; Those that are already visible/shown in the workbench need not be shown in the chevron pop up using the toggle button (By default the chevron pop up contains all the editors opened in the workbench). The purpose of this toggle button is to show only the elements that overflowed to the chevron and that too in the order of most recently added elements to chevron pop. Thats why the list is short after the button is clicked.
The default behaviour of the list can be seen on clicking the toggle again
additonaly I have also just pushed an update to resize the table's height according to the new input size only for toggle button.
- Why do we need to play around with the actual input? That do not seems appropriate here a ViewerFiler/Sorter should be sufficient to to what ever is needed and would not require to modify/depend on
BasicPartList.
I wasn’t able to find anything similar to this. The input provided to the comparator also comes from getTableViewer. I couldn't understand completely. Could you please help clarify ?
Are there any outstanding concerns on this PR?
@laeubi Could you check and let me know if there are any outstanding concerns on this PR;
I have the feeling that we need to have a look at this from UX perspective before this can be merged. This should not be rushed in.