- Lingkungan Wayland tradisional memiliki struktur di mana kompositor dan manajer jendela digabungkan dalam satu program, tetapi river 0.4.0 memisahkannya menjadi proses terpisah
- Protokol baru river-window-management-v1 memberi manajer jendela kendali penuh atas kebijakan seperti penataan jendela dan key binding, sambil tetap mempertahankan frame perfection dan performa
- Struktur ini bekerja tanpa latensi input, dan menjamin rendering yang rapi melalui pembaruan status atomik bahkan pada layout tiling yang kompleks
- Berkat struktur yang dipisahkan, manajer jendela dapat dikembangkan dan di-restart secara independen, serta mudah diimplementasikan dengan bahasa tingkat tinggi
- Pendekatan ini mendorong bertambahnya keragaman manajer jendela di ekosistem Wayland, dan river sudah mendukung lebih dari 15 manajer yang kompatibel
Struktur tradisional Wayland dan pendekatan pemisahan river
- Kompositor Wayland tradisional mengintegrasikan tiga peran display server, kompositor, dan manajer jendela ke dalam satu proses
- Display server merutekan event input dan mengirim buffer tampilan ke kernel
- Kompositor menggabungkan buffer dari beberapa jendela untuk menghasilkan tampilan akhir
- Manajer jendela menangani kebijakan pengguna seperti penataan jendela dan key binding
- Pada struktur X11, display server berjalan sebagai proses terpisah sehingga menimbulkan komunikasi bolak-balik yang tidak perlu dan latensi
- Wayland menyelesaikan hal ini dengan menggabungkan server dan kompositor, tetapi menggabungkan manajer jendela juga bukanlah keharusan
- river membongkar keterikatan ini dengan memisahkan manajer jendela menjadi program terpisah
Prinsip desain protokol river-window-management-v1
- Dirancang agar manajer jendela memiliki kendali maksimum sambil tetap mempertahankan keunggulan Wayland
- Tidak memerlukan komunikasi bolak-balik pada setiap frame atau event input, sehingga tidak ada latensi input
- Menjaga frame perfection: saat jendela baru dibuka atau ukurannya berubah, dijamin pembaruan layar tanpa celah atau tumpang tindih
- Rendering ditunda sampai semua jendela mengirim buffer baru, tetapi akan diproses dengan timeout jika melewati batas waktu tertentu
- Semakin baik implementasi aplikasi, semakin memungkinkan sinkronisasi frame yang sempurna
Struktur manajemen jendela berbasis state machine
- Protokol membagi status menjadi status manajemen jendela dan status rendering
- Status manajemen jendela: ukuran jendela, mode fullscreen, fokus keyboard, key binding, dan lain-lain
- Status rendering: posisi jendela, urutan, dekorasi, crop, dan lain-lain
- Perubahan diproses dalam pembaruan atomik (manage/render sequence)
- Kompositor memulai sequence, dan ketika tidak ada perubahan status, manajer jendela tetap dalam keadaan menunggu
- Struktur ini merupakan bentuk formalisasi eksplisit dari konsep yang sudah tersirat pada river-classic, sway, dan lainnya
Keunggulan struktur terpisah
- Pengembang manajer jendela dapat fokus pada kebijakan saja tanpa perlu mengimplementasikan seluruh kompositor
- Debugging dan restart lebih mudah, dan crash pada manajer jendela tidak menyebabkan sesi berakhir
- Tetap dapat berjalan tanpa penurunan performa meski ditulis dalam bahasa dengan garbage collection, tanpa latensi frame
- Sudah ada lebih dari 15 manajer jendela kompatibel river, dan diharapkan keragamannya bisa berkembang hingga setara X11
Keterbatasan dan rencana ke depan
- Saat ini protokol hanya mendukung lingkungan desktop 2D, belum mendukung VR dan sejenisnya
- Efek visual kompleks (misalnya jendela bergoyang) berada di luar cakupan, tetapi animasi sederhana dimungkinkan
- Dukungan custom shader sedang dipertimbangkan untuk masa depan, tetapi bukan rencana jangka pendek
- river 0.4.0 sudah cukup matang untuk penggunaan harian, dan peningkatan UX sebelum transisi ke versi 1.0.0 sudah direncanakan
- Untuk mendukung pengembangan berkelanjutan, diminta dukungan melalui liberapay, GitHub Sponsors, Ko-fi
Contoh dan galeri
- Disediakan berbagai contoh manajer jendela yang berjalan di atas river
- Canoe: manajer jendela stacking bergaya klasik
- reka: manajer jendela berbasis Emacs
- tarazed: lingkungan desktop yang berfokus pada konsentrasi
- rhine: manajemen jendela rekursif dan modular dengan dukungan animasi
- Selain itu, ada banyak manajer jendela kompatibel river lainnya
1 komentar
Komentar Hacker News
Sulit memahami keluhan terhadap Wayland (protokol) di komentar-komentar itu
Library seperti wlroots sudah menangani bagian yang berat, dan sekarang river menyediakan abstraksi tingkat lebih tinggi
Proyek Wayland mungkin saja bisa menyediakan abstraksi seperti ini lebih awal, tetapi menurut saya ini juga sesuatu yang bisa dilakukan siapa saja
Pada akhirnya kita mendapatkan perkembangan seperti ini secara gratis, jadi rasanya tidak perlu mengeluh hanya karena tidak ada orang lain yang mengerjakannya untuk kita
Masalah aksesibilitas juga dianggap sebagai risiko keamanan sehingga desainnya jadi sulit, dan sekarang saat kita memasuki era Agentic AI, ini tampaknya akan menjadi titik yang menarik
Pipewire memang sedang mengisi celah yang ditinggalkan Wayland, tetapi masih ada anggapan bahwa desainnya belum cukup ramah pengguna
Meski begitu, saya tetap merasa Wayland secara keseluruhan bergerak dua langkah maju walau sesekali mundur satu atau dua langkah
Sering kali responsnya seperti “ikuti cara saya atau pergi”, dan kurang fleksibel terhadap permintaan dari luar
Fakta bahwa ini disediakan gratis memang bagus, tetapi ketika Xorg dihentikan dan tidak ada alternatif, mendorongnya secara paksa terasa bermasalah
Melihat proyek ini, untuk pertama kalinya saya merasa Wayland bukan pemborosan waktu
Server display seharusnya tidak perlu ikut menangani manajemen jendela secara rumit
Sepertinya alasan awal Wayland menggabungkan window manager dan compositor hanyalah karena itu jalur dengan resistansi paling kecil
Namun akses jarak jauh masih tetap jadi masalah. Hal-hal yang berjalan baik di X11 sering penuh bug di Wayland
Wayland menyelesaikannya dengan integrasi, tetapi menimbulkan efek samping lain
Batas API-nya tertata rapi sehingga berbagi kode menjadi mudah
Saya penasaran apakah bug rotasi 90 derajat itu masalah di sisi compositor atau di wlroots
Menurut saya salah satu cacat desain Wayland baru sekarang mulai diperbaiki
Agar protokol umum benar-benar mapan dan window manager mencapai kematangan setingkat X11, sepertinya masih perlu 15 tahun lagi
Dan pada akhirnya seseorang mungkin akan berkata “saya akan membuat yang lebih baik”, meninggalkan Wayland, lalu memulai lagi dari nol
Setelah repot dengan masalah UEFI, akhirnya saya pindah ke Samsung DEX
Menurut saya batasannya bukan teknis, melainkan masalah politik
Sebagai pengguna Linux selama 25 tahun, setelah beralih ke Wayland 5 tahun lalu saya puas karena tidak lagi mengalami masalah screen tearing
Dari sudut pandang developer mungkin ada lebih banyak pekerjaan, tetapi sebagai pengguna ini jelas sebuah peningkatan
Kadang saya bertanya-tanya apakah saya akan terus membicarakan ini seperti orang-orang yang merindukan fitur lama CDE
River sudah hebat bahkan sebelum pemisahan ini. Saya menantikan perkembangannya ke depan
Saya sempat pindah ke Niri, tetapi suatu hari nanti saya berencana kembali
Jika Anda pengguna Xmonad, River sepertinya yang paling cocok
Saya penasaran apakah di River jendela baru dimasukkan di atas jendela yang sedang dipilih
Setelah dipisah, saya juga ingin tahu apa nama proyek di sisi window manager
Pada akhirnya kita hanya sedang menciptakan ulang fitur-fitur X11 satu per satu
Mungkin suatu hari nanti jendela Wayland akan bisa mengetahui posisinya sendiri
Sepertinya kita harus menunggu cukup lama lagi
Desktop kemungkinan akan dikuasai Android, ChromeOS, atau VM di atas Windows/macOS
Saya memakai River window manager yang sudah saya kustomisasi penuh
Di Hyprland secara default hanya bisa memakai tiling BSP, yang terasa tidak nyaman, sedangkan di River saya bisa membuat equal tiling sesuai keinginan
Pemisahan ini memberi perubahan besar pada workflow saya
Saya juga dulu pengguna i3, dan berkat hy3 saya bisa memakai Hyprland
Konfigurasi saya saya rangkum di dotfiles
Setahu saya salah satu desain inti Wayland adalah mengintegrasikan window manager dan compositor
Saya penasaran mengapa dirancang seperti itu
Wayland menanganinya secara sinkron untuk menghilangkan ketidaksesuaian visual
Protokol ini tampaknya merupakan upaya memisahkan server grafis dan window manager sambil tetap mempertahankan keuntungan performa itu
Saya merasa ketidakmampuan untuk dengan mudah mengganti window manager plug-in di Wayland adalah kerugian terbesar dibanding X11
Orang-orang yang berusaha menyelesaikan masalah seperti ini benar-benar berharga
Saya berharap layer seperti River atau Wayback bisa menjalankan peran itu
Saya juga punya ide desktop eksperimental, tetapi terpaksa memulai di X11 karena iterasinya bisa lebih cepat
Wayland masih punya kelemahan dari sisi desain
Standar tidak perlu memaksakan struktur tertentu
Saya sudah memakai i3 selama 15 tahun, dan setiap kali proyek seperti ini muncul saya bertanya-tanya mengapa Wayland diperlukan
X11 memang punya kekurangan, tetapi hampir semua yang saya inginkan tetap bisa dilakukan
Wayland selalu tampak membawa banyak friksi
Sebagai pengguna laptop itu nilai plus besar, dan dukungan VRR maupun HDR juga jauh lebih mudah dibanding X.org
Penyesuaian DPI per display, pencegahan screen tearing, dan pemblokiran perekaman layar aplikasi tanpa izin semuanya terselesaikan secara default
Saya tidak perlu lagi mengutak-atik Xorg.conf, dan kualitas hidup saya membaik
Sampai sekarang saya masih memakai rasio skala berbeda untuk tiap monitor
Saya membutuhkan fitur yang tetap menerima input meskipun jendela tidak aktif, dan hanya gerakan mouse yang bekerja sebagai pengecualian
Pada akhirnya saya menggantinya dengan Window Event, tetapi tetap terasa tidak nyaman