Pushpin: O cartão de configuração de FileContent tem o mesmo limite para cada tipo de arquivo

Ah sim. Isso é um pouco estúpido e definitivamente minha culpa. AudioContent era um POC que eu escrevi que não era para pousar no master, mas nós fundimos quando estávamos testando melhorias no suporte para streaming de arquivo binário.

O problema é que FileContent essencialmente envolve AudioContent olhando para o campo de tipo MIME do hiperarquivo e, em seguida, escolhendo um tipo de conteúdo com base nisso (siga https://github.com/automerge/pushpin/blob/7b1fb02912198c525bf080edd5d14d48e538b729/src/renderer content-types / files / FileContent.tsx # L72 se quiser ver como funciona). Isso significa que ele sempre usa o minWidth do FileContent de empacotamento na prática.

Consertar isso não é complicado, mas não é realmente trivial e eu não tinha me convencido de que alguém estava realmente usando a funcionalidade em primeiro lugar, então não cheguei a fazer isso ... Uma opção, em vez de consertar, seria incluir alguns metadados extras / escolher um conjunto maior de elementos da interface do usuário para que preencha o espaço? Trapaça, eu sei, mas quero começar a transmitir a posição em que você está no arquivo de áudio, assim como transmitimos o conjunto de cartas selecionadas em um tabuleiro para que você possa ver onde outras pessoas estão em uma faixa (útil para, digamos, algum caso de uso de podcast imaginário?)

Fico feliz em usar qualquer uma das abordagens (consertar o bug de configuração de altura ou melhorar o AudioContent) e ajudar em qualquer uma das duas, se quiser. Deve ser um bom projeto pequeno de qualquer maneira.

Adicionar metadados / transmissão extras parece uma coisa legal de se trabalhar! Em quais arquivos devo procurar a lógica de transmissão de seleção de placa?

Oooo também, como você se sentiria em relação a comentários no estilo soundcloud vinculados a momentos específicos no áudio? Ou isso está duplicando muitas funcionalidades de threads? Acho que comentários de estilo específico de documento, por exemplo, como este (ou comentários em imagens com coordenadas XY como tags do instagram) podem permitir tipos interessantes de conversas específicas de mídia.

Eu me sentiria péssimo, sim . Comentários codificados por tempo devem obviamente ser armazenados no documento de alguma forma ... Conteúdo arbitrário? Isso é muito louco?

Para transmitir a posição de escuta, você pode enviar uma "Presença" que transmite sua id de usuário, id de dispositivo e um tipo codificável JSON extra arbitrário para seus pares. No BoardCard, você transmite sua cor de seleção para seus pares. Este código é um pouco estranho, eu sei, mas olhe para usePresence em https://github.com/automerge/pushpin/blob/73193adc907b3c7c109b5f14453f9a838469f02b/src/renderer/components/content-types/board/BoardCard.ts

Por 'Conteúdo arbitrário' você quer dizer um novo tipo de conteúdo (por exemplo, audioComments ) com um array de { comment: string, time: number, author: Contact} e o id de hypermergeUrl do áudio correspondente? Ou apenas um array de { comment: string, time: number, author: Contact} que está anexado ao próprio AudioContent ? É mesmo possível anexar JSON arbitrário a um hiperarquivo? Desculpe, ainda estou aprendendo como essa arquitetura funciona.

Quer dizer, poderíamos fazer os comentários de um tipo arbitrário, como ThreadContent, TextContent, ImageContent, etc.

(PS: se você não leu ARCHITECTURE.md, isso pode acelerar sua compreensão de como o sistema funciona nos bastidores.)

(movendo isso para a folga, já que viajamos muito longe da questão original)