summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-hub/src/meshbay_hub/static/file-utils.js
Commit message (Collapse)AuthorAgeFilesLines
* feat(hub): play audio files from Explorer, scoped to the current folderChristophe Besson2026-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* feat(hub): split the group UI into a pluggable "applications" architectureChristophe Besson2026-08-231-0/+207
GroupPage's 6620-line app.js carried Chat and Files wedged in directly, with no way to add another group-level app without touching the shell itself. It is now app.js (routing, non-group pages) plus nine focused files — apps.js (the registry), chat-app.js, files-app.js, video-player.js, group-page.js (the shell), group-settings.js, hub-client.js, icon.js and file-utils.js — with docs/apps.md as the checklist for adding one (Videos/Music/Photos are sketched there, not built). Node side gained the matching enablement mechanism, mirroring member_upload exactly: a roster setting, a signed apps_enabled op enforced by _has_admin_authority, exposed in the handshake ack. Operators toggle applications per group from Settings, which also gained a small reorder: Invite, Pairing, Applications, Shared directories, Uploads, danger zone, Your devices, Members. Two bugs surfaced during the split, both missing an import across the new file boundary and invisible to node --check or a module-load probe since they only throw when the code path actually runs: - group-page.js called onRefreshAuth on a stale-token handshake rejection, but app.js never imported refreshAccessToken from hub-client.js — so a brand new member (including a group's own creator) hit "Not a member of this group" and the retry silently failed, throwing before it could refresh the token. - chat-app.js called getLocale() for message timestamps without importing it from i18n.js. Opening Chat on a group with real messages threw mid- render; uncaught, that appears to wedge Preact's render scheduler, so every button on the page stopped responding until reload. Caught the second class of bug with a proper no-undef audit across all split files (a temporarily installed ESLint 9, since the system one is too old to parse this codebase's syntax) rather than trusting grep. 827 tests pass; 6 new ones cover the apps_enabled policy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016SF6RKNBKg9qejmoMJ9ybA