diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-24 20:04:36 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-24 20:04:36 +0200 |
| commit | 28be8eead316f5026e1c0c8ffd46b873d479091d (patch) | |
| tree | 78e73782058b24f0b9c9574cf77dff8cba17788f /packages/meshbay-node | |
| parent | 62253b9592a83ce152d0c64471e20514218fb132 (diff) | |
| download | meshbay-28be8eead316f5026e1c0c8ffd46b873d479091d.tar.gz | |
feat(hub): play audio files from Explorer, scoped to the current folder
Audio files were invisible to file-utils.js's canPreview, so their
name never rendered as a clickable link and the toolbar's Play/View
buttons never enabled for them - the only way to do anything with an
audio file in Files was to download it.
- file-utils.js: canPreview now includes 'audio' alongside image/
video/document.
- files-app.js: the toolbar's canPlay/canView split treats audio like
video (Play, not View) rather than falling into the generic preview
path, which was never built for it anyway.
- group-page.js: onPreview routes an audio entry to onPlayQueue - the
same persistent player Music uses - instead of the preview modal.
Deliberately not Music's artist/album grouping: the queue is every
audio entry sharing the clicked file's literal containing directory
(entry.path), sorted by filename, so previous/next in Explorer stays
scoped to what's actually in that folder, tags or no tags. onPlayQueue
already replaces whatever queue is playing unconditionally, so
starting a track from Files while Music (or another Files folder) is
already playing needs no special handling - it's the same "just a new
queue" path either way.
Client-side only, no protocol/index change. npm run sync-ui re-run.
Full suite: 1129 passed, no regressions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KBi7ALLGfwcjBXt57yNMcy
Diffstat (limited to 'packages/meshbay-node')
0 files changed, 0 insertions, 0 deletions