Layered components legibility (tooltips, internal frames, menus)

[Chrriis]

I like FlatLaf because it looks modern. But this modernity should not impact legibility. One area where this is a concern is when components overlap.

Overlapping components that come to mind are:

• Tooltips.
• Internal Frames.
• Menus.

Using this test case as a base for this discussion (one class):
LayersTest.zip

Here is what I get with the Windows look and feel:

Yes, it looks outdated. But, tooltips are quickly visible, order and boundaries of internal frames too.

With FlatLaf:

Note that with real heterogeneous content, its gets even harder to see the tooltips and the frame boundaries. Menus also have the same problem to some extent.

My main problem is with tooltips. A quick way to slightly improve the situation would be to make the border as dark as the internal frame border:

I am not sure what could help legibility for layered components. Of course, subtle drop shadows would definitely help, but I don't know if it is in contradiction with the notion of a flat look and feel:

Note that I was very surprised to find that with FlatLaf, a disabled component had a disabled tooltip! This is not a good idea because tooltips can convey information on why the component is disabled. If I want a "disabled" tooltip, then I would style a tooltip myself. Here is the current outcome (even less readable):

Please let me know what you think.

[DevCharly]

Drop shadows are good way to simulate depth. Don't see a problem with the notion of flat design.

Have started implementation for internal frames on the drop-shadows branch:

On Mac the OS automatically adds drop shadows to heavy-weight popups, but if popup/tooltip bounds are within the window bounds, a light-weight popup is used. So I've changed this to always use heavy-weight popups on macOS, which adds drop shadows to popup menus and combobox popups. But not to tooltips and internal frames.

The "disabled" tooltips are now fixed and the border is darker. Thanks 👍

Thought about making tooltips dark, but have doubts that people use HTML text with custom text colors in tooltips, which would not work anymore with a dark tooltip background.

This is the code to make tooltips dark:

UIManager.put( "ToolTip.background", new Color( 0x1e2123 ) );
UIManager.put( "ToolTip.foreground", new Color( 0xdddddd ) );

BTW @Chrriis thanks for your valuable feedback. I really appreciate it. 🥇

[Chrriis]

1. Drop shadows on internal frames seem to work great on my test case!

If you can have drop shadows on internal frames, wouldn't it be possible to have drop shadows on lightweight menus and/or lightweight tooltips too?

2. Disabled tooltip: yes, much better 🙂

3. Tooltip darker outline does make them more visible. Thanks!

4. Dark tooltips: I am not sure. Indeed, there can be customizations which will be done based on a light theme (which will assume light tooltips) and dark theme (assuming dark tooltips). If developers can opt in, why not, but I don't think it should be the default.

[DevCharly]

Drop shadows for all popups (menu, combobox and tooltip) are now implemented in the drop-shadows branch.

This work is not finished. Not yet tested on Linux. Shadow needs some fine tuning. Especially in dark themes. Also some configuration is needed. Coming soon...

[Chrriis]

This is definitely a step in the right direction!

I would suggest a more subtle drop shadow though, less strong, not that far and wider. The point of that shadow is not to be visible or have the user notice it, but make a component stand out. As such, it would be good that the dark effect of the shadow were all around the component that has the shadow. I don't know if you notice my fake screenshot with shadow, but the left and top edges were slightly darker around too. I used a drop shadow filter of 120°, 1px distance, 4px size and 15% opacity. I could have increased the opacity a little because my shadow is very subtle. Still, it is not too noticeable but does help legibility.

I noticed something when zooming on your screenshot: your painting does not go all the way to the edge! 😉

[Chrriis]

About the shadow visible on all sides but with a distance, I am not sure my explanation was very clear. To illustrate, here is the Windows shadow on a white background. We see it is all around, but still shifted to the bottom right:

I am not saying it should be that strong, it should give a feeling of depth without knowing why 🙂

[Chrriis]

I just tried dark theme, and I saw white shadow around the popup of menus and tooltips. I guess it is not finished 🙂 Internal frames had a black shadow which is much better.

In dark mode, the shadow needs to remain black and maybe stronger than in light mode to be visible. It should play its role because in a dark mode the background should never be black. Moreover, it overlays some components which are not background and can be far from black.

[DevCharly]

@Chrriis thanks for your feedback. I'm working on (fully) customizable drop shadows.

Regarding 4-sided drop shadows: I think they work great for windows (or internal frames), but for menu popups or combobox popups they have the problem that the top drop shadow overlaps the menubar/combobox.

Maybe thats the reason that Windows 10 uses 2-sided drop shadows for menus and comboboxes (and tooltips):

I think I change internal frames to use 4-sided drop shadows by default, but keep 2-sided drop shadows for other popups. This will be configurable.

BTW how did you create the fake screenshots? PhotoShop?

[Chrriis]

I agree with you about 4-sided drop shadows: I came to the same conclusion and wanted to mention it. I think that popup menus should not be 4-sided, but other components which are not attached to a component should be 4-sided (internal frames, tooltips).

Fake screenshots: Photoshop layer of the component with a filter effect (a drop shadow).

[DevCharly]

Extended drop shadow implementation with configuration is now in master branch.

With a single java.awt.Insets object it is now possible to do nearly any kind of drop shadow 😉
Component bounds plus shadow insets are the outer bounds of the shadow.

E.g. 4,4,4,4 paints a 4px shadow on all sides.
4,4,6,6 paints a shadow slightly shifted to bottom-right.
0,4,4,4 paints 4px shadow on left, bottom and right.
0,4,0,4paints shadow on left and right sides.
-6,-6,4,4 paints 4px shadow on right and bottom sides and indents shadow by 6px on top-right and bottom-left corners (similar to following screenshot)

Configuration thru UI defaults is possible for internal frames and all other popups.

Example for popups (menu, combobox and tooltips):

UIManager.put( "Popup.dropShadowInsets", new Insets( -6, 4, 4, 4 ) );
UIManager.put( "Popup.dropShadowColor", Color.red );
UIManager.put( "Popup.dropShadowOpacity", 0.9 );

The UI keys for internal frames are:

InternalFrame.activeDropShadowInsets
InternalFrame.activeDropShadowColor
InternalFrame.activeDropShadowOpacity

InternalFrame.inactiveDropShadowInsets
InternalFrame.inactiveDropShadowColor
InternalFrame.inactiveDropShadowOpacity

Note: Because native drop shadows are used on macOS and Linux, this customization works only on Windows.

[cristatus]

I just tested on Linux (Arch, gnome 3.36.2). The shadows are not transparent and not consistent. See the screenshots.

Here you can see the shadow is painted on a white background.

Here you can see the shadow is dark without or minimal blur.

[DevCharly]

@cristatus thanks. Must admit that I've not yet tested this on Linux. Seems that transparent window does not work as it does on Windows...

[cristatus]

@DevCharly I noticed that the shadow is getting darker (like font menu) as we open and close the popup multiple times.

[cristatus]

@DevCharly I just tried changing the FlatPopupFactory.java line number 65 to if( SystemInfo.IS_MAC || SystemInfo.IS_LINUX ) fixed the issues. So heavy weight popups doesn't require shadow on Linux.

Here are some screenshots:

[DevCharly]

@cristatus many thanks. This is fantastic. Did not know that.

Would you like to create a pull request?

[cristatus]

Done!

Also, I feel the menu border little darker than other components. Is it by default or FlatLaf is setting menu border color? May be the shadow around it is causing that effect?

[DevCharly]

Thanks.

Yes the popup menu border is slightly darker. This is set by FlatLaf in UI value PopupMenu.borderColor. This makes the popup menu more distinguishable from other components when it overlaps them. The new shadow makes it even more distinguishable.

[Chrriis]

I had a bad feeling when I saw that you were switching to heavy-weight popups to achieve drop shadows. Bad feeling confirmed...
We use floating popups to display the content of some tree rows or table cells when they are not completely visible: the lightweight popups can be clicked through (for example double click to open the tree item), while heavyweight ones receive the click and get dismissed but block the action, so we rely on the fact that it is lightweight. More generally, I struggled a lot in the past with heavyweight components so I discourage forcing them to heavyweight...

Short term: how do I deactivate the use of heavy-weight popups? Too bad if I lose drop shadows for them...

Note that I originally thought that you would use a trick like for internal frames: they are not heavyweight but you managed to show a drop shadow.

[smileatom]

Noone needs drop shadows for this the only reason tooltips seemed more visible in the first issue is that they were "yellow". So just change the background color of the tooltip.

[Chrriis]

@smileatom I make applications for others. They want applications that look good and are usable. If a tooltip is in accordance to the look and feel and is not readable, it is bad. If the tooltip is ugly but visible, it is bad. This is where UI design comes into play, and it is the essence of the idea of a Look and Feel.

[smileatom]

There is no such thing as L&F separated from design. IMHO no L&F will ever be a replacement for design. Here's a google chrome "tooltip"

It is not the role of a L&F to save you from any design effort. Its a base that you can extend.

[smileatom]

Also, drop shadows are very out of style. Internal frames are even MORE if not even in consideration in current app design even on desktop. So your porting some aged app and trying to make it look good. Most people dont need this.

[smileatom]

Close this.

[Chrriis]

@DevCharly Using heavyweight popups is causing another problem: it deactivates subpixel font rendering. cf. with/without subpixel rendering (light vs heavy tooltip):

This is a problem because it makes texts less readable and some fonts with certain sizes appear bold if they cannot use the subpixel effect (attracting attention where they shouldn't, sometimes the bold effect appearing in the middle of a word).
I am not sure what is causing this. I think setting transparency on windows affects the ability to use subpixel rendering.

[DevCharly]

@Chrriis you can disable drop shadows (and default heavy weight popups) with:

UIManager.put( "Popup.dropShadowPainted", false );

But if the floating popups on trees and tables do not fit into the application window, a heavy weight popup is used (as in Windows Laf) and you have the same issue...

Do you use some open source library for the floating popups that I can try out?

Note that I originally thought that you would use a trick like for internal frames: they are not heavyweight but you managed to show a drop shadow

This should be doable, but as soon as the popup does not fit into the application window, a heavy weight popup is used and the same issues occur. It was simply easier to implement heavy weight only 😉

Regarding subpixel rendering: this is indeed caused by setting popup window background to a transparent color. Have to investigate....

[DevCharly]

Subpixel rendering issue on Windows seems to be a bug in JDK:
https://bugs.openjdk.java.net/browse/JDK-8215980

macOS and Linux are not affected because not using translucent popup windows on these platforms.

So the current plan it to use light weight popups where possible and use some tricks for heavy weight popups...

[DevCharly]

The recent commit in master now uses light weight popups by default if the popup fits into the owner windows. Only on Windows. On macOS and Linux always heavy weight popup are used.

This fixes the sub-pixel text rendering issue for popups that fit into the owner window.
Have to find a solution for heavy weight popups...

[Chrriis]

@DevCharly Just got the latest and found an odd behavior: sometimes the tooltip does not have the drop shadow while it fits within the JFrame. But I think I found the reason: tooltip is within an internal frame and it seems that when it does not fit within that internal frame it switches to heavy weight tip. Maybe the logic that detects whether it fits has a false negative on internal frames?

[DevCharly]

Aha, the problem is that the tooltip manager sometimes wants use a medium-weight popup but FlatLaf does not support them. Medium-weight popup use a java.awt.Panel.

[Chrriis]

But if the floating popups on trees and tables do not fit into the application window, a heavy weight popup is used (as in Windows Laf) and you have the same issue...

Yes, this is why we use them in clever ways: navigational trees, which are on the left, or tree tables for the tree part (still in the left of the component). While you can play with the components to have them use a heavyweight popup, the normal usage does not.

Do you use some open source library for the floating popups that I can try out?

I use an old library (Datatips, from Stephen Kelvin Friedrich, free to modify and distribute), which I patched multiple times. Here is my version, along with a simple test case: DataTips.zip
If interested, I can give you the source code of this patched library (e-mail me: chrriis (at) gmail (dot) com).
Our target is Windows, no idea how it works on other OS.

Aha, the problem is that the tooltip manager sometimes wants use a medium-weight popup

Lightweight and heavyweight was not enough! 🙂

[Chrriis]

you can disable drop shadows (and default heavy weight popups) with: UIManager.put( "Popup.dropShadowPainted", false );

Is there a way to keep the drop shadows for lightweight tooltips but not for heavyweight tooltips? Because the sub-pixel issue, which results in bold rendering, is a problem, and it would be silly to deactivate shadows as most of the time tooltips are within the window.

Here is the bold effect I am talking about:

[Chrriis]

I forgot to mention: the bold effect also affects combo box popups when the menu is heavyweight.

[cristatus]

@DevCharly using heavy popup has a side effect. When using dark theme, there is a flash effect as you can see in this animation:

I don't know if this is the case with macOS too but on Linux the fix is to set the background of the container window from the contents.

[DevCharly]

@cristatus thanks for the fix. macOS had the same issue.

[DevCharly]

@Chrriis the sub-pixel text rendering issue is now fixed in master branch.
The problem with missing drop shadows on medium-weight tooltips is not yet fixed.

[DevCharly]

Drop shadows for medium-weight popups (on Windows) are now implemented in master branch.