2 điểm bởi GN⁺ 2023-11-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • Kho lưu trữ này là một thử nghiệm mã đơn giản lấy cảm hứng từ tác phẩm của Björn Staal, đồng thời cung cấp liên kết để tìm hiểu thêm về ý tưởng gốc
  • Để chạy cục bộ, sau khi chạy npm i, mở 2 terminal: một để chạy server, terminal còn lại để chạy static server cho client
  • Chạy server bằng node server/server.js, và chạy client bằng cd client && http-server
  • Để xem thử nghiệm, mở 2 tab trình duyệt lần lượt tại localhost:8080?b=1localhost:8080?b=2
  • Kế hoạch trong tương lai bao gồm chế độ chỉ dùng localStorage, hỗ trợ số lượng cửa sổ không giới hạn và loại bỏ query trong URL, cùng việc chuyển sang WebRTC

Tổng quan dự án

  • Momciloo/fun-with-sockets là một dự án khám phá mã đơn giản lấy cảm hứng từ tác phẩm của Björn Staal
  • Thông tin thêm về ý tưởng gốc được liên kết tới bài đăng LinkedIn
  • README có kèm hình ảnh ghi lại màn hình thử nghiệm

Cách chạy cục bộ

  • Trước tiên cài đặt các dependency
    • npm i
  • Mở thêm một terminal nữa để sử dụng tổng cộng 2 terminal
  • Trong terminal thứ nhất, chạy server
    • node server/server.js
  • Trong terminal thứ hai, chuyển đến thư mục client rồi chạy static server
    • cd client && http-server
  • Trong trình duyệt, mở hai tab và dùng các giá trị query khác nhau
    • localhost:8080?b=1
    • localhost:8080?b=2

Ý tưởng trong tương lai

  • Dự định thêm flag để có thể chạy chỉ chế độ localStorage
  • Dự định có tùy chọn hỗ trợ số lượng cửa sổ không giới hạn và loại bỏ nhu cầu dùng query trong URL
  • Có kế hoạch chuyển hướng triển khai sang WebRTC

1 bình luận

 
GN⁺ 2023-11-26
Ý kiến trên Hacker News
  • Demo rất hay. Tò mò không biết nó sẽ hoạt động thế nào với nhiều màn hình
    Cũng thích việc tác giả chủ động thừa nhận rằng mình đã trực tiếp lấy cảm hứng từ người khác và ghi nhận nguồn gốc. Giá mà ngành phần mềm có nhiều người như vậy hơn

  • Có vẻ kiểu này hoặc cách tương tự sẽ hữu ích cho quản lý layer trong các chương trình vẽ như Krita, Inkscape, Gimp
    Có thể triển khai đơn giản bằng một bảng tab bên trong toàn bộ cửa sổ ứng dụng, và layer của tab được chọn sẽ trở thành layer đang hoạt động để chỉnh sửa

  • Nhớ là trước đây cũng đã có khá nhiều demo tận dụng vị trí và kích thước của cửa sổ. Cũng từng có một demo mô phỏng vật lý, không nhớ là chất lỏng hay nhiều vật rắn, nhưng có thể làm rơi vật thể từ cửa sổ này sang cửa sổ khác
    Có vẻ thậm chí không cần socket, chỉ cần kênh nhắn tin giữa các cửa sổ là được. Khi một cửa sổ mở cửa sổ con thì thường có quyền truy cập đặc biệt, khác với các tab/cửa sổ vốn bị cô lập với nhau, nên có vẻ cũng dễ làm một phiên bản chỉ chạy cục bộ

  • Nếu thích kiểu này thì WindowKill cũng có thể khá vui. Đây là một trò chơi điện tử giống Asteroids, dùng rất khéo nhiều cửa sổ chồng lấp và tương tác với nhau
    Bạn còn phải bắn cả viền cửa sổ, nếu không thì cửa sổ sẽ bị thu nhỏ. Về cuối game còn xuất hiện thêm các cửa sổ chứa boss địch
    Video chơi thử: https://youtu.be/7iP68FZWVxM

  • Liên kết tweet của tác phẩm gốc từ Bjorn Staal đã mất rồi, không biết có link nào để xem nó là gì không

  • Làm tôi nhớ tới một demo hay ho chơi Pong bằng các cửa sổ trình duyệt: http://stewd.io/pong/

  • Không rõ có ai giải thích được điều này có nghĩa là gì không. Tôi cũng không chắc mình đã hiểu đúng ảnh GIF trên trang GitHub chưa, trông như chỉ là các cửa sổ đang chia sẻ dữ liệu với nhau

    • Điểm cốt lõi không chỉ là các cửa sổ giao tiếp với nhau, mà là việc dùng API trình duyệt để lộ ra và khai thác tọa độ cửa sổ
    • Trông giống mô hình nhiều client với một server. Mỗi cửa sổ là một client riêng, gửi thông tin hình học trên màn hình lên server, rồi server trả về bố cục khác nhau cho từng client để nội dung trông như một đối tượng duy nhất trải dài qua nhiều cửa sổ
  • Hay thật. Có vẻ tự nhiên hơn nếu hình chữ nhật của cửa sổ đang được focus được vẽ ở trên cùng

    • Chắc là để cho thấy họ không chỉ đơn thuần dùng độ trong suốt
  • Nhưng tôi không hiểu vì sao lại có độ trễ. Chuyện này chẳng phải đủ đơn giản để xử lý ngay lập tức sao?

    • Vì nó chạy trong trình duyệt. Ngay cả giữa một lần di chuyển chuột đơn giản và một thay đổi tọa độ đối tượng đơn giản cũng có rất nhiều lớp hệ thống và ứng dụng chen vào để chuyển sự kiện tới mã được thông dịch hoặc biên dịch, rồi đẩy thay đổi trạng thái ra màn hình
      Ngay cả khi làm native thì việc khiến hai cửa sổ khác nhau luôn di chuyển giống hệt nhau ngay lập tức cũng không hề tầm thường. Ví dụ, từng có bài viết nói rằng một số GUI toolkit khiến việc thay đổi kích thước cửa sổ mượt mà là bất khả thi. Dù có tự làm mọi thứ, bạn vẫn phải hy vọng hệ thống đủ nhanh để thông báo cho cửa sổ và đẩy bitmap ra màn hình. Cách tốt hơn là dùng compositor phần mềm/phần cứng của toàn hệ thống, thêm các layer theo từng đối tượng rồi chỉ thay đổi tọa độ, nhưng ngay cả khi đó compositor cũng phải đủ tốt để xử lý cập nhật hơn 60/120/144 lần mỗi giây khi cần
    • Việc truy vấn vị trí cửa sổ đáng tiếc là chậm. Đây là đặc tính của tính năng trình duyệt
    • Tò mò không biết dùng postMessage API thay vì đi qua mạng có khiến nó tức thời hơn không
    • Việc giảm ưu tiên cho các cửa sổ hoặc tab chạy nền cũng có thể là một yếu tố
    • Có lẽ là do độ trễ mạng của WebSocket, và cá nhân tôi cũng từng thấy việc cập nhật vị trí cửa sổ đôi khi bị giật khựng một cách kỳ lạ
  • Đây là một cách dùng LocalStorage khá thú vị
    Tôi từng dùng cùng mẹo chia sẻ LocalStorage này để cập nhật cửa sổ đích khi cài đặt thay đổi ở một cửa sổ trình duyệt riêng. Chỉ cần lắng nghe sự kiện storage.onChanged để nhận cập nhật

    • Có vẻ cái này không dùng local storage. Cấu trúc của nó là server dựa trên WebSocket gửi cho các client vị trí của các box khác mỗi khi chúng di chuyển