Set App Icon from Pixels

[tonsky]

Follow up to #95

• Windows
• Linux
• macOS

[dzaima]

Currently looking into this, as part of trying to get general app icons for Linux. For that, there are, as far as I can tell, two approaches:

• have a globally-installed the-app.desktop file describing the program and its icon location (and the app setting a WM_CLASS hint to associate to it); seems impossible to make work via just setIcon, but would be good to have as a WindowX11-only thing for those wanting to do proper X11 application association;
• set via pixels; this could be bound to setIcon, but means something has to decode the png (or whatever file format).

I have both WM_CLASS configuring and icon-from-pixels configuring for X11 here via a temporary interface, using Skija to decode the png in the dashboard example. (the class isn't used by the example, but e.g. an OS-global icon theme could now set a custom icon for it)

[tonsky]

Both look good, make a PR?

I understand that setting icon is more of a packaging problem and probably can’t be easily solved by just doing API calls, but where it can work I don’t see why not have it

[chirontt]

The above code is working for X11, but what about other platforms such as Mac and Windows?

Currently the Window class contains only one method: to load the icon from a physical file in the file system:

JWM/shared/java/Window.java

Line 205 in b921797

public abstract Window setIcon(File icon);

The above method won't work if the icon is a resource in an application's jar file; in that case, the icon is just a stream of bytes embedded in the jar file. I suggest JWM should add a new method for such use case:

    public abstract Window setIcon(byte[] icon);

Browsing the dashboard example application, the paths to the physical icons are hard-coded in the application's code:

JWM/examples/dashboard/java/Example.java

Lines 82 to 87 in b921797

	case WINDOWS -> {
	window.setIcon(new File("examples/dashboard/resources/windows.ico"));
	}
	case MACOS -> {
	window.setIcon(new File("examples/dashboard/resources/macos.icns"));
	}

which allows only one place to run the application in order to properly load the physical icon file. This is too limited/restrictive.

Instead, the code can be enhanced to use the above new setIcon(byte[]) method:

            case WINDOWS -> {
                window.setIcon(loadIconResource("windows.ico"));
            }
            case MACOS -> {
                window.setIcon(loadIconResource("macos.icns"));
            }

where loadIconResource is a utility method that returns the icon resource as a stream of bytes:

    byte[] loadIconResource(String icon) {
        // load the icon from a physical file, or from a resource in the classpath, etc.
    }

[tonsky]

If OS API allows for that (e.g. it doesn’t require you to point at file on disk) then I am all in for byte[]

[chirontt]

I don't know about Mac or X11, but I think the X11 case is already solved in this thread/commits.

For Windows, Java doesn't have a built-in way to parse the .ico file, so we need to use native Windows APIs. Assuming the byte[] array are raw bytes from a .ico file, we can use the following Win32 functions exported by user32.dll:

• LookupIconIdFromDirectoryEx: Inspects raw icon bits and returns the exact integer resource identifier (offset) for the icon version that best fits your display resolution.

• CreateIconFromResourceEx: Builds the HICON handle from the raw resource bits once the correct offset is identified.

I've done some prototype code with the above 2 functions and they work fine, although I use Java FFM to prototype, not JNI C header.

But I'm not sure what JWM can do with the given Windows HICON handle. How can JWM use the handle to "set the icon" to the window?

[tonsky]

I don’t know :) But I also think changing icon of a running application is a very narrow use-case

[chirontt]

what JWM can do with the given Windows HICON handle. How can JWM use the handle to "set the icon" to the window?

PR #310

With this PR, I can now create a dashboard native image using GraalVM.