Pushpin: FileContent-Einstellungskarte ist für jeden Dateityp gleich

Oh ja. Das ist ein bisschen dumm und definitiv meine Schuld. AudioContent war ein POC, das ich geschrieben habe und das nicht wirklich auf dem Master landen sollte, aber wir fusionierten, als wir Verbesserungen an der Unterstützung für das Streaming von Binärdateien testeten.

Das Problem ist, dass FileContent AudioContent im Wesentlichen umschließt, indem es das Mimetype-Feld der Hyperdatei betrachtet und dann basierend darauf einen Inhaltstyp auswählt (folgen Sie https://github.com/automerge/pushpin/blob/7b1fb02912198c525bf080edd5d14d48e538b729/src/renderer/components/ content-types/files/FileContent.tsx#L72, wenn Sie sehen möchten, wie es funktioniert). Das bedeutet, dass es in der Praxis immer die minWidth des umhüllenden FileContents verwendet.

Dies zu beheben ist nicht kompliziert, aber nicht wirklich trivial und ich hatte mich nicht davon überzeugt, dass jemand die Funktionalität tatsächlich nutzt, also bin ich nicht dazu gekommen ... Eine Möglichkeit, anstatt sie zu reparieren, wäre, dies zu integrieren ein wenig zusätzliche Metadaten / einen größeren Satz von UI-Elementen wählen, damit er den Raum ausfüllt? Betrug, ich weiß, aber ich möchte damit beginnen, die Position, an der Sie sich befinden, in der Audiodatei zu übertragen, so wie wir die ausgewählten Karten in einem Board übertragen, damit Sie sehen können, wo sich andere Leute in einem Track befinden (nützlich für z. ein imaginärer Podcast-Anwendungsfall?)

Gerne mit beiden Ansätzen (beheben Sie den Höheneinstellungsfehler oder verbessern Sie den AudioContent) und helfen Sie bei beiden, wenn Sie Lust haben, es anzugehen. Sollte so oder so ein schönes kleines Projekt werden.

Das Hinzufügen zusätzlicher Metadaten/Broadcasting klingt nach einer coolen Sache, an der man arbeiten kann! In welchen Dateien sollte ich nach der Übertragungslogik für die Kartenauswahl suchen?

Oooo auch, wie würdest du Kommentare im Soundcloud-Stil halten, die an bestimmte Zeiten im Audio gebunden sind? Oder dupliziert das zu viel Funktionalität von Threads? Ich denke, dokumentspezifische Stilkommentare wie diese (oder Kommentare zu Bildern mit XY-Koordinaten wie Instagram-Tags) könnten interessante Arten von medienspezifischen Gesprächen ermöglichen.

Ich würde mich wie die Hölle fühlen,

Um die Hörposition zu übertragen, können Sie eine "Anwesenheit" senden, die Ihre Benutzer-ID, Geräte-ID und einen beliebigen zusätzlichen JSON-kodierbaren Typ an Ihre Kollegen sendet. In BoardCard übertragen Sie Ihre Auswahlfarbe an Ihre Kollegen. Dieser Code ist ein bisschen seltsam, ich weiß, aber schau dir usePresence in https://github.com/automerge/pushpin/blob/73193adc907b3c7c109b5f14453f9a838469f02b/src/renderer/components/content-types/board/BoardCard.tsx an

Mit 'beliebiger Inhalt' meinen Sie einen neuen Inhaltstyp (zB audioComments ) mit einem Array von { comment: string, time: number, author: Contact} und der ID des hypermergeUrl des entsprechenden Audios? Oder nur ein Array von { comment: string, time: number, author: Contact} , das an das AudioContent selbst angehängt ist? Ist das Anhängen von beliebigem JSON an eine Hyperdatei überhaupt möglich? Tut mir leid, ich lerne noch, wie diese Architektur funktioniert.

Ich meine, könnten wir die Kommentare zu einem beliebigen Typ machen, wie ThreadContent, TextContent, ImageContent usw.

(PS: Wenn Sie ARCHITECTURE.md noch nicht gelesen haben, können Sie Ihr Verständnis der Funktionsweise des Systems hinter den Kulissen beschleunigen.)

(Verschieben Sie dies in einen lockeren Zustand, da wir ziemlich weit von der ursprünglichen Ausgabe entfernt sind)