-
-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Layered components legibility (tooltips, internal frames, menus) #94
Comments
also made borders of internal frames in dark themes darker
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. 🥇 |
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?
|
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... |
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. |
@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? |
- reworked drop shadows implementation to support 4-sided shadows - use 4-sided shadow for internal frames - made shadows configurable in UI defaults - made shadows dark in dark themes (issue #94)
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). |
@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... |
@DevCharly I noticed that the shadow is getting darker (like font menu) as we open and close the popup multiple times. |
@DevCharly I just tried changing the Here are some screenshots: |
@cristatus many thanks. This is fantastic. Did not know that. Would you like to create a pull request? |
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? |
Fix popup shadow issue on Linux #94 (comment)
Thanks. Yes the popup menu border is slightly darker. This is set by FlatLaf in UI value |
I had a bad feeling when I saw that you were switching to heavy-weight popups to achieve drop shadows. Bad feeling confirmed... 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. |
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. |
@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. |
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. |
Close this. |
@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). |
@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?
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.... |
Subpixel rendering issue on Windows seems to be a bug in JDK: 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... |
this fixes the sub-pixel text rendering issue (on Windows) for popups that fit into the owner window
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. |
@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? |
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 |
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.
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
Lightweight and heavyweight was not enough! 🙂 |
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. |
I forgot to mention: the bold effect also affects combo box popups when the menu is heavyweight. |
@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. |
When using dark theme on light platform theme, there was a background flashing effect on popups. See JFormDesigner#94
@cristatus thanks for the fix. macOS had the same issue. |
…t has left or top drop shadow (issue #94)
@Chrriis the sub-pixel text rendering issue is now fixed in master branch. |
Drop shadows for medium-weight popups (on Windows) are now implemented in master branch. |
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:
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.
The text was updated successfully, but these errors were encountered: