Gio UI - Go için çapraz platform GUI

 (gioui.org)
2 puan yazan GN⁺ 2024-05-19 | 1 yorum | WhatsApp'ta paylaş
  • Go geliştiricilerinin birden çok işletim sistemi ve WebAssembly hedefi için immediate mode GUI oluşturmasını sağlayan bir kütüphane
  • Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD ve WebAssembly desteğiyle platform kapsamı geniş
  • Bağımlılıkları azaltacak; pencere yönetimi, giriş ve GPU çizimi için her platformun kütüphanelerinden yararlanacak şekilde tasarlanmış
  • Render işlemi, OpenGL ES ve Direct3D 11 tabanlı Pathfinder vektör renderer içeriyor; piet-gpu tabanlı compute shader renderer'a geçiş sürecinde
  • Metinleri ve şekilleri dokuya dönüştürmek yerine kontur olarak render ederek animasyon, dönüştürülmüş çizim ve piksel çözünürlüğünden bağımsızlığı destekliyor

Gio'nun amacı ve destek kapsamı

  • Gio, Go ile verimli, akıcı ve taşınabilir GUI'ler oluşturmak için geliştirilmiş bir kütüphane
  • Desteklenen platformlar Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD ve WebAssembly
  • Hızlı gösterim için bir WebAssembly demosu var; çalıştırmak için WebAssembly destekli bir tarayıcı gerekiyor
  • Örnek kaynak koduna Kitchen project üzerinden bakılabilir

Kurulum ve öğrenme yolu

  • Gio, az bağımlılık hedefiyle tasarlanmış
  • Gerekli bağımlılıklar platforma özel kurulum belgelerinden kontrol edilebilir
  • Kurulumdan sonra Learn belgeleri ve Hello World ile başlanabilir
  • Showcase'te godcr, Tailscale, gotraceui, Sointu, Protonet gibi örnekler yer alıyor

Render teknolojisi

  • Gio, immediate mode grafik paradigmasının esnekliğini modern 2D grafik teknolojileriyle birleştiriyor
  • Vektör renderer, Pathfinder project temel alınarak geliştirilmiş ve OpenGL ES ile Direct3D 11 üzerinde uygulanmış
  • Renderer, piet-gpu üzerine inşa edilen daha verimli compute shader tabanlı renderer'a geçiş sürecinde
  • Metinler ve şekiller, önceden doku görüntülerine dönüştürülmeden yalnızca konturlar kullanılarak render ediliyor
    • Verimli animasyonları destekler
    • Dönüştürülmüş çizimler için uygundur
    • Piksel çözünürlüğünden bağımsızlığı koruyabilir

Sponsorluk modeli

  • Gio geliştirme finansmanı sponsorluklarla sağlanıyor
  • Proje yararlıysa OpenCollective'deki Gio projesine destek olmayı veya geliştiriciye doğrudan sponsor olmayı düşünebilirsiniz

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-19
Hacker News yorumları

  • Gerçek kullanımda bununla ciddi ve karmaşık bir uygulama geliştirmenin mümkün olmadığını gördüm
    Diğer platformların varsayılan olarak sunduğu video, harita, zengin metin gibi bileşenler yok ve bunları kendiniz eklemek için net ve kolay bir yol da yok
    API birkaç ayda bir bozuluyor, tema uygulamanın bir yolu da yok
    Immediate mode grafikler, karmaşık durum yönetmeye başlayana kadar iyi; ama o noktadan sonra kendi retained mode grafik sisteminizi uygulamanız gerekiyor ve bu da uzun zaman önce çözülmüş bir sorunu yeniden gündeme getiriyor
    piet-gpu tabanlı gösterişli renderer da girdi olarak yalnızca Bezier eğrisi kontrol noktalarını alıp her şeyi tessellation’dan geçirdiği için fikir olarak havalı, ancak gerçek bir daire çizmek istediğinizde 4 Bezier’den oluşan bir yaklaşıma dayanmak zorunda kalıyorsunuz
    Wasm, derleyici ekibinin ürün seviyesine gelmesi için birkaç yıl mühendislik açısından cilalaması gereken bir kavram kanıtına daha yakın; genel olarak ise Go geliştiricilerinin liste ve giriş alanı düzeyinde basit arayüzler yapması için fena görünmüyor

    • Bununla her şey yapılabilir ve v0.6 ile bu sorunlar çok daha az zahmetli hale geldi
      Material Design teması da var, light/dark mod da var
      Light/dark ve özel temaları olan iyi bir gioui uygulaması örneği https://github.com/chapar-rest/chapar
      Mac veya Windows’ta go run . yeterli
      Metin kerning’i, yay boyunca akan metin, RTL/LTR de github.com/go-text/typesetting sayesinde mümkün
      Takvim spinner’ı veya diyagram gibi karmaşık widget’lar da GitHub’da var, ancak bunları bir araya getirme çabası eksik
      Bunlar toplandığında daha fazla geliştiricinin dahil olması için yeterince güçlü bir teşvik oluşacağını düşünüyorum
    • Birkaç ayda bir API’nin bozulmasına yol açan değişiklikler Google kodlarında iç karartıcı derecede sık görülüyor
      Kullanıcı kodunun bozulmamasına önem veren bir kültür yok gibi görünüyor
    • Wasm önemliyse Uno Platform bunu oldukça iyi destekliyor; AvaloniaUI da var
      İkisi de şu anda stabil ve nispeten zengin bir kontrol seti ile kütüphanelere sahip

  • Web’de Flutter gibi her şeyi canvas’a render ediyor gibi görünüyor; bu yaklaşımın erişilebilirlik ve native his açısından sorunlu olduğu biliniyor

    • Web’de kesinlikle native gibi hissettirmiyor ve erişilebilirliği de iyi değil
      Radyo düğmeleri arasında Tab ile gezilemiyor; macOS’ta CMD+A metin alanının tamamını seçmiyor, CTRL+A ise seçiyor
    • Erişilebilirlik için canvas’ın yanında birlikte duran görünmez bir DOM kullanan bir varyasyon olup olmadığını merak ediyorum
      Mümkün gibi, ama epey iş yükü de gerektirir
    • iPhone’da kopyalama veya yapıştırma bile hiç çalışmıyor
    • Bu zaten baştan bir web uygulama framework’ü değil, native GUI toolkit; daha çok web backend’i olan bir şeye benziyor

  • Konudan biraz sapıyor ama bugünlerde çapraz platform mobil ve web uygulamaları geliştirmenin en iyi yolunun ne olduğunu merak ediyorum
    İster iş mantığıyla UI’ın tamamını paylaşmak olsun, ister yalnızca iş mantığını paylaşmak olsun
    gomobile, Rust, TypeScript gibi seçenekler arasında kalmıştım
    Bir ara TypeScript en taşınabilir teknoloji gibi göründüğü için tüm iş mantığında kullanmayı düşünmüştüm, ama iOS’ta JavaScript’i makul performansla çalıştırmanın iyi bir yolu olmadığını fark ettim

    • Şu anda muhtemelen Flutter en iyi seçenek olabilir: https://flutter.dev/
      UI’ı native yazıp yalnızca iş mantığını paylaşmak sizin için uygunsa Kotlin de bir seçenek: https://kotlinlang.org/docs/multiplatform.html#kotlin-multip...
      Compose kullanırsanız UI’ı da Kotlin ile oluşturabilirsiniz: https://www.jetbrains.com/lp/compose-multiplatform/
      Ancak iOS desteği hâlâ alfa aşamasında, web ise “experimental”; bu yüzden framework geliştikçe kodunuzu değiştirmek zorunda kalmayı göze almak istemiyorsanız, tüm platformlarda zaten oldukça olgun olan Flutter daha doğru seçim
      TypeScript ve React’i zaten biliyorsanız React Native de düşünülebilir, fakat iOS’ta veya başka yerlerdeki performansı hakkında garantiyle konuşmak zor: https://reactnative.dev/
    • Ürün seviyesinde olgunluk gereken uygulamalar için doğru yol native UI
      Her şeyi çözeceğini vaat edip bunu yerine getiremeyen çok fazla framework gördüm
      Başta daha hızlı başlanıyor, ama kısa süre sonra bir OS güncellemesinden sonra FPS’i native’e yaklaştırmak ya da sistem animasyonlarını daha benzer hâle getirmek için çekirdek kütüphaneleri yamamaya başlıyorsunuz
      Zaman tasarrufu ancak UI’ı inceltmediğinizde oluyor
      Çekirdek mantık paylaşılabilir
      gomobile kullanıyorum ve genel olarak memnunum, ama runtime ek yükü 3 MB olduğu için web’e uygun değil
      Kotlin Multiplatform iyi görünüyordu, fakat temel kütüphaneler eksikti; muhtemelen Kotlin Android’de zaten var oldukları için çok platformlu karşılıklarını yapan pek kişi yoktu
      Rust ve Mozilla’nın dil binding katmanı da iyi görünüyor ama henüz denemedim
    • React Native ve Expo kombinasyonunu öneririm
      Flutter da kötü değil, fakat web’de canvas’a render ettiği için his ve erişilebilirlik açısından pek iyi değil
      iOS’ta da Impeller render motorunu devreye aldıktan sonra bile hâlâ gecikme sorunları var
      Bluesky istemcisine bakarsanız, desteklenen platformların genelinde performansı iyi ve tek bir kod tabanı kullanıyor
      https://github.com/bluesky-social/social-app
    • Uno(https://platform.uno) var
      Açık kaynak ve Android, iOS, Windows, Mac, Linux’u hedefliyor: https://platform.uno/platforms/
      C# kullanıyor; her platformun native UI framework’üyle view ve control’leri otomatik olarak uyguluyor
      Visual Studio, VS Code, Rider gibi IDE desteği de iyi ve başka araçlarla da sizi kısıtlamıyor
      Tasarım iş birliği için Figma eklentisi de var
    • Biz Tauri kullanıyoruz, ama önemli nokta bunu yalnızca iç araçlarda kullanmamız
      Tüketiciye yönelik ürünler için de iyi bir araç mı bilmiyorum
      Bizim kullanımımız için yeterince iyi uyuyor; çünkü ağırlıklı olarak güneş enerjisi santrali teknisyenlerine yönelik araçlar geliştiriyoruz ve kötü internet koşullarında çapraz platform TypeScript kullanmak küçük bir ekip için fazla yük hâline gelmişti

  • gioui ile bir streaming uygulaması geliştiriyorum; çok kolay ve yükseltmeler de her zaman sorunsuz
    Çünkü Go kullanıyor ve çekirdek geliştiriciler değişiklikleri oldukça ciddiye alıyor
    Web GUI gerektiğinde bu gioui eklenti sistemini kullanıyorum: https://github.com/gioui-plugins/gio-plugins
    WebView’in web, masaüstü ve mobilde çalışmasına şaşırıyorum
    Deep link de çalışıyor; e-posta ya da Monike bildirim bağlantısı gönderdiğinizde kullanıcının uygulaması GUI’daki tam doğru konumda açılıyor
    Tüm OS’ler için bildirimler ve paylaşım uzantıları da var; bu yüzden gerçekten tamamlanmış bir sisteme çok yakın olduğunu düşünüyorum
    Tüm OS’leri desteklemenin zor olduğu noktasına katılıyorum, ama günümüz dünyasında çeşitlilik zaten varsayılan
    Birden fazla teknoloji arasında gidip gelmeden bunu yalnızca Go ile yapabilmek hoşuma gidiyor
    Go backend’i her zaman hem gio’da hem de HTML tarafında çalışacak şekilde yazıyorum
    SEO veya video oynatma gerekirse bunu WebView’de hallediyorum; gio web tarafında Google SEO’yu da karşılayabiliyorum
    Google SEO’nun görmesi için Hugo’ya Markdown koyuyorum

  • Go’ya yeni başlayan biri olarak belgedeki şu kısmı merak ediyorum
    ops.Add(ColorOp{Color: red}) yerine op.ColorOp{Color: red}.Add(ops) kullanılmasının nedeni, Add metodunun arayüz türünde argüman almamasını sağlayıp çağrı sırasında ayırmadan kaçınmakmış; Gio’nun “zero allocation” tasarımında bunun kilit nokta olduğu söyleniyor
    Neden ayırma oluştuğunu, neyin ayrıldığını ve nasıl tasarruf edildiğini bilmek istiyorum

    • Bu, Go’nun dinamik türleri arayüz üzerinden işleme biçimi ve struct’ların buna nasıl eklemlendiğiyle ilgili
      Bir fonksiyon arayüz türünde argüman alıp ona saf bir struct geçirildiğinde, Go bunun etrafında bir sarmalayıcı oluşturur; alıntıda bahsedilen ayırma da budur
      Bu sarmalayıcı, tür/vtable işaretçisi ile struct veri işaretçisinden oluşan bir işaretçi çiftidir
      Bu sayede çalışma zamanında tür çıkarımı ve örtük arayüz genişletmesi mümkün olur
      Yani bir arayüzü uygulamak için metotları uygulamak yeterlidir; ByteReader extends Reader gibi türü açıkça yazmak gerekmez
      Bu maliyet yalnızca kullanıldığında ödendiğinden, çok sayıda hızlı yol kodu mümkün olduğunca yalnızca struct kullanır
    • Go’da v := interfaceType(concreteTypeValue) yaptığınızda düşük seviyede kabaca şöyle bir şey olur
      dataPtr := &concreteTypeValue, typePtr := typeData[concreteType](), ardından veri işaretçisi ve tür işaretçisi içeren bir arayüz değeri oluşturulur
      Burada ilk satır ayırmadır; hatırladığım kurala göre bunun nedeni Go’da işaretçilerin stack değerlerini göstermemesi, dolayısıyla concreteTypeValue değerinin heap’te ayrılması gerekmesidir
      İşaretçilerin stack’i göstermemesi kuralı, goroutine stack’lerinin dinamik olarak büyümesini kolaylaştırmak içindir
      https://go.dev/doc/faq#stack_or_heap bölümüne bakın
    • İlk yöntemde ColorOp{Color: red} boxing uygulanarak heap’te ayrılmak zorundadır
      Çünkü ops.Add genellikle somut tür değerini değil, belirli bir arayüzü uygulayan değere ait kalın bir işaretçiyi alır
    • Sorunun kendisine diğer yanıtlar cevap vermiş, ama ayrı olarak op.ColorOp{Color: red}.Add(ops) okuması garip
      Bana “op.ColorOp{Color: red} sonucuna ops ekle” gibi okunuyor
      Bu yüzden fonksiyon adını AddTo koymak isterdim: op.ColorOp{Color: red}.AddTo(ops)
      Hâlâ geleneksel değil, ama en azından fonksiyon argümanının değiştirildiğine dair sinyal veriyor
    • https://stackoverflow.com/questions/39492539/go-implicit-con...

  • Windows 10 ve Chrome kullanan oldukça sıradan bir PC’de ilk sayfadaki WASM demosunun, metin olması gereken yerlerde yalnızca siyah kareler render etmesi ilginç
    Android telefonumdaki Chrome’da düzgün render edildi

    • Sadece bende değilmiş
      Üstelik inanılmaz yavaş çalıştı
    • Windows 11’de Edge’de de aynı

  • Go ile Fyne kullanarak küçük bir uygulama yaptım, bir daha kullanmayı düşünmüyorum
    Hem Gio hem Fyne, Flutter’ın sunduğu cilalı olgunluk ve özelliklerden ciddi ölçüde yoksun
    Çekirdek mantığı Golang ile yazıp bir Android uygulamasının içine sarmaya karar verdim; GUI 2003’ten çıkmış gibi görünüyordu ve düzeltme seçenekleri de sınırlıydı

    • Başka bir seçenek olarak Wails var
      Tüm mantığı Go ile yazıp UI’ı HTML ile oluşturabilirsiniz; ister web framework kullanırsınız ister kullanmazsınız
      Electron’a benzer, ama Chrome’u beraberinde dağıtmayıp sistem web görüntüleyicisini kullandığı için daha hafiftir
      [1] https://github.com/wailsapp/wails
    • İlginç
      Android uygulamasının içine nasıl sardığını anlatabilirsen iyi olur

  • Bu çapraz platform GUI’lerin hepsi neden 50 yıl önce tasarlanmış gibi görünüyor

    • 1974’te tam olarak ne kullanıyordunuz da bu size o zamanki gibi göründü, merak ediyorum

  • Demo bende çalışmıyor
    Win 11’de Chromium’da birkaç düğme görünüyor ama çoğu tamamen siyah

  • Fyne’ın aksine bu kütüphanenin, ilk attığım test olan CJK metin render etme testini geçmiş olması iyiye işaret
    Fyne, her şeyi render edecek tek bir özel font vermediğiniz sürece bunu yapamıyor
    Dünya genelinde yaygın kullanılan tüm yazı sistemlerini, üstüne emojileri de tatmin edici biçimde kapsayan tek bir font bulmak için bol şans
    Bu yüzden kullanıcı üretimi içerik, web içeriği ya da yerelleştirme ihtimali en ufak olan bir şey yaparken Fyne benim için doğrudan eleniyor

    • Bu açıdan Noto Sans oldukça iyi