WIP: Allow icons to be relative to fragment profiles (and user settings!)

[DHowett]

No description provided.

[DHowett]

@crramirez this is what we're thinking for fragment profiles right now. Let me know if this computes.

Icons (and other media resources, eventually -- this PR is just WIP) can be relative to the json file that refers to them. This will be true for fragments of all kinds (app, localdata and appdata) as well as user settings.

You can specify...

"icon": "foo.ico",

with a directory layout like this:

        Directory: C:\Users\duhowett\AppData\Local\Microsoft\Windows Terminal\Fragments\dustin


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a---         7/17/2025   5:36 PM            375 dustin.json
-a---         3/20/2018   7:02 PM          31024 foo.ico

However, we know that won't work for you across the board. If you change icon, Terminal 1.18 (comes with Windows) through 1.23 will fail to load the relative icon. Sucks.

So, this is the terrible thing we've actually come up with:

            "guid": "{08797460-2087-4567-8309-dcc65117ec63}",
            "icon": "https://howett.net/favicon.ico", // for old terminal versions
            "icon2": "foo.ico", // for new terminal versions
            "name": "Dustin Tries a Thing",

icon2 will always override icon. 1.18-1.23 use icon, 1.24+ use icon2. We will probably have to support it forever, but you won't. After 1.18 leaves the default install media for most people, and everyone is on a version that supports relative path media locators, you can move off it.

---

We can't support ms-resource: and ms-appx: because they only work when Terminal adds your package to our package dependency graph. That will also expose all of our binaries to you and vice-versa, and anyway we can't manage the lifetime of such graph to a fine enough granularity that the settings model can load icons at any point during UI construction (including the future during reloads).

[crramirez]

Hello @DHowett ,

Thank you for taking me into account about this.

I see three issues to deal with about this change:

1. backgroundImage: The background image can be also customized via fragments. Not widely used but at least Pengwin, Fedora Remix WSL and Pengwin Enterprise, use it to provide a goodlooking default background. So, following the proposed solution, a backgroudImage2 should be created.
2. end of http support: As it is a security issue I can infer that http won't be allowed in icon2 but in icon on versions 1.18 to 1.23. Won't be allowed in either icon2 or icon after 1.24.
3. This will leave for the eternity two fields icon and icon2 with no clear difference between them, that will be needed to be very well specified in the documentation.

The fallback approach

I propose a different approach, similar to what xml does with its schema urls.

1. You keep only one icon and backgroundImage fields.
2. If the content is relative you'll read based on json fragment's path. It won't work on Terminal versions prior 1.24. I can be specified in the documentation.
3. If the content is http, versions prior 1.24 will download the file. Earlier versions will extract the filename and look for it in the fragment path. That can be specified in the documentation, suggesting URLs for backward compatibility and also have it local to support newer versions.

The above will help to have a smooth transition without permanently complicate the specification.

What do you think?