Rounded buttons are opaque

[lbalazscs]

The buttons don't seem to have real transparency at the corners and borders. Instead of the content behind them the panel color can be seen - this is only OK in simple cases when a button is on a panel.

In the following zoomed-in picture the red arrows indicate the problem areas. Here two buttons are placed on top of each other using a JLayeredPane in order to indicate the foreground and background colors that can be chosen. Such opaque areas don't appear when using Nimbus. Also the Intellij widgets have real transparency, this can be seen if you set a background picture in Idea.

[DevCharly]

You're right. Most components in FlatLaf (also in Metal and Windows LaF) are opaque.

I just used the default opacity of the components.

JLabel is maybe the only component that is not opaque. Even components like JCheckBox, JRadioButton and JSlider are opaque, although it would make much more sense that they are not opaque.

Nimbus, Substance and Aqua seem to use much more non-opaque components. Which makes sense, if the component does not fill its whole bounds.

Seems that I have to rework usage of opacity in FlatLaf completely...

[kirill-grouchnikov]

Yeah, I don't think that this has ever been on the Swing team radar - have some kind of a mechanism akin to the UIResource marker interface, but for the opacity. I made the decision to take control over opacity in Substance, and if the app starts changing it, the visual behavior is undefined.

[DevCharly]

Hmm, isn't LookAndFeel.installProperty() this mechanism?

LookAndFeel.installProperty( comboBox, "opaque", Boolean.FALSE);

Convenience method for installing a property with the specified name
and value on a component if that property has not already been set
by the developer. This method is intended to be used by
ui delegate instances that need to specify a default value for a
property of primitive type (boolean, int, ..), but do not wish
to override a value set by the client. Since primitive property
values cannot be wrapped with the UIResource marker, this method
uses private state to determine whether the property has been set
by the client.

As soon as the developer invokes c.setOpaque(...) it keeps this value and the UI delegate does/can not change it with LookAndFeel.installProperty(c, "opaque", ...).

Isn't this the same as when the developer invokes c.setBackground(new Color(1,2,3)). Then the UI delegate also do not change it.

I think when the developer uses setOpaque() or setBackground(), then he is responsible for the result.

[kirill-grouchnikov]

It eventually does get to set a separate OPAQUE_SET flag on the component, but also calls setOpaque. Maybe I'm thinking of some kind of mechanism that has two places to store opacity - one for app calls, and one for the current look-and-feel calls, and then somehow queries the two together at paint time. That might be too complicated though.

[lbalazscs]

I don't understand everything you guys are talking about, I just wanted to mention that if I call

fgButton.setOpaque(false);

explicitly, then it becomes transparent at the border, but the background color also disappears:

So for my special case it would be enough to respect the background color property even if the component is set to non-opaque. But in general it seems that the idea of rounded buttons does not go well with the idea of opaque components.

[JFormDesigner]

fixed in 0.16