[NETBEANS-5928] Proposed improvements to FlatLAF tab components+borders/margins

[eirikbakke]

In a previous PR ( https://github.com/apache/netbeans/pull/2967 ), the tab components in the NetBeans window system were redesigned and modernized for the Windows LAF. This PR ports related tabcontrol improvements back into FlatLAF, and proposes a similar tab style for FlatLAF. See the attached screenshots.

(This PR is split into a series of commits which will be easiest to review one at a time.)

The proposed style, compared to the current FlatLAF style, makes the selected tab look like an actual "tab" with an actual rectangular border around it, while keeping the much simpler "separators only" look for unselected tabs. The proposed style also tightens up vertical space significantly, like in other LAFs. See the attached screenshots. The new tab controls work well on all HiDPI scaling levels, and on all platforms (Windows, Linux, MacOS).

Advantages of the proposed tabcontrol style:

• Other applications that have tabs as part of their window system still tend to render at least the active window system tab as an actual "tabs", e.g. Chrome, Excel, Photoshop, Unity.
• Personally, I find it hard to orient my eyes around the old FlatLAF tab style; the drawn selected tab seems to fix this. (Hard to explain in a fully objective way!)
• The tab content areas (contents of editor, projects pane, navigator pane etc.) has borders around them, so it is logical that the border continues around the tab that is associated with them.
• Conserve vertical space. Modern monitors have tended to become wider but not taller. With e.g. 2x HiDPI scaling (as on all MacBooks), there may actually be fewer logical pixels available in the vertical direction than on older laptop screens.

This PR also removes an extraneous border around the editor area, and introduces a little bit of extra space in the toolbar area.

I've been using FlatLAF as the default LAF on Linux for my NetBeans Platform application. It handles HiDPI scaling very well, and it's getting really solid--thanks to @DevCharly for all his work on it!

Before/after screenshots, FlatLAF Light:

Before/after screenshots, FlatLAF Dark:

[Chris2011]

Cool, thx @eirikbakke. I hope I can identify my current opened tab better with this approach, because I use colorful tabs and there it is hard to find the current tab.

[neilcsmith-net]

I don't like this change - it's inconsistent with the standard FlatLaf tab look, and across the different tab positions. (I'd also probably revert this in my own platform applications).

That's not to say some improvements to visibility of active tabs and reducing vertical space aren't a good idea. But prefer @DevCharly look at how this works consistently across FlatLaf.

[Chris2011]

Could this be behind an option? @eirikbakke

[eirikbakke]

The "controversial" changes are all controlled by the settings in FlatDarkLaf.properties/FlatLightLaf.properties, so it's easy to restore the old look, or experiment with new variations. If preferred, I could modify this PR to keep the old look, but just add the new internal configuration options (+other smaller improvements) for now.

[Chris2011]

The thing is, some wants the new, like me some not. If this is the thing, we need to change it via options and I prefer that to make this via Tools -> Options -> Appearance -> FlatLaf.

[eirikbakke]

I'd be happy to make it into an option in the GUI, too.

I think FlatLAF fills three different roles in the NetBeans world--(1) as an "alternative" LAF that has its own distinct look and does not try to look like native apps, (2) as a "dark" LAF and (3) as the LAF that has best support for HiDPI screens on Linux. For role (1), the old look makes sense, but for roles (2) and (3), there may be people who actually want the IDE to look like a standard desktop app, but with dark mode or Linux HiDPI support. These different roles might justify having an explicit option that the user can select.

[neilcsmith-net]

I think the usability issues (which I understand) and the 3 roles can still be met without making tabs look inconsistent across the UI. Hence requesting @DevCharly thoughts on that point. An option if we have to, but good not to have to!

As for "look like a standard desktop app", and given point (3), most of the standard apps on Ubuntu have a similar flat tab look. As does new macOS I think.

[eirikbakke]

On the inconsistency between regular tabs and window system tabs, I also considered the option of changing the regular tabs. But that would require a change in the FlatLAF library, which is outside the NetBeans codebase.

It would be interesting to gather screenshots from tab styles in different apps. I don't have the latest MacOS or Ubuntu available, but here are a few:

Windows:

Photoshop:

Chrome:

Unity:

IntelliJ:

Microsoft Edge:

Visual Studio 2022 Preview (blurry screenshot from a YouTube video...):

Eclipse:

Maya:

Blender:

Tableau:

PowerBI:

Excel:

Thunderbird:

Bloomberg Terminal:

AWS Console:

I think the existing FlatLAF style looks most like IntelliJ.

[eirikbakke]

I don't like this change - it's inconsistent with the standard FlatLaf tab look, and across the different tab positions.

@neilcsmith-net Actually, for the future discussion--could you clarify what you meant here? I assume you mean the difference between the window system tabs and the regular JTabbedPane? (E.g. the sub-tabs in the "Output" pane?)

Or are you referring to the difference between the "view" tabs ("Projects/Files/Services") and the "editor" tabs? (These differences are more minor, but intentional, and were arrived at after a lot of experimentation.)

[neilcsmith-net]

I assume you mean the difference between the window system tabs and the regular JTabbedPane? (E.g. the sub-tabs in the "Output" pane?)

@eirikbakke yes, this. Also across other windows in the IDE. I like the visual consistency. I also understand the concerns. But I'm interested in whether @DevCharly has an idea on how to address the concerns without losing the consistency in the design?

[eirikbakke]

OK, good, that's what I thought. Yes, it'll be best to get @DevCharly's opinion here. No hurry--I don't mind this PR baking for a while.

One new thought: Perhaps the difference between JTabbedPane and the window system tabs is actually a good thing? Especially in the case of the Output pane--it was always awkward to put one set of tabs inside another one. On the Aqua LAF, the tab styles are intentionally different:

There's still the dialog boxes, but I feel like the old FlatLAF style works well in those, even if the window system tabs in the main window follow the more standard bordered-tab appearance.

Anyway, will await input...

[eirikbakke]

Now there's a new JetBrains IDE called Fleet, and even JetBrains now puts the tab selection highlight at the top rather than at the bottom of the tab:

I think the bottom of the tab really needs to have the same color as the background of the pane below; that's what makes it look like a tab. The blue tab selection highlight looks good, but needs to be on the outer edge of the tab to avoid disrupting the background color continuity. See e.g. Fleet, Unity, Excel, PowerBI, and Thunderbird.

(This comment is about window system tabs specifically. Per my previous comment, I still think it's a good idea to use the simplified FlatLAF tabs elsewhere in the UI, like in the Output pane, where having two different styles avoids the clutter of nested tab components. It's like having two different heading levels in a document.)

[neilcsmith-net]

Agreed! My objection to your initial proposal was mostly based on the addition of borders and a gradient - ie. no longer being flat. Using a revised flat background colour, and moving the highlight (not always blue!) above, makes sense.

[Chris2011]

How will this work for colored tabs and multi tabs? Just to leave this information here. Also we have this option to show the file path below the tabs and also the editor toolbar:

I really like when the tab is part of the editor that looks very good, I just wanted to get the attention for the other cases that we already have.

[eirikbakke]

I hadn't heard your objection about gradients before! There's a reason for the gradients that I hadn't explained before.

The problem is to make the relationship between the tab and the editor visually clear, as well as clearly showing which tab is selected. Having mocked up various different styles, I came to a couple of conflusions: 1) The background color of the bottom of the tab card needs to connect with the background color of the pane below (as mentioned before). And... 2) The background color of the selected tab needs to be brighter than the unselected tabs.

The problem is that the editor toolbar is the same brightness as the unselected tab background color. Changing the background colors of the editor toolbar or the draggable spaces between the TopComponents did not look good, in part because there are three levels of surfaces involved (application toolbar and unselected tab area, the editor toolbar, and the editor). The solution was to put a gradient on the selected tab, so the top could be made brighter and the tab would stand out.

As for the borders, these are actually more consistent with the rest of the window than the previous style, because there are already borders around each TopComponent. If there are borders around each TopComponent, having them continue around the tab card looks good:

If we really wanted to get rid of borders, we'd need to remove them from the space between the TopComponents as well. (See the Unity screenshot for an example of that. Visual Studio 2022, on the other hand, keeps the borders.)

[eirikbakke]

@Chris2011 With any one of those options activated, you would see the old editor tab style for now. I think they actually use a different tab component altogether. If we end up agreeing on an acceptable patch for the common case, I can later make a patch to extend it to the special tab options as well.

[KacerCZ]

@eirikbakke I tested your change and I like the proposed change to borders. Space around filename seems too small but maybe I'm not used to it.

[eirikbakke]

The spacing around the filename is an interesting design question. In the old Windows and Aqua LAFs, the tabs were designed to take up the absolute minimum amount of vertical space, with just one pixel of spacing from the icon to the top/bottom borders:

The current FlatLAF style uses more space, while the proposal in this PR is a bit of a compromise between the two (here showing screenshots with 2x HiDPI/Retina scaling):

In the horizontal direction, the changes in this PR are smaller, mainly to make sure the "X" is closer to the text it is associated with rather than the border before the next tab.

[mbien]

I do like having the tab on the same 3d level as the editor. Its more intuitive and makes it clearer that the tab belongs to the active view. Having a border between tab and view only causes second guessing. +1 from me too. Would be great if we could get this finished for NB 14.

[eirikbakke]

Would still be good to have a review from @DevCharly here.

[eirikbakke]

I've been using this patch in my working IDE, and in Ultorg (a NetBeans Platform app) for 10 months now, including with FlatLAF 2.0. Personally I think this patch strictly improves the appearance of FlatLAF on NetBeans, and would remove any remaining reasons to use e.g. the Nimbus, GTK, Aqua, or Windows LAFs.

Would people like this patch to get merged?

@neilcsmith-net Do you feel your objections were overcome in the discussion above?

@DevCharly Any comments or objections?

[PavelTurk]

@eirikbakke +1

[PavelTurk]

This PR was opened almost one year ago. Let's add it as an option here:

I don't know how it is for others, for me it is very difficult to use FlatLAF without the proposed feature.

[neilcsmith-net]

@eirikbakke I'm still -0 on the change. I think there's clearly an accessibility issue with FlatLaf as is, but don't think this is necessarily the right approach (ie. flat with better colour contrasts). And would still have liked @DevCharly input. But that's personal opinion, and I'm not vetoing - someone wants to merge it, merge it!

[eirikbakke]

@neilcsmith-net Thanks for your reply! Perhaps it'd be good to discuss this on the mailing list too, since FlatLAF is now the default LAF, and this PR changes the look significantly. I can send out an email.

As @Chris2011 and @PashaTurok suggested, I could also make this into an option. If so, which look should be the default?

[PavelTurk]

@eirikbakke I would suggest to use FlatLaf theme as it is (without modifications) as a default one. If an user wants to modify it - he can do.

[Chris2011]

I prefer to get this in because I like it, but yeah I can understand that this is not what everyone wants. And for this we should use an option for this or we should have this as an theme inside flatlaf. We talked about such theme styling in another ticket: https://issues.apache.org/jira/browse/NETBEANS-3746

[neilcsmith-net]

Incidentally, I just had a play with the existing theme files, and it certainly seems feasible to address some of the concerns with a few property tweaks in the themes?

EditorTab.background=@background
EditorTab.foreground=@foreground
EditorTab.activeBackground=darken(@background,20%)
EditorTab.activeForeground=@foreground
EditorTab.selectedBackground=@background
EditorTab.selectedForeground=@foreground
EditorTab.hoverBackground=#FFF
EditorTab.hoverForeground=@foreground
EditorTab.attentionBackground=#E6C840
EditorTab.attentionForeground=#000
EditorTab.underlineColor=$TabbedPane.underlineColor
EditorTab.inactiveUnderlineColor=$TabbedPane.underlineColor
EditorTab.underlineHeight=3
EditorTab.underlineAtTop=true
TabbedContainer.editor.contentBorderColor=@background

[eirikbakke]

@neilcsmith-net Yeah, putting the blue active tab indicator on top is already a big improvement. And I see you removed the borders from the rest of the window system, which indeed seems necessary if they are also going to be removed around the tabs.

In this particular screenshot: The dark gray background is a bit ugly, though. And how does this scheme work in the sidebar to the left, which is usually inactive? (Projects, Files) If you can come up with something that works, that's good!

There are a few less controversial changes in this PR as well, such as adjusting the space between the text and the X, and adjusting the vertical height and text alignment of tabs. Perhaps you could do your experiments with these included?

[neilcsmith-net]

The dark gray background is a bit ugly, though. And how does this scheme work in the sidebar to the left, which is usually inactive?

Agreed. It might be too much. But either we need background colour contrast or possibly make a border (like in your changes) across the whole tab top, in the accent colour when focused. Compare with eg. Thunderbird and Aqua LAF screenshots you shared earlier, then with VSCode one. I tried two different greys, depending on focus, so inactive are slightly darker - all ViewTab settings set to same named EditorTab setting. Maybe focus remains slightly accent coloured as it is now. I'll try a tweak tomorrow and share.

There are a few less controversial changes in this PR as well, such as .. adjusting the vertical height

Personally, using a QHD desktop and sometimes a small FHD laptop, one reason I prefer FlatLaf over other LAFs is because the tabs are a usable size. I understand why on other systems, the size might be a problem. I think perhaps considering a compact UI setting might be way to go here - like toolbar icon sizing but broader - not sure there is a one size fits all solution (pun intended! :smile:)

[Chris2011]

I like the gray background it is more and more clear which tab is now the current selected one. And to be honest this is what other tab based applications do. Terminal for Windows, VS Code, Chrome, firefox and I guess a lot more. The problem with the blue border on the top if we just use this, could be when I change my tab to tab colors for the same project. So it should be as prominent as possible.

[eirikbakke]

If you have a darker grey background in the tab area, it should probably continue around into the draggable separators and so on. Making all these different levels of grey make sense together is the main challenge here. (I'd love to see even better designs!)

Personally, using a QHD desktop and sometimes a small FHD laptop, one reason I prefer FlatLaf over other LAFs is because the tabs are a usable size.

Ah, interesting. Are you running without HiDPI scaling? Are you also using a bigger font size than the default?

[jmborer]

+1 for the change. I like the new design better (more readable) especially, when your application is full screen on a 4K monitor.

[edit] By the way, where can you customize the LaF with the properties above for your NB application? I found the answer meanwhile: https://www.formdev.com/flatlaf/how-to-customize/

Now the question is where/when is it possible to call:

FlatLaf.registerCustomDefaultsSource( "com.myapp.themes" );
FlatLightLaf.setup();

during Netbeans lifecycle setup? Is it early enough in an module Installer class?

[neilcsmith-net]

If you have a darker grey background in the tab area, it should probably continue around into the draggable separators and so on.

I disagree with this. Try closing all editor tabs. And try out #4286. I deliberately used the existing empty editor area colour, which is already darker. Then we have the idea of window / tab regions being that colour. The screenshot above made it even darker, though - I've based the PR on the existing colours, which might be enough contrast to work.

Ah, interesting. Are you running without HiDPI scaling? Are you also using a bigger font size than the default?

No scaling, standard font size. I also have NetBeans running on a Chromebook (using Crostini) - that is running at 1.5x (2400x1800 as 1600x1200). Until I updated our .deb to bundle JDK 18, scaling was broken so I was stuck running Nimbus - tabs there again a pain!

[neilcsmith-net]

@jmborer OT, but check https://github.com/apache/netbeans/blob/master/platform/o.n.swing.laf.flatlaf/src/org/netbeans/swing/laf/flatlaf/Installer.java#L35 I assume you'll want to make sure yours runs just after that one by a dependency on that module.

[eirikbakke]

Following up on Neil's PR https://github.com/apache/netbeans/pull/4286 , which is now merged, I'll close this PR and move the other improvements into separate new PRs. (The next one is https://github.com/apache/netbeans/pull/4335 .)