# Plan: Replace Internal SVGLoader Usage

## Context

The JetBrains plugin currently imports `com.intellij.util.SVGLoader` in `packages/kilo-jetbrains/frontend/src/main/kotlin/ai/kilocode/client/ui/SvgIconColorizer.kt` and calls `SVGLoader.load(ByteArrayInputStream(patch()), scale.toFloat())` from `SvgIcon.image(Graphics)`.

Inspection reports this as an internal API usage because `SVGLoader` and its `load(InputStream, float)` method are marked `@ApiStatus.Internal`.

I checked the local IntelliJ source reference via `$INTELLIJ_REPO=/Users/kirillk/products/intellij-community`:

- `platform/util/ui/src/com/intellij/util/SVGLoader.kt`
- `platform/util/ui/src/com/intellij/ui/svg/svg.kt`
- `platform/util/ui/src/com/intellij/ui/svg/jsvg.kt`
- `libraries/jsvg/intellij.libraries.jsvg.iml`

Important findings:

- IntelliJ `SVGLoader.load(stream, scale)` delegates to internal `loadSvg(...)` in `com.intellij.ui.svg`.
- The actual renderer uses `com.github.weisj:jsvg:2.1.0` and renders into a `BufferedImage` with antialiasing, bicubic interpolation, and pure stroke control.
- Copying `SVGLoader.kt` directly would keep references to other internal IntelliJ APIs (`IconLoader`, `ScaleContext`, `ImageUtil`, `SvgAttributePatcher`, `createJSvgDocument`, `renderSvgWithSize`, cache classes, etc.) and would be broader than needed.

## Implementation Plan

1. Add Kilo-owned SVG rendering code under the frontend UI package, for example:
   - `packages/kilo-jetbrains/frontend/src/main/kotlin/ai/kilocode/client/ui/SvgLoader.kt`
   - Package: `ai.kilocode.client.ui`
   - Suggested internal object name: `SvgLoader`

2. Keep the copied implementation minimal and purpose-specific:
   - Accept `InputStream` and `scale: Float`.
   - Parse the SVG with `com.github.weisj.jsvg.parser.SVGLoader().load(stream)` or the equivalent public jsvg API available in version `2.1.0`.
   - Determine image dimensions from the root SVG `width` and `height` already parsed by existing `SvgIconColorizer.size(...)`, or by passing dimensions into the loader if the public jsvg API does not expose reliable intrinsic size.
   - Render into `BufferedImage(width * scale, height * scale, BufferedImage.TYPE_INT_ARGB)` using `Graphics2D` rendering hints matching IntelliJ’s `jsvg.kt`:
     - `KEY_ANTIALIASING = VALUE_ANTIALIAS_ON`
     - `KEY_INTERPOLATION = VALUE_INTERPOLATION_BICUBIC`
     - `KEY_STROKE_CONTROL = VALUE_STROKE_PURE`
   - Return `Image`/`BufferedImage`.

3. If jsvg does not expose intrinsic size cleanly from public API, adjust the API to avoid duplicating SVG parsing:
   - Add `width` and `height` parameters to the Kilo loader.
   - In `SvgIcon.image(Graphics)`, call the loader with the already-computed `size.first` and `size.second`.
   - This is the likely smallest stable solution because current icons already require explicit `width` and `height` for `SvgIconColorizer.size(...)`.

4. Add the jsvg dependency explicitly to the plugin frontend module instead of relying on the IntelliJ-bundled library:
   - In `packages/kilo-jetbrains/gradle/libs.versions.toml`, add `jsvg = "2.1.0"` and `jsvg = { module = "com.github.weisj:jsvg", version.ref = "jsvg" }`.
   - In `packages/kilo-jetbrains/frontend/build.gradle.kts`, add `implementation(libs.jsvg)`.
   - This follows the package instruction to bundle third-party libraries with the plugin rather than relying on IDE-bundled versions.

5. Update `SvgIconColorizer.kt`:
   - Remove `import com.intellij.util.SVGLoader`.
   - Replace `SVGLoader.load(ByteArrayInputStream(patch()), scale.toFloat())` with the Kilo-owned loader call.
   - Keep the existing color patching, cache key, scale calculation, and size parsing intact.

6. Add a focused frontend unit test:
   - New test file: `frontend/src/test/kotlin/ai/kilocode/client/ui/SvgIconColorizerTest.kt` or `SvgLoaderTest.kt`.
   - Exercise the actual loader/colorizer with a small SVG resource or inline SVG bytes.
   - Assert that rendering returns a non-empty image at scale `1f` and `2f`, and that scaled dimensions are correct.
   - If testing the colorizer, paint the icon into a `BufferedImage` and verify at least one expected patched pixel color appears.

7. Run verification from `packages/kilo-jetbrains/`:
   - `./gradlew typecheck`
   - A targeted frontend test if Gradle supports one cleanly, otherwise `./gradlew test`.
   - The requested DevKit internal API inspection is IDE-based; note in final response that the code no longer references `com.intellij.util.SVGLoader`, and typecheck/tests were run.

## Notes And Risks

- The user said “copy SaveLoaer”; I interpret this as “copy `SVGLoader`”. The implementation should copy the relevant rendering behavior, not IntelliJ’s full internal `SVGLoader` object, because the full source depends on multiple other internal APIs and cache infrastructure.
- This change is in `packages/kilo-jetbrains/`, a Kilo-owned package, so `kilocode_change` markers are not needed.
- jsvg package names and constructors should be confirmed during implementation against the downloaded dependency/API available to Gradle. If the API differs from IntelliJ source usage, inspect the source jar or compile error and adapt the minimal wrapper accordingly.
