Présentation sur HN : j’ai vu une expérience étonnante et j’en ai créé une version simple

 (github.com/Momciloo)
2 points par GN⁺ 2023-11-26 | 1 commentaires | Partager sur WhatsApp
  • Ce dépôt est une expérimentation de code simple inspirée du travail de Björn Staal, avec un lien fournissant plus d’informations sur l’idée d’origine
  • Pour l’exécuter en local, il faut lancer npm i, puis ouvrir 2 terminaux : l’un pour le serveur, l’autre pour le serveur statique du client
  • Le serveur se lance avec node server/server.js, et le client avec cd client && http-server
  • Pour voir l’expérience, ouvrez localhost:8080?b=1 et localhost:8080?b=2 dans deux onglets de navigateur distincts
  • Les projets à venir incluent un mode uniquement localStorage, la prise en charge d’un nombre infini de fenêtres avec suppression des paramètres d’URL, et une migration vers WebRTC

Aperçu du projet

  • Momciloo/fun-with-sockets est un projet de simple exploration de code inspiré du travail de Björn Staal
  • Plus d’informations sur l’idée d’origine sont disponibles dans cette publication LinkedIn
  • Le README contient une capture vidéo de l’expérience

Exécution en local

  • Commencez par installer les dépendances
    • npm i
  • Ouvrez ensuite un second terminal pour en utiliser 2 au total
  • Dans le premier terminal, lancez le serveur
    • node server/server.js
  • Dans le deuxième terminal, placez-vous dans le répertoire client, puis lancez le serveur statique
    • cd client && http-server
  • Dans le navigateur, ouvrez deux onglets avec des paramètres de requête différents
    • localhost:8080?b=1
    • localhost:8080?b=2

Idées pour la suite

  • Ajout prévu d’un flag permettant d’exécuter uniquement le mode localStorage
  • Option prévue pour prendre en charge un nombre infini de fenêtres et supprimer le besoin de paramètres dans l’URL
  • Une migration de l’implémentation vers WebRTC est envisagée

À lire aussi

1 commentaires

 
GN⁺ 2023-11-26
Avis sur Hacker News

  • Super démo. Je me demande comment ça fonctionnerait avec plusieurs écrans.
    J’apprécie aussi qu’il ait spontanément indiqué s’être directement inspiré de quelqu’un d’autre et qu’il ait cité sa source. J’aimerais voir davantage de personnes comme ça dans le monde du logiciel.

  • Ce genre d’approche, ou une approche similaire, pourrait être utile pour la gestion des calques dans des programmes de dessin comme Krita, Inkscape ou Gimp.
    On pourrait l’implémenter simplement sous forme de panneau à onglets dans toute la fenêtre de l’application, et faire en sorte que le calque de l’onglet sélectionné devienne le calque actif pour l’édition.

  • Je me souviens qu’il y avait déjà pas mal de démos utilisant la position et la taille des fenêtres. Il y avait aussi une démo de simulation physique ; je ne me rappelle plus si c’était un liquide ou plusieurs solides, mais on pouvait faire tomber des objets d’une fenêtre à une autre.
    Il ne devrait même pas y avoir besoin de sockets : un simple canal de messages entre fenêtres pourrait suffire. Quand une fenêtre ouvre une fenêtre enfant, elle dispose généralement de droits d’accès particuliers, contrairement à des onglets/fenêtres normalement isolés entre eux, donc une version uniquement locale semble facile à faire.

  • Si vous aimez ce genre de choses, WindowKill pourrait aussi vous amuser. C’est un jeu vidéo proche d’Asteroids qui utilise intelligemment plusieurs fenêtres qui se superposent et interagissent.
    Il faut aussi tirer sur les bords des fenêtres, sinon elles rétrécissent. Plus tard dans la partie, des fenêtres supplémentaires contenant des boss ennemis apparaissent aussi.
    Vidéo de gameplay : https://youtu.be/7iP68FZWVxM

  • Le lien vers le tweet original de Bjorn Staal a disparu ; je me demande s’il existe un lien permettant de voir ce que c’était.

  • Ça me rappelle une démo sympa où l’on jouait à Pong avec des fenêtres de navigateur : http://stewd.io/pong/

  • Je me demande si quelqu’un peut expliquer ce que ça signifie. Je ne suis pas sûr d’avoir bien compris le GIF sur la page GitHub non plus ; on dirait simplement que les fenêtres partagent des données.

    • L’essentiel n’est pas tant que les fenêtres communiquent entre elles, mais que les API du navigateur exposent et utilisent les coordonnées des fenêtres.
    • Ça ressemble à une architecture avec plusieurs clients et un serveur unique. Chaque fenêtre est un client distinct ; elle envoie au serveur ses informations de géométrie d’écran, puis le serveur renvoie une disposition différente à chaque client, de sorte que le contenu donne l’impression d’être un seul objet réparti sur plusieurs fenêtres.

  • C’est chouette. Il me semblerait plus naturel que le rectangle de la fenêtre active soit dessiné au-dessus.

    • Je pense que c’est peut-être fait comme ça pour montrer qu’il ne s’agit pas simplement d’un effet de transparence.

  • Mais je ne comprends pas pourquoi il y a de la latence. À ce niveau, ça devrait être assez simple pour être traité instantanément, non ?

    • Parce que ça tourne dans le navigateur. Même entre un simple mouvement de souris et un simple changement de coordonnées d’objet, il y a beaucoup de couches système et applicatives qui transmettent l’événement au code interprété ou compilé, puis renvoient le changement d’état jusqu’à l’écran.
      Même en natif, faire bouger deux fenêtres différentes exactement en même temps et instantanément n’est pas toujours trivial. Par exemple, il y avait un article expliquant que certains toolkits GUI rendent impossible un redimensionnement fluide des fenêtres. Même si vous construisez tout vous-même, il faut espérer que le système soit assez performant pour prévenir rapidement la fenêtre et pousser le bitmap à l’écran. Une meilleure approche consiste à utiliser le compositeur logiciel/matériel global du système, à ajouter des calques par objet, puis à ne modifier que les coordonnées ; mais même là, il faut que le compositeur soit assez bon pour gérer, quand c’est nécessaire, plus de 60/120/144 rafraîchissements par seconde.
    • La consultation de la position des fenêtres est malheureusement lente. C’est une caractéristique des fonctionnalités du navigateur.
    • Je me demande si ce serait plus immédiat en utilisant l’API postMessage plutôt qu’en passant par le réseau.
    • Le fait que les fenêtres ou onglets en arrière-plan aient une priorité réduite peut aussi jouer.
    • C’est probablement dû à la latence réseau de WebSocket, et j’ai moi aussi déjà vu les mises à jour de position des fenêtres saccader bizarrement par moments.

  • C’est un usage amusant de LocalStorage.
    J’ai déjà utilisé la même technique de partage via LocalStorage pour mettre à jour une fenêtre cible lorsque des paramètres changeaient dans une autre fenêtre du navigateur. Pour la mise à jour, il suffit d’écouter l’événement storage.onChanged.

    • Il ne semble pas que cela utilise le stockage local. C’est une architecture avec un serveur basé sur WebSocket qui envoie aux clients la position des autres boîtes à chaque fois qu’elles bougent.