Decorations support for macOS.

[weisJ]

No description provided.

[vlsi]

It looks like a reflective approach does not really work :(
JDK's native code seems to intersect the passed bits with _STYLE_PROP_BITMASK, so it ignores all unknown ones.

I tried DialogDemo, and I have the following:

1. JRootPane should probably be saved and returned in response to getRootPane otherwise install fails with NPE trying to access getRootPane

I made the following changes:

public class MacOSTitlePane extends CustomTitlePane {
    private final JRootPane rootPane;

    public MacOSTitlePane(JRootPane rootPane) {
        this.rootPane = rootPane;
        determineColors();
    }

    @Override
    public JRootPane getRootPane() {
        return rootPane;
    }

2. It seems to work for Java 13, macOS 10.14:

Video:
https://drive.google.com/open?id=1T0IP9Vut6_vyaEqoPBDpWWd5z_gwVbVi

3. TItle foreground color does not seem to depend on the theme. For instance, DarculaTheme produces hard to read title:

4. Dialog size is not consistent, so often the dialog shows as "buttons only" (it does not happen if I disable MacOSDecorationsProvider:

5. Dialogs in "More Dialogs" are drawn without a title at all:

3,4,5 do not happen if MacOSDecorationsProvider is deactivated.

[weisJ]

I feel like we can’t get around actually using an approach with native code. I was aware that the title color would be mismatched but choose to ignore it until the setting the style bits actually works (it’s a lot simpler with native code).

I’ll have to look if 4 and 5 also happen for me. Could be a general issue with the custom rootpane implementation.
In the screen cap I‘m seeing that the size of the window is miscalculated after reopening the dialog. This should be due to a correction where the native peer insets are subtracted from the rootpane proffered size to adjust for the native insets. I’ll see if this also happens on windows. If not this probably isn’t necessary on macOS.

Back to the drawing board then.
@vlsi Do you have a c++ toolchain installed. The next solution probably involves some native code which I can’t check that it properly compiles.

[vlsi]

I have c++ and xcode installed.

[weisJ]

Could you please change DarkRootPaneUI#installClientDecorations to read

CustomTitlePane titlePane = Decorations.createTitlePane(root);
setTitlePane(root, titlePane);
updateWindow(root.getParent());
installLayout(root);
if (window != null) {
     if (window instanceof Frame && !window.isDisplayable()) {
         System.out.println("Frame [" + root + "]"
                                       + " DecorationStyle: " + root.getWindowDecorationStyle()
                                       + " Undecorated: " + (root.getWindowDecorationStyle() == JRootPane.NONE));
         ((Frame) window).setUndecorated(root.getWindowDecorationStyle() == JRootPane.NONE);
     } else if (window instanceof Dialog && !window.isDisplayable()) {
        System.out.println("Dialog [" + root + "]"
                                       + " DecorationStyle: " + root.getWindowDecorationStyle()
                                       + " Undecorated: " + (root.getWindowDecorationStyle() == JRootPane.NONE));
        ((Dialog) window).setUndecorated(root.getWindowDecorationStyle() == JRootPane.NONE);
    }
    root.revalidate();
    root.repaint();
}

and tell me the output when opening the dialog that doesn't have any titlebar.

[vlsi]

"pick one of several options", Java 11:

Dialog [javax.swing.JRootPane[,0,0,0x0,invalid,
layout=com.github.weisj.darklaf.ui.rootpane.DarkSubstanceRootLayout,
alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,
maximumSize=,minimumSize=,preferredSize=]]
DecorationStyle: 2 Undecorated: false

Java 13 (I guess the output is the same):

Dialog [javax.swing.JRootPane[,0,0,0x0,invalid,
layout=com.github.weisj.darklaf.ui.rootpane.DarkSubstanceRootLayout,
alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,
maximumSize=,minimumSize=,preferredSize=]]
DecorationStyle: 2 Undecorated: false

[weisJ]

Does disabling MacOSDecorationsProvider give you a close button for the case of "pick one of several options"?

[vlsi]

        } else if (SystemInfo.isMac && false) {
            decorationsProvider = new MacOSDecorationsProvider();
        } else {

red button in the title is close. The other buttons in the title are disabled.

[vlsi]

Just in case,

        } else if (SystemInfo.isMac) {
            decorationsProvider = new MacOSDecorationsProvider();
        } else {

"non-modal dialog"

Dialog [javax.swing.JRootPane[,0,0,0x0,invalid,
layout=com.github.weisj.darklaf.ui.rootpane.DarkSubstanceRootLayout,
alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,
maximumSize=,minimumSize=,preferredSize=]]
DecorationStyle: 2 Undecorated: false

[weisJ]

Is it always the same dialog that has no title bar? If yes please check whether only the following are affected:

• MoreDialogs -> "Pick one of several choices"
• MoreDIalogs -> "Enter some text"
• IconDialog -> "Plain (no icon)"

If yes again please verify that JOptionPane.showMessageDialog(parent, "Test", "Test", JOptionPane.PLAIN_MESSAGE); produces a corrupted dialog.

[vlsi]

MoreDialogs -> "Pick one of several choices"
MoreDIalogs -> "Enter some text"
IconDialog -> "Plain (no icon)"
If yes again please verify that

It does:

[weisJ]

@vlsi Could you check if the latest additions fix the missing titlebar for you? Also do dialogs still get smaller when reopening?

[vlsi]

Thanks, titlebar is fixed:

Also do dialogs still get smaller when reopening?

Sometimes they do. It seems to be random, however, it does happen.

[weisJ]

I have now removed the useage of AWTAccessor alltogether by fetching the peer in the native method (and added null checks). A window pointer of 0 now should yield the correct layout.

As for disabling native code I have:

• Wrapped the creation of the DecorationsProvider in a try catch block as this is the earlies point where the missing module (darklaf-windows or darklaf-macos) can be detected. In this case the DefaultDecorationsProvider is used.
• Added a system property switch to DarkLaf#getSupportsWindowDecorations. When System.getProperty("darklaf.decorations") returns "false" no decorations are used.
• If loading the library is blocked by the SecurityManager decorations will be disabled.

[weisJ]

@vlsi Could you try out the new version?

[vlsi]

Java 11 + -Ddarklaf.decorations=false:

[vlsi]

Suggested change

	val TargetMachine.getVariantName: String get() = "$operatingSystemFamily-$architecture"
	val TargetMachine.variantName: String get() = "$operatingSystemFamily-$architecture"

[weisJ]

Java 11 + -Ddarklaf.decorations=false:

Can you check if this still happens? If yes does MacOSDecorationsUtik#installDecorations get called (with Stacktrace)?

[vlsi]

Ok, now it works great 🎉

[weisJ]

Any last thoughts? Something that needs to change? Otherwise I'll merge the PR.

[vlsi]

I think this is ready to merge.