The Library tab's top-level system list should include virtual systems (Core
launchables), the way zaparoo-frontend does. Right now it drops them.
Excluding them from the other system lists is correct — search pickers,
create.search.tsx, and the SystemSelector instances all pick a system to
search or browse within, and a virtual system has no media inside it. This is
only about the top-level list you land on in the Library tab, where each entry is
a thing you can pick and write to a token.
Core returns virtual systems from systems with zapScript set to their
zaparoo://<uuid>/<name> URI and mediaCount: 0. The Library list filters
through filterSystemCatalog (src/routes/library.index.tsx:105), which applies
systemHasIndexedMedia (src/lib/systemFilters.ts:23-27):
return system.mediaCount === undefined || system.mediaCount > 0;
zaparoo-frontend uses the zap script as the signal instead of treating a zero
count as "empty" — rust/zaparoo-core/src/endpoints/catalog.rs:63:
!system.zap_script.trim().is_empty() || system.media_count.is_some_and(|count| count > 0)
Two notes on implementing it:
- The existing
includeEmptySystems option is too blunt here. It would also
admit real systems with zero indexed media, which library.index.test.tsx:145
("should hide systems with an explicit zero media count") deliberately keeps
hidden. The frontend's rule — keep when zapScript is non-empty or media
count > 0 — draws the line in the right place.
- The app never reads
System.zapScript anywhere today, so listing a virtual
system also needs a way to write it to a token, otherwise the entry is inert.
availableSystemCount (library.index.tsx:128) gates the empty state and
would need the same treatment.
This came up with a Windows user whose custom Winamp launcher appeared to do
nothing. Platforms without an on-device frontend feel it most: Core serves
/app/ from the embedded zaparoo-app build, so on Windows the app and the web
UI are the same code and a kind = "virtual_system" custom launcher is not
visible anywhere.
The Library tab's top-level system list should include virtual systems (Core
launchables), the way
zaparoo-frontenddoes. Right now it drops them.Excluding them from the other system lists is correct — search pickers,
create.search.tsx, and theSystemSelectorinstances all pick a system tosearch or browse within, and a virtual system has no media inside it. This is
only about the top-level list you land on in the Library tab, where each entry is
a thing you can pick and write to a token.
Core returns virtual systems from
systemswithzapScriptset to theirzaparoo://<uuid>/<name>URI andmediaCount: 0. The Library list filtersthrough
filterSystemCatalog(src/routes/library.index.tsx:105), which appliessystemHasIndexedMedia(src/lib/systemFilters.ts:23-27):zaparoo-frontenduses the zap script as the signal instead of treating a zerocount as "empty" —
rust/zaparoo-core/src/endpoints/catalog.rs:63:Two notes on implementing it:
includeEmptySystemsoption is too blunt here. It would alsoadmit real systems with zero indexed media, which
library.index.test.tsx:145("should hide systems with an explicit zero media count") deliberately keeps
hidden. The frontend's rule — keep when
zapScriptis non-empty or mediacount > 0 — draws the line in the right place.
System.zapScriptanywhere today, so listing a virtualsystem also needs a way to write it to a token, otherwise the entry is inert.
availableSystemCount(library.index.tsx:128) gates the empty state andwould need the same treatment.
This came up with a Windows user whose custom Winamp launcher appeared to do
nothing. Platforms without an on-device frontend feel it most: Core serves
/app/from the embeddedzaparoo-appbuild, so on Windows the app and the webUI are the same code and a
kind = "virtual_system"custom launcher is notvisible anywhere.