Wayland kompozitörü ile pencere yöneticisinin ayrılması

• Geleneksel Wayland ortamlarında kompozitör ile pencere yöneticisi tek bir programda birleşik bir yapıdaydı; ancak river 0.4.0 bunu ayrı süreçlere ayırıyor
• Yeni river-window-management-v1 protokolü, pencere yöneticisine pencere yerleşimi, tuş atamaları gibi politika kararlarında tam yetki verirken frame perfection ve performansı koruyor
• Bu yapı girdi gecikmesi (latency) olmadan çalışıyor ve karmaşık döşemeli düzenlerde bile atomik durum güncellemeleri sayesinde temiz render alınmasını garanti ediyor
• Ayrık yapı sayesinde pencere yöneticisi bağımsız olarak geliştirilebiliyor ve yeniden başlatılabiliyor; ayrıca üst seviye dillerle uygulanması da kolaylaşıyor
• Bu yaklaşım Wayland ekosisteminde pencere yöneticisi çeşitliliğinin artmasını teşvik ediyor; river şimdiden 15'ten fazla uyumlu yönetici destekliyor

---

Wayland'ın geleneksel yapısı ve river'ın ayrıştırma yaklaşımı

• Geleneksel Wayland kompozitörleri görüntü sunucusu, kompozitör ve pencere yöneticisi olmak üzere üç rolü tek bir süreçte birleştiriyordu
  • Görüntü sunucusu girdi olaylarını yönlendirir ve görüntü tamponlarını çekirdeğe iletir
  • Kompozitör birden çok pencerenin tamponunu birleştirerek son ekran görüntüsünü oluşturur
  • Pencere yöneticisi ise pencere yerleşimi ve tuş atamaları gibi kullanıcı politikalarından sorumludur
• X11 yapısında görüntü sunucusu ayrı bir süreç olarak bulunduğundan gereksiz gidiş-dönüş iletişimi ve gecikme oluşuyordu
• Wayland bunu çözmek için sunucu ile kompozitörü birleştirdi, ancak pencere yöneticisini de mutlaka birleştirmek gerekmiyor
• river bu bağı çözerek pencere yöneticisini ayrı bir programa ayırıyor

river-window-management-v1 protokolünün tasarım ilkeleri

• Pencere yöneticisinin azami denetime sahip olmasını sağlarken Wayland'ın avantajlarını koruyacak şekilde tasarlandı
• Her karede veya her girdi olayında gidiş-dönüş iletişimi gerekmiyor, dolayısıyla girdi gecikmesi oluşmuyor
• Frame perfection korunuyor: pencere açıldığında ya da boyutu değiştiğinde boşluk veya çakışma olmadan ekranın güncellenmesi garanti ediliyor
  • Tüm pencereler yeni tamponlarını gönderene kadar render geciktiriliyor; ancak belirli bir süre aşılırsa zaman aşımıyla işleniyor
• Uygulama ne kadar iyi uygulanmışsa, tam kare senkronizasyonu da o kadar mümkün oluyor

Durum makinesi tabanlı pencere yönetimi yapısı

• Protokol durumu pencere yönetimi durumu ve render durumu olarak ayırıyor
  • Pencere yönetimi durumu: pencere boyutu, tam ekran olup olmama, klavye odağı, tuş atamaları vb.
  • Render durumu: pencere konumu, sırası, süslemeler, kırpma vb.
• Değişiklikler atomik güncellemeler (manage/render sequence) halinde gruplanarak işleniyor
• Diziyi kompozitör başlatıyor; durum değişikliği olmadığında pencere yöneticisi bekleme halinde kalıyor
• Bu yapı, mevcut river-classic ve sway gibi çözümlerde zaten bulunan kavramların açıkça biçimlendirilmiş hali

Ayrık yapının avantajları

• Pencere yöneticisi geliştiricileri tüm kompozitörü uygulamak zorunda kalmadan yalnızca politikalara odaklanabiliyor
• Hata ayıklama ve yeniden başlatma kolaylaşıyor; pencere yöneticisinin çökmesi oturumun kapanmasına yol açmıyor
• Çöp toplayıcılı dillerle yazılsa bile performans kaybı olmuyor, kare gecikmesi yaşanmıyor
• Şimdiden 15'ten fazla river uyumlu pencere yöneticisi var ve X11 düzeyinde bir çeşitlilik artışı bekleniyor

Sınırlamalar ve gelecek planları

• Mevcut protokol şu anda yalnızca 2D masaüstü ortamlarını destekliyor; VR gibi kullanım senaryoları desteklenmiyor
• Karmaşık görsel efektler (ör. sallanan pencereler) kapsam dışında, ancak basit animasyonlar mümkün
• Gelecekte özel shader desteği değerlendiriliyor, fakat bu kısa vadeli bir plan değil
• river 0.4.0 günlük kullanım için yeterli durumda ve 1.0.0 sürümüne geçmeden önce UX iyileştirmeleri planlanıyor
• Geliştirmenin sürmesi için liberapay, GitHub Sponsors, Ko-fi üzerinden destek çağrısı yapılıyor

Örnekler ve galeri

• river üzerinde çalışan çeşitli pencere yöneticisi örnekleri sunuluyor
  • Canoe: klasik bir stacking pencere yöneticisi
  • reka: Emacs tabanlı pencere yöneticisi
  • tarazed: odak odaklı masaüstü ortamı
  • rhine: özyineli, modüler pencere yönetimi ve animasyon desteği
• Bunların dışında da çok sayıda river uyumlu pencere yöneticisi bulunuyor

[GN⁺]

Hacker News görüşleri

• Yorumlardaki Wayland(protokol) hakkındaki şikâyetleri anlamakta zorlanıyorum
  wlroots gibi kütüphaneler zaten ağır işleri üstlendi ve artık river daha yüksek seviyeli soyutlamalar sunuyor
  Wayland projesi bu tür soyutlamaları daha erken sağlayabilirdi, ama bunun herkesin yapabileceği bir şey olduğunu düşünüyorum
  Sonuçta bu gelişmeleri bedavaya elde ediyoruz, başkası bizim yerimize yapmıyor diye şikâyet etmeye gerek yok bence

  • Sorunun başlangıcı, Wayland'in ilk dönemde ekran görüntüsünü yasaklama gibi ilkesel bir tutum almasıydı diye düşünüyorum
    Erişilebilirlik sorunları da güvenlik riski sayıldı, bu yüzden tasarım zorlaştı; şimdi de Agentic AI çağına girerken bunun ilginç bir nokta olacağını düşünüyorum
    Pipewire, Wayland'in eksik bıraktığı yerleri dolduruyor ama hâlâ kullanıcı dostu tasarımın yetersiz olduğu düşünülüyor
    Yine de Wayland'in bir iki adım geri gitse de genel olarak iki adım ileri gittiğini düşünüyorum
  • Şikâyetlerin asıl kaynağı bence Wayland topluluğu, özellikle de GNOME tarafının tavrı
    “Benim yolum ya da çık git” tarzı tepkiler çok oluyor ve dışarıdan gelen isteklere esnek yaklaşılmıyor
    Ücretsiz sunulması güzel ama Xorg durdurulmuşken ve alternatif yokken bunun zorla dayatılması sorunlu bence

• Bu projeyi görünce ilk kez Wayland'in zaman kaybı olmadığını hissettim
  Görüntü sunucusunun pencere yönetimini de ayrıca karmaşık biçimde üstlenmesi gerekmediğini düşünüyorum
  Wayland'in başlangıçta pencere yöneticisiyle compositör’ü birleştirmesinin nedeni muhtemelen sadece en az dirençli yol olmasıydı
  Ama uzaktan erişim hâlâ sorunlu. X11'de iyi çalışan şeyler Wayland'de bol hatalıydı

  • X11'de Xserver ile pencere yöneticisi ayrıldığı için ilk pencere yerleşimi gibi sorunları çözmek zordu
    Wayland bunu birleştirerek çözdü ama başka yan etkiler doğurdu
  • Küçük Wayland compositörlerinin çoğu wlroots veya smithay gibi kütüphaneler kullanıyor
    API sınırları iyi çizildiği için kod paylaşımı kolay
    90 derece döndürme hatasının compositör tarafında mı yoksa wlroots tarafında mı olduğunu merak ediyorum
  • X11'in uzaktan erişimi berbattı. Wayland'de EGL ya da Vulkan üzerinden daha temiz katmanlama yapılabildiği için aslında daha iyi olduğunu düşünüyorum
  • X11'de pencere yöneticisi dekorasyonlardan sorumluydu; bu yüzden ayırmak isterseniz mesajlaşma ve ayarlar karmaşıklaşıyor
  • Belki de masaüstü ortamları kendi ekosistemlerini kurarken merdiveni arkalarından çektiler

• Bence Wayland'in çeşitli tasarım kusurlarından biri ancak şimdi düzeltilmeye başlanıyor
  Ortak protokoller yerleşip pencere yöneticileri X11 düzeyinde olgunlaşana kadar bir 15 yıl daha gerekecek gibi
  Ve sonunda yine biri çıkıp “daha iyisini yapacağım” diyerek Wayland'i bırakıp sıfırdan başlayacak gibi görünüyor

  • Bu yüzden bugünlerde WSL ya da Virtualization Framework gibi şeylerin masaüstü Linux için gerçekçi çözüm olduğunu düşünüyorum
    UEFI sorunlarıyla uğraştıktan sonra sonunda Samsung DEX'e geçtim
  • Wayland yeniden yapılsa bile sonucun benzer olacağını düşünüyorum
    Sınırlar teknikten çok siyasi bir mesele

• 25 yıllık bir Linux kullanıcısı olarak, 5 yıl önce Wayland'e geçtikten sonra ekran yırtılması (tear) olmadan gayet memnunum
  Geliştirici tarafında daha çok iş çıkıyor olabilir ama kullanıcı olarak bu net bir iyileşme

  • Yine de window shading özelliğinin olmaması üzücü
    Eskiden CDE özelliklerini özleyen insanlar gibi ben de bunu yıllarca söyleyip duracak mıyım diye düşünüyorum

• River, ayrımdan önce de harikaydı. Bundan sonra nasıl gelişeceğini merakla bekliyorum
  Kısa süreliğine Niri'ye geçtim ama bir gün geri dönmeyi planlıyorum
  Xmonad kullanıcıları için River en uygun seçenek gibi görünüyor

  • Ben de Xmonad kullanıyorum ve Hyprland master/slave stack yapısını düzgün işleyemiyordu
    River'da yeni pencerenin o anda seçili pencerenin üstüne eklenip eklenmediğini merak ediyorum
    Ayrımdan sonra pencere yöneticisi tarafındaki projenin adının ne olacağını da bilmek isterim

• Sonuçta X11'in işlevlerini tek tek yeniden icat ediyoruz
  Belki bir gün Wayland pencereleri kendi konumlarını öğrenebilir

  • İdealistler hâlâ sanal 2D piksel ızgarasını bile açıkça tanımlamaya yanaşmıyor
    Muhtemelen daha epey beklemek gerekecek
  • Ama artık GNU/Linux'un büyük kısmı headless sunucular ya da gömülü sistemler için kullanıldığı için bunun çok önemi olmayabilir
    Masaüstünü Android, ChromeOS ya da Windows/macOS üstündeki VM'ler kaplayacak gibi görünüyor

• Ben tamamen özelleştirilmiş bir River pencere yöneticisi kullanıyorum
  Hyprland'de varsayılan olarak yalnızca BSP tiling mümkün olduğu için rahatsız oluyordum, River'da ise istediğim gibi eşit tiling yapabiliyorum
  Bu ayrım benim iş akışımı ciddi biçimde değiştirdi

  • Eşit tiling istiyorsanız hy3'e bakmaya değer
    Ben de eski bir i3 kullanıcısıydım; hy3 sayesinde Hyprland kullanabildim
  • Ben de Hyprland'de benzer sorunlar yaşadım ve sonunda Niri'ye geçip istikrarlı bir geliştirme ortamı buldum
    Ayarlarımı dotfiles içinde topladım
  • BSP'nin ne olduğunu sormak istiyorum

• Bildiğim kadarıyla Wayland'in temel tasarım kararlarından biri pencere yöneticisi ile compositör’ü birleştirmekti
  Neden böyle tasarlandığını merak ediyorum

  • Pencere yöneticisi ayrı bir süreçte asenkron iletişim kurarsa frame senkronizasyonu sorunları ortaya çıkıyor
    Wayland bunu eşzamanlı işleyerek görsel tutarsızlıkları ortadan kaldırıyor
  • Wayland, context switch sayısını en aza indirmek için her şeyi tek süreçte topladı
    Bu yeni protokol, performans avantajını korurken grafik sunucusu ile pencere yöneticisini ayırma girişimi

• Wayland'de tak-çıkar pencere yöneticilerini kolayca değiştirememek, X11'e kıyasla en büyük kayıp bence
  Bu sorunu çözmeye çalışan insanlar gerçekten çok değerli

  • On yıllardır aynı pencere yöneticisini kullanan biri olarak, tam bir ikame arayüz olmadan Wayland'e geçmek zor
    River ya da Wayback gibi katmanların bu rolü üstlenmesini umuyorum
  • Bu kısıt, yeni WM·DE geliştirme için de büyük bir engel
    Benim de deneysel masaüstü fikirlerim var ama hızlı yineleme yapabildiğim için mecburen X11 ile başlamak zorunda kalıyorum
    Wayland'in tasarımında hâlâ zayıf noktalar var
  • Aslında tek bir uygulamanın bile WM genişletme API'si sunması yeterli olabilir diye düşünüyorum
    Standardın belirli bir yapıyı zorlamasına gerek yok
  • İdeal olarak, kök Wayland sunucusunun altında kullanıcı başına Wayland sunucuları, onların içinde X11 sunucusu ve onun üstünde pencere yöneticisinin olduğu katmanlı yapı en temiz çözüm gibi görünüyor

• 15 yıldır i3 kullanıyorum; böyle projeler çıktıkça neden Wayland'e ihtiyaç duyulduğunu daha çok sorguluyorum
  X11'in kusurları var ama istediğiniz hemen her şeyi yapabiliyorsunuz
  Wayland ise hep sürtünme yaratıyor gibi görünüyor

  • Ben KDE 5 günlerinden beri Wayland kullanıyorum ve HiDPI ölçekleme gerçekten harikaydı
    Dizüstü kullanıcıları için büyük bir avantajdı; VRR ve HDR desteği de X.org'a kıyasla çok daha kolay
  • Kullanıcı açısından bakınca sadece çalışıyor
    Ekran başına DPI ayarı, ekran yırtılmasını önleme ve uygulamaların izinsiz ekran kaydı yapmasını engelleme gibi şeyler varsayılan olarak çözülmüş durumda
  • Ben de i3'ten sway'e DPI desteği yüzünden geçtim
    Artık Xorg.conf ile uğraşmak zorunda olmamak yaşam kalitesini artırdı
    Şu anda da monitör başına farklı ölçek oranları kullanıyorum
  • X11'de yüksek yenileme hızı ayarı hep sorunluydu
  • Son dönemde yaşadığım sorun, Wayland'in DeviceEvent desteklememesi oldu
    Pencere odakta değilken bile girdi alması gereken bir özelliğe ihtiyacım vardı, ama sadece fare hareketi istisna olarak çalışıyordu
    Sonunda Window Event'e geçtim ama hâlâ rahatsız edici