TUI'lerin Neden Geri Döndüğü
(wiki.alcidesfonseca.com)- TUI'ler anlık geri bildirim, otomasyon kolaylığı ve işletim sistemleri arasında çalışabilme sayesinde yeniden öne çıkıyor; Claude ve Codex gibi araçlar da komut satırında büyük başarı yakaladı
- Windows, Linux ve macOS'taki yerel GUI'ler; sırasıyla tutarsız API stratejileri, araç takımı ve ortam parçalanması, geçmiş yönergelerle uyumun zayıflaması nedeniyle hem geliştiriciler hem de kullanıcılar için yükü artırıyor
- Electron uygulamalarında asıl sorun bellek kullanımı değil, görsel tutarlılık eksikliği ve klavye odaklı iş akışlarındaki boşluklar; menü ve kısayol entegrasyonu da zayıflamış durumda
- Google'ın Flutter UI girişimi ve Zed'in GPUI'si gibi yeni UI yığınları oluşturma çabaları oldu, ancak işletim sistemi entegrasyonu zayıfsa hızlı bir renderer tek başına yeterli olmuyor
- İyi bir arayüzün özü, kullanıcının daha az düşünmesini sağlayan tutarlılık; geliştiriciler ile işletim sistemi ve araç takımı üreticileri UI kuramına ve erişilebilir araç takımlarına daha fazla yatırım yapmalı
TUI'lerin yeniden öne çıkmasının arka planı
- DHH'nin Omarchy projesi, TUI, web uygulaması ve gnome tarzı yerel uygulamaların karışımından oluşuyor; TUI ise anlık geri bildirim ve “geek points” için kullanılıyor
- Yaklaşık 10 yıl önce kod editörlerinde de benzer bir eğilim vardı
- BBEdit, Textmate, Notepad++, Sublime gibi yerel editörlerden Atom, VSCode ve bunların türevleri gibi Electron tabanlı uygulamalara geçildi
- Güçlü tercihlere sahip kullanıcılar vim ya da emacs'e yöneldi; anlık geri bildirim ve yüksek kullanılabilirlik elde ettiler ama bunun karşılığında çok dik bir öğrenme eğrisini kabul etmek zorunda kaldılar
Yerel GUI'lerin zayıflama nedenleri
-
Windows
- Windows, tutarlı bir GUI kütüphanesi stratejisi oluşturamadı; bir API başarıya ulaşmayınca bir yenisini üretme döngüsünü tekrar etti
- Jeffrey Snover, Microsoft hasn’t had a coherent GUI strategy since Petzold yazısında MFC, OLE, COM ve ActiveX'in Windows geliştirme ekosisteminin geneline karmaşıklık yaydığını söylüyor
- Microsoft daha sonra WinForms, WPF, Silverlight, WinUI ve MAUI'yi denedi, ancak bunlar başarılı olamadı; birçok kurumsal ve bireysel masaüstü uygulaması hâlâ Electron uygulamalarına dayanıyor
- Windows'un görsel olarak tutarlı biçimde bütünleşik olduğu son dönem, Windows 98 ya da Windows 2000'e daha yakın bir zamandı
- Domenic Denicola, Windows Native App Development Is a Mess yazısında, birkaç yılda bir işletim sistemi ve UI API'lerini yeniden üretmenin maliyetinin yüksek olduğunu; sandboxing ve özellik kaldırma girişimlerinin de buna eklenmesiyle her yeni katmanda önceki çerçevelerde yapılabilen bazı işlerin artık yapılamadığı boşluklar oluştuğunu savunuyor
-
Linux
- Linux'taki UI tutarsızlığı, büyük ölçüde tasarımın doğal bir sonucu; farklı ekipler farklı hedeflerin peşinden gitme özgürlüğüne sahipti
- GTK ve Qt başlıca çerçeveler hâline geldi; ikisi de çapraz platform yerel geliştirmeyi hedeflese de en yaygın kullanımları esas olarak Linux tarafında kaldı
- Farklı araç takımlarıyla yapılmış Linux uygulamaları yan yana geldiğinde yine de bir dereceye kadar uyumlu görünebilir, ancak Windows'taki çok sayıdaki çerçeve bu düzeyde bir uyum yakalayamıyor
- Dağıtım, masaüstü ortamı ve donanım kombinasyonları çok fazla olduğu için test etmek zor; bu yüzden birçok şirket yerel Linux uygulaması geliştirmiyor
- Şirketler genelde Linux desteğini Electron üzerinden veriyor ya da açık bir API varsa bunu açık kaynak topluluğunun çözmesine bırakıyor
-
macOS
- Apple'ın Human Interface Guidelines, dünya çapında kullanıcı arayüzü derslerinde alıntılanacak kadar güçlü bir ölçüttü
- Xerox PARC ve Apple, iyi bir insan-bilgisayar arayüzünün ne olduğuna dair araştırmalarıyla öne çıkan kurumlar arasında sayılıyor
- Son dönemde Apple, geçmiş yönergelerle olan tutarlılığı bozan bir yöne ilerliyor
- macOS; Fitts yasasını göz ardı ediyor, pencere yeniden boyutlandırmayı neredeyse imkânsız hâle getiriyor, düzeltme girişimlerinden sonra bile sorunları sürdürüyor ve tüm menülere simge ekliyor
- macOS artık tasarımcıların huzur içinde çalışabileceği güvenli bir bölge olarak görülmekte zorlanıyor
Electron uygulamalarının sınırları
- En sık dile getirilen sorun bellek kullanımı, ancak son 10 yılda bellek kullanımı aslında düşme eğilimindeydi
- Daha büyük sorun, görsel tutarlılık eksikliği ve klavye merkezli iş akışlarının yetersizliği
- 64GB RAM'li bir MacBook Pro kullanılan bir ortamda bile Dock'ta 8 yerel uygulama ile 6 Electron uygulaması birlikte bulunuyor
- Yerel uygulamalar: TextMate ve macOS sistem yardımcı programları
- Electron uygulamaları: Slack, Discord, Mattermost, VSCode, Cursor, Plexamp
- Cursor ve VSCode gibi uygulamalarda, ajan panelinden bir özellik istedikten sonra yalnızca klavyeyle yan paneldeki ajan listesine geçmek ya da öğeleri arşivlemek doğal hissettirmiyor
- Oysa bu tür işlemler tüm macOS uygulamalarında aynı şekilde yapılabilmeli; ancak kısayol olsa bile bazen menüde gösterilmiyor
- Son 10 yılda geliştiriciler, uygulamada yapılabilen işlemleri menülere de eklemeyi giderek unutur oldu; bu da uygulamaların sandbox içindeki HTML olarak uygulanması yapısıyla bağlantılı
- Slack bu konuda diğer Electron uygulamalarından daha iyi iş çıkarıyor, ama o da kusursuz değil
Yeni UI yığınını yeniden kurma girişimleri
- Google, Dart ile birlikte Android mirası taşımayan yeni bir işletim sistemi ve yeni cihazlar için yeni bir UI araç takımı oluşturmak istemişti
- Google, Flutter UI adlı yeni bir UI araç takımı istiyordu, ancak gerçek ürün piyasaya çıkmadan projeden vazgeçti
- Bu tür girişimler ancak tekel benzeri bir konum ya da yeterince büyük bir pazar payı varsa başarılı olabilir
- Zed, Rust ile benzer bir yol seçerek kendi GPU renderer kütüphanesi olan GPUI'yi geliştirdi; bu kütüphane çapraz platformu hedefliyor
- GPUI hızlı olsa da barındırıcı işletim sistemiyle entegrasyonu tek başına yeterli değil; geliştiricilerin ihtiyaç duydukları binding'leri kendilerinin eklemesi gerekiyor
- Hızlı bir renderer yerine işletim sistemiyle iyi bütünleşen daha yavaş bir renderer tercih edilmeli
TUI'nin doldurduğu boşluk
- Apple Automator'ın gerilemesini hatırlatan bir bağlamda, TUI yeniden otomasyona uygun bir arayüz olarak önem kazanıyor
- TUI, uzaktan çalıştırma açısından da görece kolay; baş ağrıtan X forwarding'e bağımlı kalmak gerekmiyor
- Yerel UI araç takımları başarısız olduğunda insanlar temele dönüyor ve bunun sonucunda TUI bir seçenek olarak öne çıkıyor
- Claude ve Codex komut satırında büyük başarı elde etti; kullanıcılar da çevredeki işletim sistemine odaklanmak yerine etkileşimin kendisine yoğunlaşabiliyor
- TUI ile buluttaki makinelerde kod ve uygulamalarla çalışmak ya da iPad'den GPU'lu bir makineye uzaktan bağlanmak mümkün
- TUI, tüm uygulamaların birbirinden farklı göründüğü bir ortamda Apple ve Microsoft'un bıraktığı boşluğu dolduruyor
- Farklı görünümler sanat ya da bilgisayar oyunları için iyi olabilir, ancak arayüzün geri çekilip kullanıcının kendi işini yapmasına alan açması gereken amaçlar için uygun değil
Bundan sonra gereken yön
- John Loeber, Bring Back Idiomatic Design yazısında, onay kutusunun bile sistemle etkileşim kurmak için bir arayüz olduğunu ve iyi bir arayüzün kullanıcıyı daha az düşündürdüğünü savunuyor
- Kullanıcılar çok sayıda şeyle etkileşime girer; bu nedenle tutarlı bir deneyim sunan homojen arayüzlere ihtiyaç vardır
- Command+C kopyalama kısayoluysa her yerde çalışmalı; belirli durumlarda ayrıca CTRL+Shift+C ya da sağ tık → kopyala gibi seçenekleri hatırlamak zorunda kalmak rahatsız edicidir
- Tüm geliştiriciler yalnızca yazılımı değil, genel olarak iyi kullanıcı arayüzleri üretmeye yarayan kuramı da öğrenmeli
- Kullanıcı deneyimi tasarımını, yazılım mühendisliği eğitiminde önemsiz bir soft skill gibi gören yaklaşım sona ermeli
- Hangi süreç olursa olsun UI anlaşılmıyorsa proje başarısız sayılmalı; HCI derslerinde de hedef kusursuz UI olmalı
- İyi bir UI üretmenin büyük kısmı ihtiyaçları anlamaya dayanır; programlamanın kendisi ise artık zaten otomatikleşiyor
- İşletim sistemi ve araç takımı üreticileri, geliştiricilerin gerçekten kullanmak isteyeceği erişilebilir araç takımlarına yatırım yapılmasını sağlamalı ve giriş engellerini düşürmeli
- Burada mutlaka çapraz platform desteği savunulmuyor, ancak böyle en az bir çözümün varlığı bile Electron ve TUI bağımlılığını azaltmaya yardımcı olabilir
4 yorum
Ben de öyle düşünüyorum; ancak bana göre geliştirici dünyası modaya gereğinden fazla duyarlı. TUI'ye esasen düzgün bir GUI yapma becerisi ya da isteği olmayan şirketler öncülük ediyor, ama TUI'yi gerçekten kaç kişinin kullandığını bilmiyorum.
Hacker News yorumları
Sadece sayılara bakarsak, TUI’nin popüler olmasının asıl nedeni Claude Code ve geri kalanlar onun yanında arka plan gürültüsü gibi kalıyor diye düşünüyorum
İlk kez TUI yapmak istememin nedeni, uygulamayı SSH üzerinden sunma fikriydi. SSH uygulamaları, yerel kurulum gerektirmemeleri bakımından tarayıcıya benziyor
https://pico.sh ile uğraşmayı eğlenceli kılan büyük neden de, TUI dağıtımında kullanıcı müdahalesinin hiç gerekmemesi
Muhtemelen bunun nedeni, ağır tarayıcı tabanlı arayüzlerden kaçma isteği ve terminal render etmenin sınırlarını test etme merakı
Yeni ve ilginç teknolojilerle yeni sistemler kurmak yerine GPU hızlandırmalı daktilo emülatörleri yapıyoruz. Nostalji ile teknik körlüğün karıştığı tuhaf bir durum
SSH üzerinden her türlü protokolü taşıyabilirsiniz. Keşke bunun yerine uzak bitmap ekranlara çizim yapma yönüne gidilse
X Window mükemmel tasarlanmamıştı ama ağ şeffaflığı vardı; Plan 9’daki devdraw ise uzak grafik programlarının varlıkları yükleyip çizgi çizme komutlarını RPC ile gönderdiği bir render motoruydu
vim’de gerçekten zor olan tek şey, modal düzenleyicinin en temel hareketi olan komut moduna dönüş için parmakları Escape’e kadar uzatmak zorunda olmak
İdeal akış hızlıca düzenleme yapıp anında komut moduna dönmek ama Escape kullanımı tarihsel bir kalıntı, bunu kabul etmek lazım
Bu yüzden CapsLock’u sistem genelinde Escape olarak yeniden eşlemek yeterli. Linux ve macOS’ta sadece GUI ayarlarıyla yapılabiliyor; Windows’ta da bir registry anahtarı oluşturup ya da değiştirip 1 dakikada hallediliyor
Bunun dışında temel için vim-tutor yeterli; zaman alan bir iş çıktığında bakıp öğrenirsiniz, o yüzden öğrenme eğrisinin tam olarak nerede olduğunu pek bilmiyorum. Asıl sorun, modal düzenlemeye fazla hızlı alışıp onun olmadığı ortamların taş devri gibi gelmeye başlaması
Hatta bugün vim’de hjkl’nin gerekli olmasının gerçek nedeni, klavye düzeninin ok tuşları için kötü olması diye düşünüyorum. Daktilolarda ok tuşları yoktu ama bilgisayarda ok tuşları temel şeylerden biri
Boşluk tuşunun o kadar büyük olması da gerekmiyor, iki başparmağın birden kullanmasına da gerek yok. Küçük bir ok tuşu kümesini boşluk tuşunun soluna ya da sağına taşımak çok daha iyi olurdu
hjkl hilesi sadece hacker editörlerinde işe yarıyor ama genel yazılımlarda da ok tuşları çok kullanılıyor ve bugünkü düzen eller için çok kötü. Tüm eli oynatmadan başparmakla ok tuşlarına basmaya çalıştığım için iltihaplanma yaşamaya başladım
Eli kaldırıp home row’dan çıkmaya ve sonra geri dönmeye zorluyor; böylece aksi halde durup dururken birikecek RSI puanlarını azaltıyor
Aynı nedenle diğer elimle de sık sık ok tuşlarını kullanıyorum. Tabii hjkl’yi de epey kullanıyorum
https://github.com/microsoft/PowerToys
jjolarak eşleyip geçinAyrıca
Ctrl + [standart terminal/ASCII’de Esc demek, bu yüzden Esc’ye uzanmaktan biraz daha rahat olabilirİşletim sistemi üreticilerinin kendi çıkarları çökerken geriye kalan küller TUI modası gibi görünüyor
İyi bir genel amaçlı UI yok. Tarayıcı en iyisine en yakın olanı ve oldukça başarılı ama sandbox nedeniyle yerel dosya ya da ağ erişimi gerektiren işlerde uygun değil ya da sürtünmesi yüksek. Basit bir şeyi çalıştırmak için de saçma derecede fazla ek yük getiriyor
Uzaktan erişim daha da kötü. Windows ana makinede çalışan bir uygulamaya Mac’ten erişip erişemeyeceğiniz, bunu tünellenmiş bağlantı üzerinden yönlendirebileceğiniz gibi sorunlar çıkıyor
TUI, ihtiyaç duyulan şeyi yapan basit bir genel amaçlı protokol ve uzak erişim bunun doğal parçası. Yerelde kullandığınız şey SSH bağlantısı üzerinden de doğal şekilde çalışıyor
Aynı ekosisteme kilitlemek ya da her şeyi uyumsuz hale getirmekle kazanacağını sanan işletim sistemi üreticilerine büyük bir orta parmak aynı zamanda
Notcurses ve Ratatui, ncurses ekosistemine çok şey kattı
Windows 11 bunun çok iyi bir örneği; o kadar şatafatın hiçbiri gerçekten gerekli değil
Keşke TUI geri dönmeseydi. Her gün TUI yerine web arayüzünü seçerim
Aşırı akıllı fontlar kurmak zorunda değilsiniz, düzgün görünmesi için terminal ayarlarıyla oynamak zorunda değilsiniz, yapan kişinin en iyi sandığı gezinme kısayollarını tahmin etmek zorunda değilsiniz
İşletim sisteminin standart metin gezinmesini destekleyen gerçek metin düzenleme, parola yöneticileri ve metin genişleticilerle daha iyi entegrasyon da var
CLI içinde yaşıyorum ve tek kısayolla terminal açıyorum ama terminalin tek seçenek olduğu dönemden beri teknoloji çok ilerledi ve UI yapmak için daha iyi seçenekler var
Bu TUI akımının tamamı bana sadece bir moda trendi gibi görünüyor
Çünkü kimse native UI geliştirmeye yatırım yapmıyor. Electron, şirketlerin kullanımı kolay bir GUI yığını olsa onu benimseyeceğinin kanıtı
Büyük bir uygulamada paketleme ve dağıtıma harcanan zaman toplamın küçük bir kısmıdır, dosya boyutu da pek önemsenmez; ama küçük uygulamalarda öyle değil
Windows için uygulama yapmak kolay; küçük bir binary formu açar, çift tıklamayla çalışır ve kurulum gerekmez
Linux’ta aynısını yapmak istediğinizde GTK ya da Qt’nin kurulu olduğunun garantisi yok, bu yüzden bağımsız çalıştırılabilir yapmak istiyorsanız fiilen işletim sisteminin tamamını yanında göndermeniz gerekiyor. Bu da dosya boyutunu büyütüyor
Python da sorunlu; ya Windows kullanıcısında Python olacak ya da yorumlayıcıyı da birlikte göndereceksiniz
Geriye uygulanabilir seçenek olarak Java’daki gibi tek bir
.jardosyasını her sistemde çalıştırma yaklaşımı kalıyor ama Oracle lisansı değiştirdi ve JavaFX artık Java’ya dahil değil. Swing hâlâ dahilBen sadece klavye kısayolları olan bir menü çubuğu göstermek istiyorum; neden tüm işletim sistemlerinde menü çubuğuna erişim sağlayan bir menü çubuğu VM’i yok, anlamıyorum
Electron ile tüm tarayıcıyı birlikte göndermek aptalca. Kullanıcılar, Flash’ın masaüstü uygulama sürümü gibi bir platform kurmalı ve tüm uygulamalar onu kullanmalıydı
DOS oyunu dağıtmak masaüstü uygulaması dağıtmaktan daha kolay bile olabilir. Çünkü DOS oyunu çalıştırmak isteyen kişi büyük ihtimalle DOS emülatörünü zaten kurmuştur
Gereken şey; kullanımı kolay, çapraz platform, açık kaynak ve mümkünse seçtiğiniz programlama dilinden kullanılabilen bir framework
Daha büyük sorun insan kaynağı. Web geliştirmeyi bilen insan çok; bu yüzden o kadroyu masaüstünde de kullanmak istiyorsunuz ve masaüstü JavaScript olan Electron ile bu çok daha kolay oluyor
GUI benzeri şeyleri yeniden yapmaya çalışan terminal UI’larını pek anlayamıyorum. Bilgisayar arayüzlerinin daha iyiye gitmesi gerekmiyor mu
Artık çizgi ve şekil çiziyormuş gibi yapmak için karakter ızgarasına mahkûm olmak zorunda değiliz. Kitty ya da iTerm gibi standart dışı terminaller olmadan görüntü bile gösteremiyorsunuz
İyi bir çapraz platform akış tabanlı UI sistemi olmaması üzücü. Web kendi çapında harika ama bu amaç için kesinlikle daha iyi bir şey olabilir. Flutter fena değil ama isteğe bağlı kullanım açısından zayıf ve Dart’a fazla bağlı
İnsanlar GUI istiyor ama sonunda TUI içindeki GUI benzeri çözümlere dolanmak zorunda kalıyor
Taşınabilir, uzaktan çalıştırılabilir, soket açığa çıkarmadan daha güvenli şekilde çalışabilen ve tüm masaüstünü ayağa kaldırmadan kullanılabilen bir şey istiyorlar
Rootless pencere sistemi fiilen öldü; geriye web arayüzleri ve onların tüm sorunları ya da herkesin zaten sahip olduğu SSH bağlantısıyla çalışan TUI kaldı
Eskiden Tcl/Tk ile hızlıca bir şey yapıp X Window ile pencere açabiliyordunuz ama bugün o kadar kolay değil, zaten uzaktan X kullanan da yok
En küçük ortak payda SSH ve ona uyan şeyler hayatta kalıyor
Desteklemediği söylenen terminallerin çoğu da GNOME VTE tabanlı ve o taraftaki destek üzerinde çalışılıyor; hata takipçisine bakınca neredeyse bitmiş gibi görünüyor
X11’de en standart terminale en yakın şey olan xterm de buna dahil
[0] https://www.arewesixelyet.com/
Sağlam ve güvenilir bir GUI toolkit’i de yok; hepsi farklı bug’lar ve tuhaflıklarla dolu
Flutter iyi olabilir ama Flutter ile uygulama derleme sürecinin başlı başına kâbus olduğunu görmezden gelmeniz gerekiyor. Flutter da sanki herkesin derleyebilmesi için tasarlanmamış gibi; pratikte bunu dağıtımlar gizliyor
Ayrıca web tabanlı UI’lar illa ağır olmak zorunda değil. HN’de olmadığı gibi
Sürekli terminal açık tutan, hayatını Bash script’leriyle otomatikleştiren, VIM/TMUX kullanan biri olarak bile TUI’lerin çoğu iyi bir GUI’nin iki adım gerisinde
Gelişigüzel gezinme ve kısayollar, bozuk kopyala-yapıştır, zayıf ortam entegrasyonu bunun başlıca örnekleri
Asıl sorun, programlama dillerine düzgün entegre olmuş ya da standart kütüphanenin parçası olan iyi bir çapraz platform GUI platformu bulunmaması
Swing’de native browser bileşenlerine erişim zayıf, Tk’de browser bileşeni ve sürükle-bırak eksik, wxWidgets’in topluluğu küçük ve binding’leri de sanki birden fazla kez yeniden canlandırılmak zorunda kalmış gibi görünüyor
Qt’nin de daha fazla para kazanmak uğruna bir gün bozulma ihtimali var; ayrıca KDE’nin o kadar kritik olduğunu düşünmüyorum ve KDE topluluğunun uzun vadede bir fork’u taşıyıp taşıyamayacağından da emin değilim
Geriye Electron ya da browser bileşeninin üstüne JavaScript/CSS bindirip yerel sunucu callback’leri ekleyen türevler kalıyor; önemsiz uygulamalardaki bellek ve çalışma zamanı yükünü geçtim, programlama modeli başlı başına kötü
Düzgün bir çapraz platform GUI toolkit’i yapmak için kullanılabilirlik, erişilebilirlik, tasarım, dokümantasyon ve test için ciddi para ve insan gerekiyor. Açık kaynak topluluğu bunu başaramadı; GTK fiilen Linux’a özel hâle geldi ve Qt ya da Swing’in yerini alacak modern bir aday da yok
TUI temel sorunun çözümü değil ama alternatiflere bakınca, çapraz platform UI için TUI’yi seçen geliştiricileri anlamak mümkün. GUI ihtiyaçlarının yaklaşık %80’i, TUI renderer’ı olan bir GUI toolkit’i ile de karşılanabilir gibi geliyor
Böylece kararlı API ve ABI sağlanabilir, ayrıca başka birçok dilde karmaşık dolambaçlara girmeden binding yapılabilir. Özellikle derlenen dillerde bu daha önemli
Qt’yi Python’a bağlamak kolay olabilir ama Free Pascal gibi bir dile bağlamak için C API sunan aracı bir C++ kütüphanesi gerekir ve uygulamanın o kütüphaneyi de dağıtması gerekir
Ne yazık ki GUI toolkit’lerinin çoğu C değil C++ ya da başka dillerle yazılıyor; bu da geliştiricinin sevdiği dil o değilse kullanımı acı verici hâle getiriyor. Ana akım içinde C ile yazılmış neredeyse tek seçenek GTK ama GTK de geriye dönük uyumluluğu pek umursamıyor
Bir kütüphane sadece C API sunsun, içi hangi dille yazılmış olursa olsun denebilir ama eğer yaygın olarak dağıtılan bir şey değilse statik linkleme isteyebilirsiniz. C/C++ dışındaki dillerde bu ayrıca sorun yaratıyor
Örneğin Lazarus için bir FLTK backend’i yapmaya çalışmıştım[0]; FLTK bir C++ kütüphanesi ve statik linklemeyi teşvik ediyor, dolayısıyla bağımsız GUI binary’leri üretmek mümkün görünüyordu
Ama önce bir C wrapper yazmak gerekti; Linux’ta da g++’ın linker’a verdiği sihirli bayraklar olmadan C++ kütüphanesini C/C++ dışı dillerden statik linklemek acı vericiydi, Windows’ta ya da en azından msys2’de ise imkânsızdı, ben de bıraktım
[0] https://i.imgur.com/W6XbLkr.png
macOS ve Windows’ta native görünüme çok yaklaşıyor ve Qt’ye göre programlaması çok daha kolay. Hem kullanıcı olarak hem de ara sıra geliştirici olarak çoklu platform GUI için en çok wxWidgets’i tercih ediyorum
Buna karşılık Electron ya da browser bileşeni + JavaScript/CSS + yerel sunucu callback kombinasyonundan kullanıcı olarak gerçekten nefret ediyorum. İşlevsellikten vazgeçip komut satırına dönmem gerekse bile bu tür uygulamalardan kaçınmak isterim
Standart klavye kısayollarını da desteklemiyorlar, görüntüleri de tuhaf kaçıyor ve beklenmedik yerlerde takılıyorlar
Bazı TUI framework’leri neredeyse o seviyeye geldi. SSH vb. üzerinden ekstra uğraş olmadan kullanılabilmeleri güzel ama sanki yanlış problemi çözüyorlar
Her şeyi bir IDE gibi göstermeye ya da çalıştırmaya çalışmak yerine, pencere yönetimi ve kalıcılık kısmı daha az kötü olan tmux benzeri şeylerle birlikte daha odaklı ve birleştirilebilir CLI araçları tercih ederim
readline destekli basit bir REPL yaparsanız standart ve öngörülebilir davranış elde edersiniz
Yine de bu akımın terminal emülatörü iyileştirmelerini hızlandırması hoşuma gidiyor
Baktığım TUI’lerin çoğu sanki NPM bağımlısı
Agent’ların, güvenlik lastik yangını olmayan bir şeyle kendilerini yeniden yazmaya bile vakti yokmuş gibi görünmesi tuhaf
Bütün bu agent’ların bir şeyleri ele geçireceği anlatısı bana, sonuçta yeterince hızlı olmamak dışında pek bir şeyden endişe etmeyen çöp-dönüşüm-çöp startup insanlarının ürettiği şeyler gibi geliyor
Mesela OpenCode, tüm mesaj logunu tutup aynı sırayla SSE endpoint’ine göndererek bir sonraki yanıtı alma gibi en temel işi hâlâ doğru düzgün yapamıyor; bağlam budamayı kapatsanız bile prompt cache miss sık sık devam ediyor
Geliştirici deneyimi de harika ve npm gerekmiyor
curl | bashile işleyen o huzurlu güvenlik günleriYazılım geliştiricilerin kullanıcı arayüzü tasarlamasına izin verilmesi başlı başına garip
Metin dışı kullanıcı arayüzleri oluşturma becerileri yok gibi görünüyor. Sanki bir tesisatçıya evi tasarlatıp bütün zeminleri, borular daha rahat geçsin diye aşağı doğru eğimli yaptırmak gibi
Birden çok pencereyi taşıyıp yeniden boyutlandırmanız gerekiyorsa metin penceresi yapıyorlar; seçenekleri hızlıca seçmeniz gerekiyorsa metin kutusu yapıyorlar; stilli ve biçimli belgeleri hızlı yazmanız gerekiyorsa biçim vermek için daha fazla metin yazdırıyorlar
Ama o metni biçimli hâliyle kolayca görebileceğiniz uygulamayı yapmıyorlar
Yapmaları gayet doğal, kullanmak istemiyorsanız kullanmazsınız
Güzel görünüyorlar ama uygulama stili geliştirme ya da dosya yöneticisini aşan karmaşık işler için neredeyse işe yaramıyorlar
TUI, terminalin içinde yaşayan insanlar için iyi olduğu için
Görsel içerik kaynaklı dikkat dağınıklığı yok, klavyeyle aşırı verimli ve artık AI bunu hızlıca üretebiliyor. Eskiden gerçekten acı vericiydi
TUI’nin kitlesi büyüdükçe TUI de daha yaygın hâle geldi
80 sütunluk metin içinde ürün yöneticisinin sadeleştirebileceği şey de pek olmuyor
Hiçbir büyük teknoloji şirketinin tarayıcıyı bırakmıyor olması zaten yanlış değil mi?
Lobste.rs görüşleri
Keşke insanlar bunun yerine yerel uygulamalar yapsa. TUI, komut satırı arayüzü ile gerçek GUI’nin kötü yanlarını birleştiren bir şey gibi görünüyor
Her TUI programı kaydırmayı baştan kendisi uygulamak zorunda kalıyor; bu yüzden terminal piksel düzeyinde kaydırmayı desteklese bile TUI programları yalnızca satır satır kaydırmayı destekliyor ve davranışları da birbirinden farklı oluyor. senpai içindeki scrollback, kullandığım diğer programlardan farklı çalıştığı için sürekli yönümü kaybediyorum
Arayüzün tek bir metin panelinden fazlası olduğuna dair terminale bilgi vermenin de bir yolu yok; bu yüzden metin seçimi sık sık bozuluyor. Fare olaylarını ele geçirerek bu mümkün oluyor ama o da ayrı bir dert. Bir TUI IRC istemcisinde metin seçebilmek için iki yandaki ıvır zıvır panelleri gizleyen bir kısayola basmam gerekiyordu ve bu epey aptalca bir süreçti
Izgaraya uymak zorunda olma kısıtı, yerleşim ve tasarım olanaklarını ciddi biçimde sınırlıyor. Tıklanabilir düğme gibi görünmesi için biçimlendirme yapma, bağlam menüsü benzeri şeyler gibi. Bir zamanlar bu sorundan şikayet etmiştim
TUI’lerin artmasını, geleneksel GUI çerçevelerinin durumunun iyi olmamasının üzücü bir sonucu olarak görüyorum. TUI çerçeveleri nispeten daha istikrarlı ve çok eski olanları kullansanız bile çok sırıtmıyor. ncurses programlarını bugün hâlâ sık kullanıyorum ama Motif programlarını kullandığımı pek hayal edemiyorum
GUI çerçevelerinde ise seçenekler o kadar fazla değil ve bakım ihtiyacı çok daha yüksek. Masaüstü ortamları değişiyor, GUI’den beklentiler de artıyor. TUI erişilebilirliğinin gerçekten kötü olduğunu düşünüyorum ama bundan tamamen emin de değilim. Üstelik değişim de çok fazla: GTK2 ile yapıyorsun, kullanım dışına çıkıyor; GTK3’e geçiyorsun, bu kez GTK4’e geç deniyor
Daha alaycı bakarsak, Omarchy gibi şeylerde başka etkenler de var. Normal bir GUI olan xfce4-taskmanager sıkıcı görünüyor ama TUI olan btop aşırı hacker işi duruyor. İnsanlar terminal estetiğini seviyor (/r/unixporn’a bakın) ve hava uğruna kullanılabilirlikten ödün vermeye de razı gibiler. btop’un süreç listesini gerçekten fade-out yapmasına bakınca bunu görebiliyorsunuz
Umarım artık giriş engeli daha düşüktür. Geliştiricilerin çoğu yüksek seviyeli dillerle yetişmişken bu çok ikna edici görünmüyor; C++’ın karmaşıklığı da beni korkutuyor olabilir
[
20:41
]
username1
:
message1
[
20:42
]
username2
:
message2
Matrix istemcisi Nheko ise bir seferde bir satırdan fazlasını seçmene bile izin vermiyor
Buna karşılık IRC istemcileri varsayılan olarak şunu veriyor
20:41 <username1> message1
20:42 <username2> message2
Bazen mantıklı olabiliyorlar ama ideal olarak yalnızca küçük, kısa ömürlü uygulamalarda ya da metin düzenleme gibi istisnalarda kullanılmaları daha iyi olur diye düşünüyorum
Örneğin lf, tig, kakoune kabuk betikleriyle iyi çalışıyor; aynı betikleri yeniden kullanabiliyor ve üç uygulamanın hepsinde işlevsellik genişletebiliyorsun. Hepsi alacritty içinde çalıştığı için bu üç uygulama ve kabuğun genelinde çalışan köprüler de oluşturabiliyorum
Hayal kuracak olsam, Emacs ya da acme tarzı bütünleşmeye izin veren tek renkli minimalist bir GUI araç takımı isterdim
TUI’nin nasıl olup da “otomasyonu kolay” olduğunu anlamıyorum. Konsolda gösterilen bir GUI’den farkı ne?
Bu yazı, TUI’nin “geri dönüşünün” asıl nedenini kaçırmış. Bu iddianın kendisi de şüpheli ama Claude gibi kodlama ajanlarının çok sayıda vibe coding ürünü üretmesiyle son dönemde popülerliğinin arttığı doğru gibi görünüyor
Geliştiriciler kolay yolu sever. Çünkü çapraz platform bir TUI yapmak, bir GUI yapmaktan daha kolay
Web uygulamalarının popüler olmasının nedeni de aynıydı. Tarayıcı araçlarıyla çapraz platform uygulama yapmak kolaydı; Electron’ın yükselişi de tarayıcılar arası destek yükünü ortadan kaldıran benzer bir durum. Duyarlı bir arayüz yapmak, arayüzü çapraz platform biçimde render etmek, kullanıcı girdisini özellikle erişilebilirliği de hesaba katarak ele almak zordur. Bu yüzden geliştiriciler, bunları kolaylaştıran bir şey görünce hemen üstüne atlar
Son dönemde TUI yapımını kolaylaştıran değişiklikler de oldu. Gelişmiş özellikler için çapraz platform desteği iyileşti, karmaşık ayrıntıları soyutlayan popüler kütüphaneler çıktı ve bunlar yakın zamandaki TUI rönesansına yol açmış gibi görünüyor
Bunun dışında yazının diğer noktaları biraz şüpheli. Mesela yazar, Electron uygulamalarının zayıf yanı olarak tutarlılığı gösteriyor ama popüler TUI’lerde de gelenekler dışında neredeyse hiç tutarlılık yok. Kodlama ajanları benzer kısayollar benimsedi ama bunun nedeni çoğunun aynı kaynak olan Claude’u kopyalamış olması. Bu kısayollar kodlama ajanlarının dışına pek taşmıyor ve benim kullandığım çoğu TUI’nin kısayolları ve görsel dili epey farklı
“Arayüzü çapraz platform biçimde render etmek zor” sözü de bana şüpheli geliyor. Bir uyumluluk katmanı gerekir ve desteklenen platform sayısı kadar uygulama gerekir ama bu, tek platform desteğine göre o kadar da zor görünmüyor. Elbette hedef platformların render yaklaşımı o kadar farklıysa ki ortak bir API tasarlamak zorlaşıyorsa başka; ama ekrana piksel basma seviyesinde bunun böyle olmaması gerekir. Ölçekleme gibi şeylerle uğraşmak gerekir ama onun ötesi oldukça doğrusal olmalı, olmadı SDL var
Sanırım kastedilen şey, arayüzün tüm platformlarda “yerel gibi görünmesi”. Bu da her platformun tercih edilen yerel GUI araç takımını kullanmayı gerektirebilir; bunlar hem birbirinden çok farklıdır hem de düşük seviyeli render API’lerine göre çok daha büyük ve daha az kararlı olabilir. Bunun için hayat çok kısa. Renk teması ya da grafik stilinin bazı yönlerini değiştirme imkanı bırakırdım ama bunu uygulama düzeyi ayar olarak tutardım. Her işletim sisteminin grafik ayarlarını okuyup zaman harcamak istemem
“Kullanıcı girdisini, özellikle erişilebilirliği ele almak zor” sözü de garip. Klavye ve fare olaylarını dinlemek önemsiz bir iş. Erişilebilirlik açısından düzgün klavye dolaşımı gerekir ve bu genel kullanılabilirlik için de önemlidir; standart ve özelleştirilmiş kısayolların desteği de gerekir ama genel olarak bunlar diğer şeylerden çok daha kolay görünüyor
Ekran okuyucu desteği, ilgili platformun API’sine ve platformlar arası farklara bağlı olarak zor olabilir ama bu girdi sorunundan çok render sorununa daha yakın
TUI, bir “geri dönüşten” çok, yerel GUI programlama bilgisini kaybettiğimiz için eldeki araçlarla idare etmeye çalışma haline benziyor. Bu, tutarlı geliştirme ve yatırım eksikliğinin sonucu
Qt gibi birkaç parlak istisna dışında UI medeniyeti çöktü ve sanki kıyamet sonrasında yaşıyoruz
Preventing the Collapse of Civilization konuşmasıyla kafiyeli geliyor ve artık çok fazla kodun AI tarafından yazıldığı bir dönemde bu bilgi çöküşünün daha da yayılmasından endişe ediyorum
Bilgisayar bilimi için bir tür After Virtue gerekiyormuş gibi geliyor; belki Blow’un çevrimiçi varlığı bu rolü oynuyordur. Her neyse, tutarlılık gösteren, kullanıcıya saygı duyan, öğrenmeyi ve özeni ödüllendiren bilgisayar arayüzleri dönemini özlüyorum
Bu yazının somut içeriği pek yok gibi; daha çok yazarın diğer her şeyin berbat olduğunu düşündüğünü söylüyor gibi
Şunu söyleyebilirim: Emacs, metin, klavye, düğme ve zengin medya arayüzleri için harika bir platform
İnsanlar Go, Rust ve şimdi de Zig ile ncurses yerine TUI kütüphaneleri kullanmaya başladığı için olabilir. Yine de ncurses’ın gerektirdiği o korkunç taşınabilirlik sorunlarını çözmüş oldular
Sonra insanlar yeni terminaller yapmaya ve o taraftaki teknolojiyi de ilerletmeye başladı. Kısmen bunun sebebi C yerine Go, Rust ve Zig ile yazabilmeleri
C ve C++’tan daha eğlenceli, daha az sinir bozucu iyi seçenekler sunarsanız insanlar doğal olarak daha yeni ve daha faydalı kodlar yazmaya başlar
TUI’nin geri dönmesinin gerçek nedeni, 2026’da imzalanmış ve noter tasdikli bir GUI dağıtmak için Apple’a para ödemeniz ve Windows için de bir sertifika otoritesine para vermeniz gerekecek olması
Küçük bir düzeltme: Zed’in GPU hızlandırmalı UI kütüphanesi çapraz platform API’si wgpu değil, gpui
Yazının tezini gerçekten kanıtlayıp kanıtlamadığından emin değilim ama MS-DOS dönemini yaşamış ve TUI’leri hep sevmiş biri olarak ben de araya gireyim. afl-fuzz kullandıysanız muhtemelen anlarsınız
Teoride Linux’ta TUI’nin çok daha başarılı olması gerekirdi. Metin tabanlı estetiği seven teknik bir kullanıcı kitlesi vardı ve bir de kaba, tutarsız GUI ortamı gibi bir “avantaj” söz konusuydu. Ekran kartını X sunucusunda düzgün çalıştırmak bile başlı başına sorun olan zamanlar vardı
Aynı zamanda onlarca yıl boyunca *nix yazılım geliştiricileri, eski ve egzotik terminal türlerini bile desteklemek zorundaymış gibi hissetti. Uygulama DECwriter’da düzgün render edilmezse kıyamet kopacakmış gibi davranılıyordu; böyle kısıtlar altında iyi bir TUI yapmak zordu
MS-DOS döneminde Microsoft, Borland, Norton gibi şirketler işlevsel ve hızlı tepki veren metin tabanlı arayüzleri ustalıkla yapmıştı. Linux’ta ise uzun süre TUI tasarımının “zirvesi” menuconfig denen canavardı; biraz gözünüzü kısarsanız vim’e bile TUI diyebilirsiniz. İnsanların gerçekten metin modlu konsol kullandığı dönemlerden hatırladığım iyi Linux TUI’lerden biri, Norton Commander’dan ilham alan dosya yöneticisi Midnight Commander idi