Fix 242 icon loading by providing new key-based API

[rock3r]

In IJP 242 the icon loading has changed yet again. Instead of relying on icon mappings like it used to, now New UI icon paths are hardcoded into the CachedImageIcon themselves. This breaks Jewel's ability to load New UI icons, resulting in old UI icons being shown instead.

With this PR, we set to address this issue, and design an API that improves upon the existing ones. We have created the new IconKey, that encapsulates an icon resource path in a better typed and fully portable way allowing the same code to be used both in standalone and in bridge mode.

We have a new generation task in the ui module that traverses an AllIcons-style class and an icon mappings json file (like PlatfomIconMappings.json), and creates an icon keys file with the same structure. These keys are then used to look up icons, simplifying the code. This mechanism should work for 233 and 241 as well, since it bypasses the need for relying on the platform icon mapping, until we get better APIs, hopefully soon.

The Icon composable now accepts PainterHints and uses them when rendering the icons, too.

What used to look like this:

Icon(
  "actions/close.svg",
  iconClass = AllIcons::class.java,
  modifier = Modifier.border(1.dp, Color.Magenta),
  contentDescription = "An icon",
)

Icon(
  "icons/github.svg",
  iconClass = JewelIcons::class.java,
  modifier = Modifier.border(1.dp, Color.Magenta),
  contentDescription = "An icon",
)

Now looks like this:

PlatformIcon(AllIconsKeys.Actions.Close, "An icon")

Icon(
  IdeSampleIconKeys.gitHub,
  iconClass = IdeSampleIconKeys::class.java,
  modifier = Modifier.border(1.dp, Color.Magenta),
  contentDescription = "An owned icon",
)

Applying hints to Icons and PlatformIcons is also much easier now. It was:

val iconProvider =
    rememberResourcePainterProvider("icons/taskGroup.svg", StandaloneSampleIcons::class.java)

val badged by iconProvider.getPainter(Badge(Color.Red, DotBadgeShape.Default))
val strokedAndBadged by iconProvider.getPainter(Badge(Color.Red, DotBadgeShape.Default), Stroke(Color.White))

Icon(badged, "taskGroup")
Icon(strokedAndBadged, "taskGroup")

And now is:

PlatformIcon(AllIconsKeys.Nodes.ConfigFolder, "taskGroup", hint = Badge(Color.Red))

PlatformIcon(
  AllIconsKeys.Nodes.ConfigFolder,
  "taskGroup",
  hints = arrayOf(Stroke(Color.White), Badge(Color.Red)),
)

The sample code has been partially updated to the new API, but more work is needed to spread the change throughout existing components and their styling. That will come in a follow-up PR.

[jakub-senohrabek-jb]

To reduce dependency on IntelliJ platform, maybe current composition context (or something better) could hold something like IconProvider, which can resolve icon by id? Then when used as IJ plugin, it could use IntelliJIconKey.fromPlatformIcon as the IconProvider and in case of desktop jewel, it can use any kind of resource based thing, or it can be even customizable. The Icon api would then accept this id, maybe it can be even same, but we can make the Icon class nullable, to indicate it should be automatically resolved.

interface IconProvider {
	fun getIconByKey(key: string): ResourcePainter? // or maybe just Painter?
}

[rock3r]

That was an earlier iteration on the design, but it depends on having IJP classes on the classpath (e.g., AllIcons) to use as keys, or using stringly-typed APIs, which are anti-goals for this change. To make it work, we'd still need to generate the keys anyway, so at that point, might as well go all the way with our keys to the API. Custom themes should still be able to use json icon mappings to provide custom icons if they so wish.

Out of date, he provided the fix he wanted