Add Options to hide tab icons and and show full text in view area

[praveen-skp]

Issue: #735

Currently, the UI/UX for Eclipse views does not scale properly when a perspective contains a lot of views. The current solution for scaling views in Eclipse is to provide lots of different perspectives and use them to group the views. If only a limited number of views are visible it means that the whole title of each view is visible and the usability is good but if the number views increase significantly then the following issues occur:

1. The tab titles get so small that only the view icons are visible. This means users have to learn all icons which is not ideal.
2. The overall look&feel of the IDE feels cluttered.
3. Lots of view icons draw attention away from the editor area. However, when playing the role as a classic IDE for a programming language the editor area should be most prominent.

Changes:

• As all three points are based on personal preferences, new eclipse preferences has been added for handling Tab icons and titles in View areas by providing two options
  a. Always show full titles
  b. Hide icons

• Corresponding change to CTabRendering to handle these preferences and render the image and text for tabs in view areas accordingly

  • As a pre-requisite, added property "showSelectedImage" to CTabFolder : Pull request

• Added two CSS properties handler

  • CSSPropertyTabTextMinimumCharactersSWTHandler: An swt property to set the minimum characters for CTabFolder
  • CSSPropertySelectedImageVisibleSWTHandler: An swt property to set if the selected tab's image should be visible or not

This a prototype and would like to get feedback

[github-actions]

Test Results

0 files   -      852  0 suites   - 852   0s ⏱️ - 1h 54m 57s
0 tests  -   7 328  0 ✔️  -   7 176  0 💤  - 152  0 ❌ ±0 
0 runs   - 23 130  0 ✔️  - 22 628  0 💤  - 502  0 ❌ ±0 

Results for commit 85e92b5. ± Comparison against base commit 81e7679.

[albertmink]

@praveen-skp can you provide a screenshot from the whole IDE, not only a view area (with hidden icons)? Such an example helps to explain the addressed change in overall look&feel

[praveen-skp]

Screenshots for the whole IDE:

[iloveeclipse]

Few things:

• if no icons shown for views, it would be nice to show active view with an icon
• Instead of hiding (small) icons and showing only (long) view titles, why not add an option to show no view titles. In this case, views will be shown by icons and only active one will have icon and title. That will save place and clearly set focus on what is active in each view stack.

[shubhamWaghmare-sap]

@iloveeclipse

Few things:

• if no icons shown for views, it would be nice to show active view with an icon

This is already technically possible using the SWT API. We can consider incorporating this as a future update if required.

On a side note, we also observed that showing the icon (only) for active view could potentially increase screen flickering, as the text for the tabs would be moved each time a tab is switched. Thus the impact on user experience should be evaluated before proceeding.

• Instead of hiding (small) icons and showing only (long) view titles, why not add an option to show no view titles. In this case, views will be shown by icons and only active one will have icon and title. That will save place and clearly set focus on what is active in each view stack.

Showing only icons is also technically possible and here is what it would look like:

We had contemplated this option and consulted with UX experts who indicated the following potential issues related to accessibility:

• It would be difficult for users to identify a tab just by the icon.
• Users would need to learn/remember the icons for different views, which is not ideal.
• Figuring out if a view is already open or not would not be a quick task.
• Precise mouse movements would be needed to hit the required tab.

Moreover, the intention behind the change was not on saving space but to keep the focus only on editor area which is the main actor in IDE. Thus the icons for all tabs from the view stack (supporting actors) are to be hidden, which might draw attention away from the editor area otherwise.
Also the idea is to align the look & feel with other IDEs out there like VS code, where tabs in view stack always show full texts but no icons, which gives a cleaner look.

[BeckerWdf]

Regarding "only show icons": It looks much more cluttered compared to the current state (Icon and Text). I have the feeling this is a move into the wrong direction.

[humphreygao]

I think it is a good idea, you can provide this 2 options(show full titles and hide icons) and let users to decide. And it would be good to always show editor tabs' full name especially when you open many editors.

[HeikoKlare]

Thanks for the proposal. I really like it.

I have some minor code style comments and one general remark:
I am wondering whether it may be useful to allow the configuration for each part stack (not necessarily as part of this PR but as a future extension). You could then define the visualization that fits most for one specific stack of views. E.g., you may have one stack of views that you usually distinguish by their (full) names, so that you want to hide the icons and always show the full texts, and you may have a (horizontally) small stack of views of which you know well their icons, so that only showing the icons may be perfect for that stack (this would require to have the option of only showing icons as proposed in #1071 (comment)). This would relieve you from deciding about the visualization of tab items for the whole workbench. As a concrete example, in a "usual" perspective setup such as the Java perspective, displaying the full names of the tabs may be useful for the views in the stack at the bottom of the workbench window, while it may not be desired for the stack at the right side of the workbench window, as the names of one or two views can easily require all the available space for the tabs.
As an RCP application provider, you could even provide perspectives that are predefined accordingly. The preferences could then be used to define the initial behavior of newly created stacks.

[BeckerWdf]

I think it is a good idea, you can provide this 2 options(show full titles and hide icons) and let users to decide. And it would be good to always show editor tabs' full name especially when you open many editors.

I would try to keep the number of configurations options as small as possible. Let's start with the current implementation of this PR. Let's see that what kind of feedback we get. We can add more configuration options later on. But pls. let's start simple.

[HeikoKlare]

One further thing I forgot to mention: when removing the icons, it becomes really hard to see where one tab item ends and the next begins, as there are no borders between them. With the icons enabled, you directly see where the items starts. So maybe there should be some kind of small separator to see where a new tab item starts?

[BeckerWdf]

One further thing I forgot to mention: when removing the icons, it becomes really hard to see where one tab item ends and the next begins, as there are no borders between them. With the icons enabled, you directly see where the items starts. So maybe there should be some kind of small separator to see where a new tab item starts?

You are right. But is it necessary to see where "inactive" view tabs start and end exactly. If you want to bring it to the top you simple click on the text. Pls. look how VsCode does it - I also don't see separators there...

[HeikoKlare]

You are right. But is it necessary to see where "inactive" view tabs start and end exactly. If you want to bring it to the top you simple click on the text. Pls. look how VsCode does it - I also don't see separators there...

That's true. My concerns are not with respect to where the tab starts and ends exactly but with respect to identifying the text that belongs together, i.e., to a single tab, at all. The difference I see in comparison to VS Code is the size of the space between the texts. Maybe we could increase the padding to have a bigger difference between the size of a whitespace and the size of the space between tabs, so to make it easier to find the individual tabs?

For example, in the following tab folder, I find it quite hard to see where tabs start and end. It takes some time (or knowledge) to identify whether there are tabs "CSS" and "Scratch Pad" or whether it is a single "CSS Scratch Pad". Either I know that, I have to take a deep look for quite some time to distinguish the space between tabs and the whitespace between words, or I have to hover with the mouse to see the highlighting.

In VS Code, I find it fairly easy to identify the individual tabs.

[BeckerWdf]

Maybe we could increase the padding to have a bigger difference between the size of a whitespace and the size of the space between tabs, so to make it easier to find the individual tabs?

Good idea.

[shubhamWaghmare-sap]

Maybe we could increase the padding to have a bigger difference between the size of a whitespace and the size of the space between tabs, so to make it easier to find the individual tabs?

Earlier the padding was only added to the selected tab.
Now the padding is uniformly added across all tabs (selected and unselected) where tab icon would not be visible.
This is how it looks now and the change is done in eclipse-platform/eclipse.platform.swt#785

For example, notice the significant space between Type Hierarchy tab and CSS Scratch Pad tab.

[HeikoKlare]

With some further adaptations of the required SWT change eclipse-platform/eclipse.platform.swt#785, this looks good to me.

I would be in favor of even larger paddings when no icons are shown, as also mentioned in the SWT PR (eclipse-platform/eclipse.platform.swt#785 (review)), which could look like this:

But that's a matter of personal preference.

[HeikoKlare]

@shubhamWaghmare-sap Was it intended that the minimum number of characters shown for tabs now is 1 in case "always show full titles" is not enabled? That way it seems to become impossible to navigate between source code files 😇

[thomasritter]

Just tested the iBuild. In general it looks much cleaner. We should think about making the option "Always show full titles" the default, in the future. When the icons are visible everything looks great. Once I switch off the icons the tab title spacing is not ideal when the tab is in focus, in my opinion. When I look at the titles it feels like they are not bound to the beginning of the tab. They are leaning to the right. The reason for this is that the titles are not aligned in the center. I would recommend we align them. The left red box should be flush with the beginning of the tab. See screenshot:

[shubhamWaghmare-sap]

@shubhamWaghmare-sap Was it intended that the minimum number of characters shown for tabs now is 1 in case "always show full titles" is not enabled? That way it seems to become impossible to navigate between source code files 😇

@HeikoKlare It seems that before this change, the minimum number of characters for tabs "in view areas" was always 1. Also the newly added preferences do not affect the "editor area".
The below screenshot corresponds to a commit before this change, where, we have a chevron in "editor area" and only 1 character visible in "view area". (same is the case when "always show full titles" is not enabled )

So,

1. Do you observe this issue in the Editor area or in View area?
2. If you observe it in View area, is it expected to have a higher number for default minimum characters and have chevron instead ?
3. Is there a reason to suspect it to be a regression?

[HeikoKlare]

Maybe I erroneously related the changed behavior to this PR. For me, the behavior changed in the editor area. This is how it looks like:

Behavior for the view area is fine for me, as it has been like this before, and you can usually also distinguish views by icons (in comparison to files in the editor area, where the single first letter does not help).

The changed behavior for the editor area (assuming that it is related to this PR) actually is a regression for me, because for me it is now ususable without "always show full titles" activated.

Once I switch off the icons the tab title spacing is not ideal when the tab is in focus, in my opinion. When I look at the titles it feels like they are not bound to the beginning of the tab. They are leaning to the right. The reason for this is that the titles are not aligned in the center.

The SWT implementation for tab folders with disabled icons centers the text (like, e.g., VS code does). @thomasritter What do you mean by "leaning to the right"? The text actually should be centered. And making it left aligned will look strange, as then you have a huge space to the right as a separator to the next tab.

[thomasritter]

@HeikoKlare If the tab is selected the area in which the text should be aligned runs from the left edge to the right X. See this screenshot. I added the black box. You can see that the text is not centered. It is too much to the right.

[HeikoKlare]

Thanks for clarification! I got it. The problem is that centering is performed w.r.t. the "text area", but the tab also has a padding on its own. We have to fix that in SWT.

[thomasritter]

Ok, here a fake screenshot in which I fixed it manually and centered the text. This is how I would expect it to look like.

[HeikoKlare]

Seeing the fake screnshot: do you really think that it looks better that way? It seems like my eyes expect the text to be centered "within the padding" of the tab, like in the current behavior. So the current behavior actually looks more "natural" to me than the proposed one.

[thomasritter]

@HeikoKlare In order to get away from "feeling" and more towards empirical data I looked at the most widely used tab design and measured how they position the content (text + icon). Have a look at this diagram:

As you can see, almost all tab titles are leaning slightly to the left side of the tab. Only Intellij uses a centered design. As most humans read from left to right this makes a lot of sense to me. The content needs to feel anchored to the left side. This is not the case with the current design. My proposal would be to follow the padding of the Eclipse tab with icon or at least do not have more padding in the front than after the (x) button.

By the way thanks for sending me down this rabbit hole :) Was interesting to realize that the browser vendors are using very similar spacing for their tabs.

[HeikoKlare]

Thanks for collecting that data, @thomasritter!

You compare the iconless tab design with other applications using icons in tabs. The reason why left alignment and small paddings work when using icons is that the icons work as a separator between individual tabs, which allows you to easily find the start/end of a tab.

When using an iconless design, you need to apply larger paddings to be able to distinguish tab start/end from whitespaces between words in a single tab (see my previous comment). From my point of view, using paddings as separators only works with centered text. Left-aligning the tab text looks really weird:

To support this with some empirical data: VS code does it the same way (in the screenshot, the "Terminal" tab is moved between the "Output" and "Debug Console" tabs to show where VS code puts the border):