Gio UI - GUI lintas platform untuk Go

 (gioui.org)
2 poin oleh GN⁺ 2024-05-19 | 1 komentar | Bagikan ke WhatsApp
  • Sebuah library yang memungkinkan pengembang Go membuat GUI mode langsung yang menargetkan berbagai sistem operasi dan WebAssembly
  • Mendukung Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD, hingga WebAssembly, sehingga memiliki cakupan platform yang luas
  • Dirancang untuk mengurangi dependensi, dan untuk manajemen jendela, input, serta rendering GPU memanfaatkan library platform masing-masing
  • Rendering mencakup renderer vektor Pathfinder berbasis OpenGL ES dan Direct3D 11, dan sedang beralih ke renderer compute shader berbasis piet-gpu
  • Teks dan bentuk tidak di-bake menjadi tekstur, melainkan dirender sebagai outline, sehingga mendukung animasi, gambar dengan transformasi, dan kemandirian terhadap resolusi piksel

Tujuan dan cakupan dukungan Gio

  • Gio adalah library untuk membuat GUI yang efisien, mulus, dan portabel dengan Go
  • Platform yang didukung adalah Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD, WebAssembly
  • Tersedia demo WebAssembly untuk demonstrasi cepat, dan untuk menjalankannya dibutuhkan browser dengan dukungan WebAssembly
  • Kode sumber contoh dapat dilihat di Kitchen project

Instalasi dan jalur pembelajaran

  • Gio dirancang dengan tujuan dependensi minimal
  • Anda dapat memeriksa dependensi yang diperlukan di dokumentasi instalasi tiap platform
  • Setelah instalasi, Anda bisa memulai dari dokumentasi Learn dan Hello World
  • Showcase mencakup godcr, Tailscale, gotraceui, Sointu, Protonet dan lainnya

Teknologi rendering

  • Gio menggabungkan fleksibilitas paradigma grafis mode langsung dengan teknologi grafis 2D modern
  • Renderer vektornya berbasis Pathfinder project dan diimplementasikan di atas OpenGL ES serta Direct3D 11
  • Renderer tersebut sedang beralih ke renderer berbasis compute shader yang lebih efisien dan dibangun di atas piet-gpu
  • Teks dan bentuk tidak dipanggang lebih dulu sebagai gambar tekstur, melainkan dirender hanya dengan outline
    • Mendukung animasi yang efisien
    • Cocok untuk gambar yang ditransformasikan
    • Dapat mempertahankan kemandirian terhadap resolusi piksel

Model pendanaan

  • Pendanaan pengembangan Gio diperoleh melalui dukungan sponsor
  • Jika proyek ini bermanfaat, Anda dapat mempertimbangkan memberi dukungan melalui proyek Gio di OpenCollective atau langsung kepada pengembang

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-19
Opini Hacker News

  • Setelah benar-benar mencobanya, ternyata mustahil membuat aplikasi kompleks yang serius dengan ini
    Tidak ada komponen seperti video, peta, atau rich text yang disediakan secara bawaan di platform lain, dan tidak ada jalur yang jelas dan mudah untuk menambahkannya sendiri
    API-nya rusak setiap beberapa bulan, dan tidak ada cara untuk menerapkan tema
    Grafis immediate mode bagus sampai Anda harus mengelola state yang kompleks, tetapi sejak titik itu Anda pada akhirnya harus mengimplementasikan sendiri grafis retained mode, sehingga masalah yang sudah lama terpecahkan dibawa kembali
    Renderer mewah berbasis piet-gpu juga hanya menerima control point kurva Bézier sebagai input lalu melakukan tessellation untuk semuanya; konsepnya keren, tetapi untuk menggambar lingkaran sungguhan Anda akhirnya bergantung pada aproksimasi dengan 4 Bézier
    Wasm lebih terasa seperti proof of concept yang masih perlu dipoles secara engineering selama beberapa tahun oleh tim compiler agar layak untuk produk, dan secara keseluruhan tampaknya cukup baik bagi developer Go saat membuat UI sederhana seperti daftar dan field input

    • Anda bisa membuat apa pun dengan ini, dan di v0.6 masalah-masalah seperti ini sudah jauh tidak merepotkan
      Ada tema Material Design dan juga mode terang/gelap
      Contoh aplikasi gioui yang bagus dengan mode terang/gelap dan tema kustom adalah https://github.com/chapar-rest/chapar
      Di Mac atau Windows cukup go run .
      Kerning teks, teks yang mengalir mengikuti busur, serta RTL/LTR juga dimungkinkan berkat github.com/go-text/typesetting
      Widget kompleks seperti spinner kalender atau diagram juga ada di GitHub, tetapi masih kurang upaya untuk mengumpulkannya menjadi satu
      Jika hal-hal seperti ini terkumpul, rasanya insentif bagi lebih banyak developer untuk ikut terjun akan menjadi cukup besar
    • Perubahan API yang merusak setiap beberapa bulan terlihat sangat sering, sampai membuat murung, di kode Google
      Tampaknya tidak ada budaya yang mementingkan agar kode pengguna tidak rusak
    • Jika Wasm penting, Uno Platform mendukungnya dengan cukup baik, dan ada juga AvaloniaUI
      Keduanya saat ini sudah stabil dan memiliki kumpulan kontrol serta library yang relatif kaya

  • Di web, tampaknya semuanya dirender ke canvas seperti Flutter, dan pendekatan ini diketahui bermasalah dalam hal aksesibilitas dan nuansa native

    • Di web, jelas tidak terasa native dan aksesibilitasnya juga buruk
      Tidak bisa berpindah antar radio button dengan tab, di macOS CMD+A tidak memilih seluruh isi field teks, sedangkan CTRL+A bisa
    • Saya penasaran apakah ada varian yang, demi aksesibilitas, menempatkan DOM tak terlihat di samping canvas
      Sepertinya mungkin, tetapi pekerjaannya juga tampaknya cukup besar
    • Di iPhone bahkan copy atau paste sama sekali tidak berfungsi
    • Ini sejak awal bukan framework aplikasi web, melainkan toolkit GUI native, dan lebih tepatnya memiliki backend web

  • Sedikit melenceng dari topik, tetapi belakangan ini saya penasaran apa cara terbaik untuk membuat aplikasi mobile dan web lintas platform
    Baik jika berbagi logika bisnis sekaligus UI, maupun hanya berbagi logika bisnis
    Saya sempat mempertimbangkan pilihan seperti gomobile, Rust, dan TypeScript
    Pada suatu waktu TypeScript tampak seperti teknologi yang paling portabel sehingga saya ingin memakainya untuk semua logika bisnis, tetapi kemudian saya menyadari tidak ada cara yang bagus untuk menjalankan JavaScript di iOS dengan performa yang layak

    • Saat ini kemungkinan Flutter adalah pilihan terbaik: https://flutter.dev/
      Jika tidak masalah menulis UI secara native dan hanya berbagi logika bisnis, Kotlin juga bisa menjadi pilihan: https://kotlinlang.org/docs/multiplatform.html#kotlin-multip...
      Dengan Compose, UI juga bisa dibuat dengan Kotlin: https://www.jetbrains.com/lp/compose-multiplatform/
      Namun dukungan iOS masih alpha dan web masih “experimental”, jadi jika tidak ingin menanggung situasi harus mengubah kode seiring framework berkembang, Flutter yang sudah cukup stabil di semua platform adalah pilihan yang tepat
      Jika sudah mengenal TypeScript dan React, React Native juga bisa dipertimbangkan, tetapi sulit menjamin performanya di iOS atau tempat lain: https://reactnative.dev/
    • Untuk aplikasi yang membutuhkan tingkat penyelesaian tinggi, UI native adalah pilihan yang tepat
      Saya sudah terlalu sering melihat framework yang menjanjikan bisa menyelesaikan semuanya tetapi tidak menepatinya
      Awalnya memang lebih cepat untuk memulai, tetapi tak lama kemudian setelah pembaruan OS, Anda akhirnya menambal library inti agar FPS mendekati native atau agar animasi sistem terlihat lebih mirip
      Waktu hanya benar-benar dihemat ketika UI tidak dipoles
      Logika inti bisa dibagikan
      Saya memakai gomobile dan secara umum menyukainya, tetapi overhead runtime-nya 3MB sehingga tidak cocok untuk web
      Kotlin Multiplatform tampak bagus, tetapi library dasar banyak yang belum ada, dan mungkin karena sudah tersedia di Kotlin Android, tidak banyak orang yang membuat padanan multiplatform-nya
      Rust dan lapisan binding bahasa dari Mozilla juga tampak bagus, tetapi saya belum mencobanya
    • Saya merekomendasikan kombinasi React Native dan Expo
      Flutter juga tidak buruk, tetapi untuk web ia merender ke canvas sehingga kurang baik dari sisi feel dan aksesibilitas
      iOS juga masih punya masalah latensi bahkan setelah mengadopsi mesin rendering Impeller
      Jika melihat klien Bluesky, performanya cukup baik di seluruh platform yang didukung dan memakai satu codebase
      https://github.com/bluesky-social/social-app
    • Ada Uno(https://platform.uno)
      Open source dan menargetkan Android, iOS, Windows, Mac, Linux: https://platform.uno/platforms/
      Menggunakan C#, dan secara otomatis mengimplementasikan view serta control dengan framework UI native masing-masing platform
      Dukungan IDE seperti Visual Studio, VS Code, dan Rider juga bagus, dan tidak dibatasi hanya pada alat-alat itu
      Ada juga plugin Figma untuk kolaborasi desain
    • Kami memakai Tauri, tetapi penting dicatat bahwa kami hanya memakainya untuk tool internal
      Saya tidak tahu apakah ini juga alat yang bagus untuk produk konsumen
      Untuk penggunaan kami, ini sangat cocok, terutama karena tool kami digunakan teknisi pembangkit listrik tenaga surya, dan memakai TypeScript lintas platform di kondisi internet yang buruk menjadi terlalu membebani tim kecil

  • Saya sedang membuat aplikasi streaming dengan gioui, dan ini sangat mudah serta upgrade selalu mulus
    Karena ini Go dan para developer intinya menangani perubahan dengan cukup serius
    Saat membutuhkan GUI web, saya memakai sistem plugin gioui ini: https://github.com/gioui-plugins/gio-plugins
    Mengejutkan bahwa WebView berjalan di web, desktop, dan mobile
    Deeplink juga berfungsi, jadi ketika mengirim tautan lewat email atau notifikasi Monike, aplikasi pengguna terbuka tepat di lokasi yang sesuai dalam GUI
    Ada juga notifikasi dan ekstensi berbagi untuk semua OS, jadi menurut saya ini benar-benar mendekati sistem yang lengkap
    Saya setuju bahwa mendukung semua OS itu sulit, tetapi di dunia sekarang keberagaman adalah hal mendasar
    Saya suka karena semua ini bisa dilakukan hanya dengan Go tanpa harus berpindah-pindah teknologi
    Backend Go selalu kami tulis agar berjalan baik di gio maupun HTML
    Jika membutuhkan SEO atau pemutaran video, kami menanganinya di WebView, dan SEO Google untuk sisi web gio juga bisa dipenuhi
    Kami memasukkan Markdown ke Hugo agar Google SEO dapat melihatnya

  • Dari sudut pandang pemula Go, bagian dokumentasi ini membuat saya penasaran
    Alasan memakai op.ColorOp{Color: red}.Add(ops) alih-alih ops.Add(ColorOp{Color: red}) disebutkan karena metode Add dibuat agar tidak menerima argumen bertipe interface, sehingga menghindari alokasi saat pemanggilan, dan ini merupakan inti dari desain “zero allocation” Gio
    Saya ingin tahu mengapa alokasi terjadi, apa yang dialokasikan, dan bagaimana penghematannya dilakukan

    • Ini karena cara Go menangani tipe dinamis lewat interface dan bagaimana struct berinteraksi dengannya
      Ketika sebuah fungsi menerima argumen bertipe interface dan kita meneruskan struct murni ke sana, Go membuat wrapper di sekelilingnya; inilah alokasi yang dimaksud dalam kutipan itu
      Wrapper ini adalah pasangan pointer yang terdiri dari pointer tipe/vtable dan pointer ke data struct
      Dengan begitu, inferensi tipe saat runtime dan perluasan interface implisit menjadi mungkin
      Artinya, untuk mengimplementasikan interface cukup dengan mengimplementasikan metodenya, tanpa perlu menuliskan tipe secara eksplisit seperti ByteReader extends Reader
      Biaya ini hanya dibayar saat digunakan, jadi banyak kode jalur cepat sebisa mungkin hanya memakai struct
    • Di Go, ketika melakukan v := interfaceType(concreteTypeValue), pada level rendah kira-kira yang terjadi adalah seperti ini
      dataPtr := &concreteTypeValue, typePtr := typeData[concreteType](), lalu membuat nilai interface yang memiliki pointer data dan pointer tipe
      Baris pertama di sini adalah alokasinya; menurut aturan yang saya ingat, pointer di Go tidak menunjuk ke nilai stack, sehingga concreteTypeValue harus dialokasikan di heap
      Aturan bahwa pointer tidak menunjuk ke stack dibuat agar stack goroutine lebih mudah bertumbuh secara dinamis
      Lihat https://go.dev/doc/faq#stack_or_heap
    • Pada cara pertama, ColorOp{Color: red} harus diboxing dan dialokasikan di heap
      Karena ops.Add umumnya menerima pointer tebal ke nilai yang mengimplementasikan interface tertentu, bukan nilai tipe konkret
    • Pertanyaannya sendiri sudah dijawab oleh jawaban lain, tetapi secara terpisah, op.ColorOp{Color: red}.Add(ops) terasa aneh dibaca
      Bagi saya, itu terbaca seperti “menambahkan ops ke hasil dari op.ColorOp{Color: red}”
      Jadi saya ingin menamai fungsinya AddTo: op.ColorOp{Color: red}.AddTo(ops)
      Masih belum sepenuhnya idiomatis, tetapi setidaknya memberi sinyal bahwa argumen fungsi yang dimodifikasi
    • https://stackoverflow.com/questions/39492539/go-implicit-con...

  • Menarik bahwa demo WASM di halaman pertama, pada PC yang cukup biasa dengan Windows 10 dan Chrome, hanya merender kotak-kotak hitam di tempat seharusnya ada teks
    Di Chrome pada ponsel Android, rendernya benar

    • Ternyata bukan cuma saya
      Selain itu, jalannya sangat lambat
    • Sama juga di Edge pada Windows 11

  • Saya pernah membuat aplikasi kecil dengan Fyne di Go, dan tidak berniat memakainya lagi
    Baik Gio maupun Fyne sangat kekurangan tingkat polesan dan fitur matang yang disediakan Flutter
    Saya akhirnya membuat logika inti dengan Golang lalu membungkusnya sebagai aplikasi Android, tetapi GUI-nya terasa seperti berasal dari tahun 2003 dan opsi untuk memperbaikinya juga terbatas

    • Alternatif lain adalah Wails
      Semua logika bisa ditulis dengan Go, sementara UI ditulis dengan HTML; bisa memakai framework web atau tidak
      Mirip Electron, tetapi lebih ringan karena tidak ikut mendistribusikan Chrome dan memakai web viewer sistem
      [1] https://github.com/wailsapp/wails
    • Menarik
      Saya ingin kalau Anda bisa menjelaskan bagaimana Anda membungkusnya sebagai aplikasi Android

  • Mengapa semua GUI lintas platform seperti ini terlihat seolah-olah didesain 50 tahun lalu?

    • Saya ingin tahu sebenarnya apa yang mereka pakai pada 1974 sampai-sampai ini terlihat seperti dari masa itu

  • Demo tidak berjalan untuk saya
    Di Chromium pada Win 11, beberapa tombol terlihat, tetapi sebagian besar semuanya berwarna hitam

  • Berbeda dengan Fyne, fakta bahwa library ini lolos tes pertama yang saya lemparkan, yaitu rendering teks CJK, adalah pertanda bagus
    Fyne tidak bisa melakukan ini kecuali kita memberinya satu font kustom untuk merender semuanya
    Semoga beruntung menemukan satu font yang mencakup secara memuaskan semua sistem tulisan yang umum dipakai di seluruh dunia, apalagi emoji
    Jadi ketika membuat sesuatu yang punya sedikit saja kemungkinan berisi konten buatan pengguna, konten web, atau lokalisasi, Fyne langsung gugur bagi saya

    • Dalam hal seperti ini, Noto Sans cukup bagus