Pushpin: Los límites de la tarjeta de configuración de FileContent son los mismos para cada tipo de archivo

Ah sí. Esto es un poco estúpido y definitivamente es mi culpa. AudioContent fue un POC que escribí y que en realidad no estaba destinado a aterrizar en el maestro, pero nos fusionamos cuando estábamos probando mejoras en el soporte de transmisión de archivos binarios.

El problema es que FileContent esencialmente envuelve AudioContent mirando el campo mimetype del hiperarchivo y luego seleccionando un tipo de contenido basado en eso (siga https://github.com/automerge/pushpin/blob/7b1fb02912198c525bf080edd5d14d48e538b729/src/renderer/components/ content-types / files / FileContent.tsx # L72 si desea ver cómo funciona). Eso significa que siempre usa el minWidth del FileContent envolvente en la práctica.

Arreglar esto no es complicado pero no es realmente trivial y no me había convencido de que nadie estuviera usando la funcionalidad en primer lugar, así que no lo hice ... Una opción, en lugar de arreglarlo, sería incluir un poco más de metadatos / elegir un conjunto más grande de elementos de la interfaz de usuario para que llene el espacio? Hacer trampa, lo sé, pero quiero comenzar a transmitir la posición en la que se encuentra en el archivo de audio, al igual que transmitimos el conjunto de tarjetas seleccionadas en un tablero para que pueda ver dónde están otras personas en una pista (útil para, digamos, ¿Algún caso de uso de podcast imaginario?)

Feliz de rodar con cualquiera de los enfoques (corregir el error de ajuste de altura o mejorar el contenido de audio) y ayudar con cualquiera de los dos si tiene ganas de abordarlo. Debería ser un pequeño proyecto agradable de cualquier manera.

¡Agregar metadatos / transmisiones adicionales suena como algo genial en lo que trabajar! ¿Qué archivos debo buscar para la lógica de transmisión de selección de tarjeta?

Oooo también, ¿cómo te sentirías acerca de los comentarios estilo soundcloud vinculados a momentos específicos en el audio? ¿O eso está duplicando demasiada funcionalidad de subprocesos? Creo que los comentarios de estilo específicos del documento, por ejemplo, como este (o comentarios sobre imágenes con coordenadas XY como etiquetas de instagram) podrían permitir tipos interesantes de conversaciones específicas de los medios.

Me sentiría como el infierno, sí . Los comentarios codificados por tiempo obviamente deberían almacenarse en el documento de alguna manera ... ¿Contenido arbitrario? ¿Eso es demasiado loco?

Para transmitir la posición de escucha, puede enviar una "Presencia" que transmite su ID de usuario, ID de dispositivo y un tipo codificable JSON adicional arbitrario a sus pares. En BoardCard, transmite el color de su selección a sus compañeros. Este código es un poco extraño, lo sé, pero mira usePresence en https://github.com/automerge/pushpin/blob/73193adc907b3c7c109b5f14453f9a838469f02b/src/renderer/components/content-types/board/BoardCard.tsx

Por "contenido arbitrario", ¿te refieres a un nuevo tipo de contenido (por ejemplo, audioComments ) con una matriz de { comment: string, time: number, author: Contact} y la identificación del hypermergeUrl del audio correspondiente? ¿O simplemente una matriz de { comment: string, time: number, author: Contact} que se adjunta al propio AudioContent ? ¿Es posible adjuntar JSON arbitrario a un hiperarchivo? Lo siento, todavía estoy aprendiendo cómo funciona esta arquitectura.

Quiero decir, ¿podríamos hacer que los comentarios sean de un tipo arbitrario, como ThreadContent, TextContent, ImageContent, etc.

(PD: si no ha leído ARCHITECTURE.md, podría acelerar su comprensión de cómo funciona el sistema detrás de escena).

(moviendo esto a holgura ya que nos hemos alejado bastante del problema original)