Option in chevron dropdown to display the most recently active editors at the top of the list

[elsazac]

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 first order.
• 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 :

Imp_Feature.mov

[iloveeclipse]

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.

[eclipse-platform-bot]

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.

[github-actions]

Test Results

 2 904 files  ±0   2 904 suites  ±0   2h 18m 40s ⏱️ + 8m 51s
 8 019 tests ±0   7 774 ✅ ±0  245 💤 ±0  0 ❌ ±0 
23 597 runs  ±0  22 815 ✅ ±0  782 💤 ±0  0 ❌ ±0 

Results for commit 4d32093. ± Comparison against base commit fbad80e.

♻️ This comment has been updated with latest results.

[elsazac]

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.

[SougandhS]

A very useful feature @elsazac, Thanks for working on this!

[laeubi]

This looks useful but there a two things that should be adjusted:

1. the icon does not seen suitable, also from the name it seem to be a different purpose can we use something else?
2. 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

[BeckerWdf]

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.

[elsazac]

1. 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.

[elsazac]

• 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.

[elsazac]

• 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

[elsazac]

additonaly I have also just pushed an update to resize the table's height according to the new input size only for toggle button.

[elsazac]

2. 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 ?

[elsazac]

Are there any outstanding concerns on this PR?