Show icon for view tabs when not minimized
Description
View tabs (e.g. Projects, Output, Watches, etc) only show their icons when they are minimized (rendered by FlatSlidingButtonUI). It would be nice, at least for platform applications, to have a setting to allow painting the icon when they are in normal mode (rendered by FlatViewTabDisplayerUI).
Use case/motivation
When there are a number of tabs open it is easier to find the right one when icons are displayed rather than just text. Eclipse and IntelliJ using icons in their tabs.
Related issues
No response
Are you willing to submit a pull request?
No
I've added contribution welcome. Might need some rethinking of the tab displayer structure.
Realistically, enhancements of the platform that add complexity, but are not desired in the IDE itself, probably require direct or indirect investment in their development and maintenance. A pull request would offer a starting point.
Somewhat open question whether this is a desirable option in the IDE itself?
Somewhat open question whether this is a desirable option in the IDE itself?
I'm not sure of the history in the IDE regarding why the icons aren't shown, but unless there's a good reason I would advocate for the icons to be always displayed.
Realistically, enhancements of the platform that add complexity, but are not desired in the IDE itself, probably require direct or indirect investment in their development and maintenance.
We had originally thought to override FlatViewTabDisplayerUI and draw the icon in our own UI delegate, but ran into a couple issues:
FlatViewTabDisplayerUIis public, but is not in a publicly available package (at least not to our module)paintTabContentpaints a busy icon and the text, so overriding it would not (easily) allow for painting the icon between the busy icon and the text where it would logically belong.
The simple approach might be to introduce a paintTabIcon protected method in AbstractViewTabDisplayerUI that could be called from paintTabContent or pull out the busy icon painting to a separate method.
It looks like there are quite a few subclasses of AbstractViewTabDisplayerUI, so either approach would require some refactoring of all those as well to handle it completely.
A more involved approach would be to refactor the view tabs to be rendered similar to the editor tabs using a rendering component for each tab rather and providing the TabData instance rather than a tab index. That might allow for more reuse of the generic renders across the various different tab views as well.
We have our own fork of the platform and will probably just add icon rendering directly to FlatViewTabDisplayerUI in the short term as we don't have the resources for a larger refactoring and only use the FlatLaf UI anyway.
I'm not sure of the history in the IDE regarding why the icons aren't shown, but unless there's a good reason I would advocate for the icons to be always displayed.
Yes, I don't know why historically this distinction was made, but I also personally prefer it like that and would not want to adopt it in our platform applications. I can see why it would be a useful option.
We have our own fork of the platform and will probably just add icon rendering directly to
FlatViewTabDisplayerUIin the short term as we don't have the resources for a larger refactoring and only use the FlatLaf UI anyway.
I'll leave this open, but at the same I'll say that there is a small team of people here working on development and maintenance. Those of us primarily here because of the platform like myself are fewer. Enhancements to the platform alone do get in, but they need to not add to the maintenance overhead and be contributed by those who have a requirement for them. Feature requests without a PR offer are likely to just sit here unless someone else takes an interest.
Personally I would like to see Siemen's advertised "Upstream First" approach apply to the NetBeans platform. You and we stand to benefit more from reducing (or even removing) the need for you to maintain a fork.