2 puntos por GN⁺ 2023-11-26 | 1 comentarios | Compartir por WhatsApp
  • Este repositorio es un experimento de código simple inspirado en el trabajo de Björn Staal, y también proporciona un enlace con más información sobre la idea original
  • Para ejecutarlo localmente, después de npm i hay que abrir 2 terminales: una para el servidor y otra para el servidor estático del cliente
  • El servidor se ejecuta con node server/server.js, y el cliente con cd client && http-server
  • Para probar el experimento, abre localhost:8080?b=1 y localhost:8080?b=2 en dos pestañas del navegador
  • Los planes futuros incluyen un modo solo localStorage, soporte para una cantidad infinita de ventanas y eliminación de los parámetros de consulta en la URL, además de migrar a WebRTC

Resumen del proyecto

  • Momciloo/fun-with-sockets es un proyecto de exploración de código simple inspirado en el trabajo de Björn Staal
  • Más información sobre la idea original está enlazada en esta publicación de LinkedIn
  • El README incluye una imagen de la grabación de pantalla del experimento

Cómo ejecutarlo localmente

  • Primero instala las dependencias
    • npm i
  • Abre una terminal adicional para usar un total de 2 terminales
  • En la primera terminal, ejecuta el servidor
    • node server/server.js
  • En la segunda terminal, entra al directorio cliente y luego ejecuta el servidor estático
    • cd client && http-server
  • En el navegador, abre dos pestañas usando valores de consulta diferentes
    • localhost:8080?b=1
    • localhost:8080?b=2

Ideas futuras

  • Se planea agregar una bandera para ejecutar solo el modo localStorage
  • Se planea una opción para soportar una cantidad infinita de ventanas y eliminar la necesidad de parámetros de consulta en la URL
  • Existe el plan de mover la implementación hacia WebRTC

1 comentarios

 
GN⁺ 2023-11-26
Comentarios de Hacker News
  • Excelente demo. Me pregunto cómo funcionaría con múltiples monitores.
    También me gusta que haya dicho voluntariamente que se inspiró directamente en otra persona y le haya dado crédito. Ojalá hubiera más gente así en la industria del software.

  • Creo que este enfoque, o algo similar, sería útil para la gestión de capas en programas de pintura como Krita, Inkscape o Gimp.
    Podría implementarse de forma sencilla como un panel de pestañas dentro de toda la ventana de la aplicación, haciendo que la capa de la pestaña seleccionada sea la capa activa para la edición.

  • Recuerdo que antes había bastantes demos que aprovechaban la posición y el tamaño de las ventanas. También había una demo de simulación física; no recuerdo si era de líquidos o de varios sólidos, pero permitía dejar caer objetos de una ventana a otra.
    Parece que ni siquiera harían falta sockets; bastaría con un canal de mensajes entre ventanas. Si una ventana abre una ventana hija, normalmente tienen permisos especiales de acceso entre sí, a diferencia de pestañas/ventanas que suelen estar aisladas, así que parece fácil hacer una versión solo local.

  • Si te gustan estas cosas, WindowKill también puede resultar interesante. Es un videojuego parecido a Asteroids que usa de forma ingeniosa varias ventanas que se superponen e interactúan entre sí.
    También tienes que disparar a los bordes de la ventana; si no, la ventana se encoge. Más adelante en el juego aparecen ventanas adicionales con jefes enemigos.
    Video de gameplay: https://youtu.be/7iP68FZWVxM

  • El enlace al tuit original de Bjorn Staal desapareció; me pregunto si hay algún enlace donde se pueda ver qué era.

  • Me recordó a una gran demo de Pong con ventanas del navegador: http://stewd.io/pong/

  • Me pregunto si alguien puede explicar qué significa esto. Tampoco sé si entendí bien el GIF de la página de GitHub; simplemente parece que las ventanas comparten datos.

    • La clave no es tanto que las ventanas se comuniquen entre sí, sino que se exponen y usan las coordenadas de las ventanas mediante la API del navegador.
    • Parece una arquitectura de varios clientes y un solo servidor. Cada ventana es un cliente individual; cuando envía al servidor la información de geometría de la pantalla, el servidor devuelve una disposición distinta para cada cliente, de modo que el contenido parezca un solo objeto extendido a través de varias ventanas.
  • Genial. Parecería más natural que el rectángulo de la ventana enfocada se dibujara encima de los demás.

    • Supongo que lo hicieron así para mostrar que no se trata simplemente de usar transparencia.
  • Pero no entiendo por qué hay retraso. ¿No debería ser algo lo bastante simple como para procesarse al instante?

    • Porque corre dentro del navegador. Incluso entre un simple movimiento del mouse y un simple cambio de coordenadas de un objeto, hay muchas capas del sistema y de la aplicación que intervienen para pasar el evento a código interpretado o compilado, y luego llevar el cambio de estado hasta la pantalla.
      Incluso en nativo, hacer que dos ventanas distintas se muevan de forma idéntica e instantánea no siempre es trivial. Por ejemplo, hubo textos sobre cómo algunos toolkits de GUI hacen imposible el redimensionamiento suave de ventanas. Aun si haces todo por tu cuenta, tienes que esperar que el sistema tenga rendimiento suficiente para avisar rápidamente a la ventana y empujar el bitmap a la pantalla. Una mejor forma sería usar el compositor de software/hardware de todo el sistema, agregar capas por objeto y luego cambiar solo las coordenadas; aun así, el compositor tendría que ser lo bastante bueno para manejar actualizaciones de 60/120/144 veces por segundo o más cuando haga falta.
    • Consultar la posición de la ventana lamentablemente es lento. Es una característica de la funcionalidad del navegador.
    • Me pregunto si usando la API postMessage en lugar de pasar por la red sería más inmediato.
    • Que las ventanas o pestañas en segundo plano tengan menor prioridad también podría ser un factor.
    • Probablemente sea por la latencia de red de WebSocket; personalmente también he visto que las actualizaciones de posición de ventanas a veces se sienten extrañamente a tirones.
  • Es un uso interesante de LocalStorage.
    Alguna vez usé la misma técnica de compartir LocalStorage para actualizar una ventana objetivo cuando cambiaba una configuración en otra ventana del navegador. Para actualizar, basta con escuchar el evento storage.onChanged.

    • Esto no parece usar almacenamiento local. Es una estructura con un servidor basado en WebSocket que envía a los clientes la posición de las otras cajas cada vez que se mueven.