HN veröffentlicht: Ich habe ein erstaunliches Experiment gesehen und eine einfache Version gebaut

 (github.com/Momciloo)
2 Punkte von GN⁺ 2023-11-26 | 1 Kommentare | Auf WhatsApp teilen
  • Dieses Repository ist ein von der Arbeit von Björn Staal inspiriertes einfaches Code-Experiment und enthält zusätzlich einen Link mit weiteren Informationen zur ursprünglichen Idee
  • Die lokale Ausführung erfolgt, indem man nach npm i zwei Terminals öffnet: eines für den Server und eines für den statischen Client-Server
  • Der Server wird mit node server/server.js gestartet, der Client mit cd client && http-server
  • Das Experiment lässt sich prüfen, indem man in zwei Browser-Tabs jeweils localhost:8080?b=1 und localhost:8080?b=2 öffnet
  • Zu den künftigen Plänen gehören ein reiner localStorage-Modus, Unterstützung für eine unbegrenzte Anzahl von Fenstern samt Entfernen der URL-Query sowie der Wechsel zu WebRTC

Projektüberblick

  • Momciloo/fun-with-sockets ist ein einfaches Code-Erkundungsprojekt, inspiriert von der Arbeit von Björn Staal
  • Weitere Informationen zur ursprünglichen Idee finden sich in diesem LinkedIn-Beitrag
  • Das README enthält eine Bildschirmaufzeichnung des Experiments

Lokale Ausführung

  • Zunächst die Abhängigkeiten installieren
    • npm i
  • Ein weiteres Terminal öffnen, sodass insgesamt 2 Terminals verwendet werden
  • Im ersten Terminal den Server starten
    • node server/server.js
  • Im zweiten Terminal in das Client-Verzeichnis wechseln und anschließend den statischen Server starten
    • cd client && http-server
  • Im Browser zwei Tabs öffnen und jeweils unterschiedliche Query-Werte verwenden
    • localhost:8080?b=1
    • localhost:8080?b=2

Künftige Ideen

  • Es ist geplant, ein Flag hinzuzufügen, mit dem nur der localStorage-Modus ausgeführt werden kann
  • Geplant ist eine Option, die eine unbegrenzte Anzahl von Fenstern unterstützt und die Notwendigkeit der Query in der URL entfernt
  • Es gibt den Plan, die Implementierung in Richtung WebRTC zu verlagern

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-26
Hacker-News-Kommentare

  • Coole Demo. Ich frage mich, wie das auf mehreren Monitoren funktionieren würde.
    Ich finde es gut, dass freiwillig offengelegt und als Quelle genannt wurde, dass man sich direkt von jemand anderem inspirieren ließ. Ich wünschte, es gäbe mehr solche Leute in der Softwarebranche.

  • Für die Layer-Verwaltung in Malprogrammen wie Krita, Inkscape oder Gimp könnte so etwas oder etwas Ähnliches nützlich sein.
    Man könnte das einfach als Tab-Panel innerhalb des gesamten Anwendungsfensters umsetzen und dafür sorgen, dass der Layer des ausgewählten Tabs zum aktiven Layer für die Bearbeitung wird.

  • Ich erinnere mich, dass es früher schon einige Demos gab, die Position und Größe von Fenstern genutzt haben. Es gab auch eine Physiksimulations-Demo; ich weiß nicht mehr, ob es Flüssigkeit oder mehrere feste Körper waren, aber man konnte Objekte aus einem Fenster in ein anderes fallen lassen.
    Es wirkt, als müsste man dafür nicht einmal Sockets verwenden und könnte es allein mit einem Nachrichtenkanal zwischen Fenstern umsetzen. Wenn ein Fenster ein Kindfenster öffnet, hat es normalerweise besondere Zugriffsrechte, anders als bei Tabs/Fenstern, die sonst voneinander isoliert sind, daher scheint auch eine nur lokal laufende Version leicht machbar.

  • Wenn man so etwas mag, könnte auch WindowKill Spaß machen. Das ist ein Asteroids-ähnliches Videospiel, das auf clevere Weise mehrere Fenster nutzt, die sich überlappen und miteinander interagieren.
    Man muss auch auf die Fenstergrenzen schießen, sonst schrumpft das Fenster. Später im Spiel erscheint sogar ein zusätzliches Fenster mit einem Boss-Gegner darin.
    Gameplay-Video: https://youtu.be/7iP68FZWVxM

  • Der Link zum Tweet des Originals von Bjorn Staal ist verschwunden, und ich frage mich, ob es einen Link gibt, unter dem man sehen kann, was das war.

  • Das erinnert mich an eine coole Demo, in der man Pong mit Browserfenstern spielt: http://stewd.io/pong/

  • Ich frage mich, ob jemand erklären kann, was das bedeutet. Ich bin mir nicht sicher, ob ich selbst das GIF auf der GitHub-Seite richtig verstanden habe; es sieht einfach so aus, als würden die Fenster Daten teilen.

    • Der Kern ist weniger, dass die Fenster miteinander kommunizieren, sondern dass über Browser-APIs Fensterkoordinaten offengelegt und genutzt werden.
    • Es wirkt wie eine Architektur mit mehreren Clients und einem einzelnen Server. Jedes Fenster ist ein eigener Client, sendet seine Bildschirmgeometrie an den Server, und der Server liefert pro Client ein anderes Layout zurück, damit der Inhalt wie ein einziges Objekt wirkt, das sich über mehrere Fenster erstreckt.

  • Cool. Es würde natürlicher wirken, wenn das Rechteck des fokussierten Fensters ganz oben gezeichnet würde.

    • Vielleicht wurde das so gemacht, um zu zeigen, dass nicht einfach nur Transparenz verwendet wurde.

  • Ich verstehe allerdings nicht, warum es Latenz gibt. Sollte das bei etwas so Einfachem nicht sofort reagieren?

    • Weil es im Browser läuft. Selbst zwischen einer simplen Mausbewegung und einer einfachen Änderung von Objektkoordinaten liegen viele System- und Anwendungsschichten, die das Ereignis an interpretierten oder kompilierten Code weiterreichen und Zustandsänderungen bis auf den Bildschirm bringen.
      Selbst nativ ist es nicht immer trivial, zwei unterschiedliche Fenster sofort identisch zu bewegen. Es gab zum Beispiel Berichte darüber, dass manche GUI-Toolkits flüssiges Ändern der Fenstergröße unmöglich machen. Selbst wenn man alles selbst baut, muss man darauf hoffen, dass das System leistungsfähig genug ist, Fenster schnell zu benachrichtigen und Bitmaps auf den Bildschirm zu schieben. Ein besserer Weg wäre, den software-/hardwareweiten Compositor des Systems zu verwenden, pro Objekt Layer hinzuzufügen und dann nur die Koordinaten zu ändern; aber auch dann muss der Compositor gut genug sein, um bei Bedarf mehr als 60/120/144 Aktualisierungen pro Sekunde zu schaffen.
    • Das Abfragen der Fensterposition ist leider langsam. Das ist eine Eigenschaft der Browser-Funktionalität.
    • Ich frage mich, ob es direkter wäre, ohne Netzwerk stattdessen die postMessage-API zu verwenden.
    • Dass Hintergrundfenster oder -tabs mit geringerer Priorität behandelt werden, könnte ebenfalls ein Faktor sein.
    • Wahrscheinlich liegt es an der Netzwerkverzögerung von WebSocket, und ich selbst hatte gelegentlich auch Fälle, in denen Aktualisierungen der Fensterposition seltsam ruckelig wirkten.

  • Ein interessantes Beispiel für den Einsatz von LocalStorage.
    Ich habe schon einmal denselben LocalStorage-Sharing-Trick verwendet, um ein Zielfenster zu aktualisieren, wenn sich Einstellungen in einem separaten Browserfenster geändert haben. Für Aktualisierungen muss man nur auf das Ereignis storage.onChanged hören.

    • Ich glaube nicht, dass hier lokaler Speicher verwendet wird. Es sieht eher nach einem WebSocket-basierten Server aus, der den Clients die Positionen der anderen Boxen sendet, sobald sie verschoben werden.