Sway’i bir şekilde çalıştırmak

WSL2’de Sway çalıştırmaya dair bir topluluk deposunu takip ederek taze bir Debian kurulumundan başladım. git kurmak, unable to locate package hatasıyla anında başarısız oldu — paket yöneticisinin önbelleği bomboştu. Taze bir kurulumda başka bir şey kurmadan önce bir kez apt update çalıştırmak bunu giderdi.

Deponun klonlanması sonra server verification failed: certificate signer not trusted hatasıyla başarısız oldu; bu, HTTPS trafiğini denetleyen ağımdaki bir proxy’ye bağlanıyordu. Proxy’nin kök sertifikasını Windows’tan dışa aktardım (certmgr.msc → Trusted Root Certification Authorities → Export as Base-64 .CER), .crt uzantısıyla /usr/local/share/ca-certificates/ içine kopyaladım ve update-ca-certificates çalıştırdım.

Sway açıldı — teknik olarak. Ekranda hiçbir şey görünmüyordu, ama Windows görev çubuğunda üzerine gelince tuhaf bir [WARN:COPY MODE] etiketi gösteren bir şey belirmişti. Bilinen, tamamen kozmetik bir WSLg görüntü hatası: PowerShell’den wsl --update, ardından wsl --shutdown, sonra yeniden başlatmak bunu giderdi.

Sonra hiçbir klavye kısayolu hiçbir işe yaramadı. Windows’un Windows tuşunu yakaladığını varsaydım. Gerçek neden daha basitti: kopyaladığım Sway yapılandırma dosyası tamamen bomboştu, yani varsayılanlar dahil hiçbir tuş ataması yoktu. Debian’ın gerçek varsayılan yapılandırmasını /etc/sway/config’den ~/.config/sway/config’e başlangıç noktası olarak kopyalamak sorunu tek hamlede çözdü.

Günlük kullanıma uygun hale getirmek

Sway gerçekten çalışır olunca, bir tarayıcıyla başlayarak günlük uygulamaları kurmaya başladım. Aynı sertifika sorunu, sonradan kurulan her tarayıcıda bağımsız olarak geri geldi, çünkü tarayıcılar işletim sistemi sertifika deposunu kullanmıyor — kendi depolarını tutuyorlar. Firefox’a sertifik doğrudan Settings → Privacy & Security → View Certificates → Authorities → Import yoluyla içe aktarılmalıydı, ya da alternatif olarak p11-kit-trust.so bir Güvenlik Aygıtı olarak yüklenip sistem deposunu otomatik okumasını sağlamalıydı. Ayrıca kurulmuş Chromium tabanlı bir tarayıcıya ise aynı sertifika, certutil -d sql:$HOME/.pki/nssdb ile (sürüme göre ~/.local/share/pki/nssdb) kendi NSS veritabanına içe aktarılmalıydı — git’teki işletim sistemi seviyesindeki düzeltme ikisini de kapsamıyordu.

İş için bir UML şema aracı tamamen bomboş gri bir pencere olarak açıldı — Java Swing/AWT uygulamalarının, Sway gibi non-reparenting döşeyen pencere yöneticileri altında hatalı çizildiği bilinen, uzun süredir var olan bir hata. Uygulamayı başlatmadan önce _JAVA_AWT_WM_NONREPARENTING=1 ortam değişkenini ayarlamak, ya da bunu kalıcı olarak ~/.bashrc’ye eklemek, sorunu düzeltti.

Terminal yazısı belirgin şekilde küçük görünüyordu, ama yalnızca dizüstünün dahili ekranında, harici bir monitörde değil. WSLg, özellikle Windows’un kesirli ölçekleme yüzdelerinde, ekran başına DPI ölçeklemesini güvenilir biçimde otomatik algılamıyor. Sway’in yapılandırmasında doğrudan açık bir çıkış başına ölçek faktörü belirlemek — output WL-1 scale 1.25, çıkış adı swaymsg -t get_outputs ile bulunarak — WSLg’nin kendi başına çıkaramadığını düzeltti.

Klavye düzeni destanı

Son proje ergonomiydi: daha iyi yazma konforu için Alman ergonomik klavye düzeni Neo2’yi açmak. Anında ters tepti — tek bir şey bile yazamaz oldum, çünkü Neo2, eski X11 uygulamalarının beklediğinden çok daha fazla shift seviyesi ve değiştirici kombinasyonu kullanıyor ve temel girişi bozuyordu. Klavyeye hiç dokunmadan kurtuldum: fareyle bir terminale sağ tıklayarak swaymsg input "type:keyboard" xkb_variant "" komutunu yapıştırdım, bu da anında düz Almancaya geri döndürdü.

Tam Neo2 yerine bir hibrit üzerinde karar kıldım: yalnızca Neo2’nin ergonomik harf konumları, sayılar, noktalama işaretleri ve AltGr sembolleri tam olarak standart Almanca bırakılmış olarak. Bunu, düzeni hafızadan tahmin etmek yerine gerçek Neo2 tanımını doğrudan kurulu klavye veritabanından (/usr/share/X11/xkb/symbols/de, neo_base bölümü) okuyan bir betikle oluşturdum, tam olarak eşleştiğinden emin olmak için.

İki düzen arasında geçiş yapması gereken bir kısayol sessizce hiçbir şey yapmadı. xkbcli compile-keymap --verbose ile gerçek nedeni bulmadan önce birkaç yanlış ize düştüm — yinelenen bir tuş ataması, gizli Windows tarzı satır sonları, odak varsayımları: compositor’ın klavye kütüphanesi, belgelerin ima ettiği şekilde özel düzenler için ~/.config/xkb’yi hiç aramıyordu. Bitmiş bir keymap dosyasını xkbcli compile-keymap --include ~/.config/xkb --include-defaults --layout de,mylayout > ~/.config/xkb/mykeymap.xkb ile önceden derleyip, düzeni canlı olarak çözmesini istemek yerine Sway’i giriş yapılandırmasında xkb_file ile doğrudan o dosyaya yönlendirmek bunu düzeltti.

Yalnızca-harfler sürümünü oluşturmak, aynı tuşlarda yaşayan AltGr özel karakterlerini — @ gibi — sessizce bozmuştu: bir tuşun sembol listesinin bir kısmını geçersiz kılmak, yalnızca belirttiğin seviyeleri değil, her seviye dahil tüm listeyi değiştiriyor. Çözüm, özel düzeni üretirken her tuş için standart Alman düzeninden AltGr seviyesindeki (3. seviye ve üstü) sembolleri çekip, yalnızca ilk iki seviyeyi tutmak yerine bunları yeni Neo2 harflerinin ardına eklemekti.

Tüm bunlardan sonra bile, özel düzen odak farklı bir pencereye her geçtiğinde sessizce düz Almancaya geri dönüyordu. Gerçek neden: WSLg’nin RDP tabanlı klavye köprüsü, her odak değişiminde etkin düzeni Windows’un kendi giriş diline göre yeniden eşliyor ve yalnızca Linux’un keymap’i içinde var olan bir düzen kavramına hiç sahip değil — Linux tarafından düzeltilebilecek bir şey değil, gerçek ve hâlâ açık bir WSLg platform sınırlaması.

Çözüm, sıfırlamayı önlemeye çalışmak yerine, pencereler arasında geçtikten sonra özel düzenin indeksine doğrudan geri dönmek için bağlanmış bir tuş — başka türlü neredeyse hiç uzanmadığım Insert’i kullandım. Yani gerçek günlük hareket şu: bir uygulamaya odaklanmak için Super+Sol ya da Super+Sağ, düzeni geri döndürmek için Insert, sonra yazmak. Tek temiz bir geçiş istediğim yerde üç tuş vuruşu. Ama bu özlemediğim bir tuş ve en baştan istediğim hibrit düzende yazıyorum — sadece artık küçük bir ritüeli var.