Pushpin: La carte de réglage FileContent limite les mêmes pour chaque type de fichier

Ah ouais. C'est un peu stupide et certainement de ma faute. AudioContent était un POC que j'ai écrit et qui n'était pas vraiment destiné à atterrir sur le maître, mais nous avons fusionné lorsque nous testions des améliorations de la prise en charge du streaming de fichiers binaires.

Le problème est que FileContent enveloppe essentiellement AudioContent en examinant le champ de type mime de l'hyperfichier, puis en choisissant un type de contenu en fonction de celui-ci (suivez https://github.com/automerge/pushpin/blob/7b1fb02912198c525bf080edd5d14d48e538b729/src/renderer/components/ content-types/files/FileContent.tsx#L72 si vous voulez voir comment cela fonctionne). Cela signifie qu'il utilise toujours le minWidth de l'emballage FileContent dans la pratique.

Résoudre ce problème n'est pas compliqué mais pas vraiment trivial et je ne m'étais pas convaincu que quelqu'un utilisait réellement la fonctionnalité en premier lieu, donc je ne m'y suis pas penché... Une option, au lieu de la réparer, serait d'inclure un peu de métadonnées supplémentaires/choisir un plus grand ensemble d'éléments d'interface utilisateur afin qu'il remplisse l'espace ? Tricher, je sais, mais je veux commencer à diffuser la position à laquelle vous vous trouvez dans le fichier audio, tout comme nous diffusons l'ensemble de cartes sélectionnées dans un tableau afin que vous puissiez voir où se trouvent les autres personnes dans une piste (utile pour, disons, un cas d'utilisation de podcast imaginaire ?)

Heureux de rouler avec l'une ou l'autre approche (corriger le bug de réglage de la hauteur ou améliorer le contenu audio) et aider avec l'une ou l'autre si vous avez envie de vous y attaquer. Cela devrait être un joli petit projet de toute façon.

L'ajout de métadonnées/diffusion supplémentaires semble être une bonne chose sur laquelle travailler ! Dans quels fichiers dois-je rechercher la logique de diffusion de sélection de carte ?

Oooo aussi, que penseriez-vous des commentaires de style soundcloud liés à des moments spécifiques dans l'audio ? Ou est-ce que cela duplique trop de fonctionnalités de threads ? Je pense que des commentaires de style spécifiques au document, par exemple comme celui-ci (ou des commentaires sur des images avec des coordonnées XY comme des balises instagram) pourraient permettre des types intéressants de conversations spécifiques aux médias.

Je me sentirais comme l' enfer oui . Les commentaires codés dans le temps doivent évidemment être stockés dans le document d'une manière ou d'une autre... Contenu arbitraire ? C'est trop fou ?

Pour diffuser la position d'écoute, vous pouvez envoyer une "Présence" qui diffuse votre ID d'utilisateur, votre ID d'appareil et un type encodable JSON supplémentaire arbitraire à vos pairs. Dans BoardCard, vous diffusez votre couleur de sélection à vos pairs. Ce code est un peu bizarre, je sais, mais regardez usePresence dans https://github.com/automerge/pushpin/blob/73193adc907b3c7c109b5f14453f9a838469f02b/src/renderer/components/content-types/board/BoardCard.tsx

Par « contenu arbitraire », entendez-vous un nouveau type de contenu (par exemple audioComments ) avec un tableau de { comment: string, time: number, author: Contact} et l'identifiant du hypermergeUrl de l'audio correspondant ? Ou juste un tableau de { comment: string, time: number, author: Contact} qui est attaché au AudioContent lui-même ? Est-il possible d'attacher un JSON arbitraire à un hyperfichier ? Désolé, je suis encore en train d'apprendre comment fonctionne cette architecture.

Je veux dire, pourrions-nous faire des commentaires un type arbitraire, comme un ThreadContent, TextContent, ImageContent, etc.

(PS : si vous n'avez pas lu ARCHITECTURE.md, cela pourrait accélérer votre compréhension du fonctionnement du système dans les coulisses.)

(en déplaçant cela vers le mou puisque nous avons voyagé assez loin du numéro d'origine)