Shortcuts in the Overview section: improved icon support

[Kyrodan]

Regarding the new Shortcuts feature (#469 and #864).
I don't want to upload an image for a link. It's just an icon and as heavy self-hoster I don't want to search and fetch icons from "somewhere", I would like to have it just built-in Yuvomi.

Idea 1:
So why not add the Self-Hoste icon set built-in to Yuvomi.
An icon-picker is not necessarily required in first place if a help-text states to the search-capabilities of the website.

Idea 2:
You mentioned to query the favicon is not an option because each load of the dashboard page causes traffic. That's true.
But what if the favicon gets downloaded on demand in the edit/create dialog?

Both ideas could also be combined, so there are three options for the image.

[ulsklyc]

Thanks - this is a good catch, and the answer turned out to be that the icon set was already in the repo.

Built in, and it already shipped: Lucide. Yuvomi vendors the full Lucide set at public/lucide.min.js (v0.469.0, 1743 icons) and draws every button in the app with it. What was missing was not the icons, but a way to pick one. So a quick link now has a third face next to "uploaded image" and "first letter": a built-in symbol, chosen from a searchable grid. An icon costs the length of its name instead of the 20-40 KB of a data URL, it stays sharp, it takes the tile colour, and it follows the light/dark switch - none of which a raster upload does.

The picker opens from the tile preview in the quick link dialog. It starts with ~48 suggestions for common self-hosted categories (media, storage, home control) and searches the full set from there. One caveat worth stating plainly: the names are English identifiers (film, server, clapperboard), so the search is English - the placeholder says so, rather than letting someone type "kalender" and find nothing.

On Idea 1 (bundling selfh.st/icons). I looked at it seriously, and it does not carry its weight here. It would be a low double-digit megabyte increase in the repo for a row that holds at most 24 tiles; every brand logo carries its own licence situation; and Yuvomi vendors third-party code by hand with a documented update path (public/vendor/README.md), which does not scale to a few thousand SVGs that change upstream. And it still would not be complete - the one service someone is looking for can be missing from that set too, which puts us back at the upload.

You do lose the actual brand mark this way: you get a film reel instead of the Jellyfin logo. If you want the real logo, the image upload is still there, unchanged.

On Idea 2 (fetching the favicon on demand). This one I wanted to work, and it does not - for a reason that is worth writing down.

The browser cannot do it. It may display a cross-origin image, but not read it: a canvas tainted by a cross-origin source throws on toDataURL(), and favicons do not ship CORS headers. Without reading it there is nothing to store.

That leaves the server fetching it. But any household member can create a quick link - there is no admin gate on that route - and quick links point at internal addresses by design (the placeholder in the dialog is literally 192.168.1.5:8096). A server that any member, including a child account, can point at any address inside the home network is a network-scanning tool. That price is higher than the saved lookup, so it stays out. The same reasoning is why the subscription logo fetch, which does exist, refuses private addresses.

Shipping in the next release. The reasoning above lives in the code as well, so the next person to reach for selfh.st or a favicon fetch finds out why it was not taken.