Gio UI - Go के लिए क्रॉस-प्लैटफ़ॉर्म GUI

 (gioui.org)
2 पॉइंट द्वारा GN⁺ 2024-05-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक लाइब्रेरी है जो Go डेवलपर्स को कई operating systems और WebAssembly के लिए immediate mode GUI बनाने में सक्षम बनाती है
  • Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD, WebAssembly तक सपोर्ट करती है, इसलिए इसका platform coverage व्यापक है
  • डिज़ाइन ऐसा है कि dependencies कम रखी जाती हैं और window management, input, GPU drawing के लिए हर platform library का उपयोग किया जाता है
  • Rendering में OpenGL ES और Direct3D 11 आधारित Pathfinder vector renderer शामिल है, और यह piet-gpu आधारित compute shader renderer की ओर बढ़ रहा है
  • Text और shapes को texture में bake किए बिना outlines के रूप में render किया जाता है, जिससे animation, transformed drawing और pixel-resolution independence सपोर्ट होते हैं

Gio का उद्देश्य और सपोर्ट दायरा

  • Gio Go में efficient, smooth और portable GUI बनाने के लिए एक लाइब्रेरी है
  • Supported platforms हैं Linux, macOS, Windows, Android, iOS, FreeBSD, OpenBSD, WebAssembly
  • Quick demo के लिए WebAssembly demo उपलब्ध है, जिसे चलाने के लिए WebAssembly support वाला browser चाहिए
  • Example source Kitchen project में देखा जा सकता है

Installation और सीखने का रास्ता

  • Gio को कम dependencies के लक्ष्य के साथ design किया गया है
  • Platform-specific installation docs में जरूरी dependencies देखी जा सकती हैं
  • Installation के बाद Learn docs और Hello World से शुरुआत की जा सकती है
  • Showcase में godcr, Tailscale, gotraceui, Sointu, Protonet आदि शामिल हैं

Rendering तकनीक

  • Gio immediate mode graphics paradigm की flexibility को आधुनिक 2D graphics technology के साथ जोड़ता है
  • Vector renderer Pathfinder project पर आधारित है और OpenGL ES तथा Direct3D 11 के ऊपर implement किया गया है
  • Renderer piet-gpu पर built, अधिक efficient compute shader based renderer की ओर बढ़ रहा है
  • Text और shapes को texture images के रूप में पहले से bake नहीं किया जाता, बल्कि सिर्फ outlines का उपयोग करके render किया जाता है
    • Efficient animations को सपोर्ट करता है
    • Transformed drawing के लिए उपयुक्त है
    • Pixel-resolution independence बनाए रख सकता है

Funding model

  • Gio development के लिए funding sponsorship से जुटाई जाती है
  • अगर project उपयोगी लगे, तो OpenCollective पर Gio project या developer को direct sponsorship देने पर विचार किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-19
Hacker News की राय

  • असल में इस्तेमाल करके देखा तो इससे गंभीर, जटिल ऐप बनाना संभव नहीं लगा
    दूसरे प्लेटफॉर्मों पर डिफॉल्ट रूप से मिलने वाले video, maps, rich text जैसे components इसमें नहीं हैं, और उन्हें खुद जोड़ने का कोई साफ़ और आसान रास्ता भी नहीं है
    हर कुछ महीनों में API टूट जाती है, और themes लगाने का तरीका भी नहीं है
    Immediate mode graphics तब तक अच्छे हैं जब तक जटिल state manage नहीं करनी पड़ती, लेकिन उसके बाद अंततः अपनी retained mode graphics लागू करनी पड़ती है, जिससे बहुत पहले हल हो चुकी समस्या फिर वापस आ जाती है
    piet-gpu आधारित चमकदार renderer भी input के रूप में सिर्फ Bezier curve control points लेकर सब कुछ tessellate करता है; concept शानदार है, लेकिन असल में circle बनाना हो तो 4 Bezier वाली approximation पर निर्भर रहना पड़ता है
    Wasm भी product-level बनने के लिए compile team द्वारा कई साल की engineering polish मांगने वाले proof of concept के करीब है, और कुल मिलाकर यह Go developers के लिए lists और input fields जैसी सरल UI बनाने में ठीक लगता है

    • इससे कुछ भी बनाया जा सकता है, और v0.6 में ये समस्याएं काफी कम झंझट वाली हो गई हैं
      Material Design theme भी है और light/dark mode भी
      light/dark और custom theme वाला एक अच्छा gioui app उदाहरण https://github.com/chapar-rest/chapar है
      Mac या Windows पर go run . ही काफी है
      text kerning, arc के साथ बहता text, और RTL/LTR भी github.com/go-text/typesetting की वजह से संभव हैं
      calendar spinner या diagram जैसे जटिल widgets भी GitHub पर हैं, लेकिन इन्हें एक जगह लाने की कोशिश की कमी है
      अगर ये चीजें इकट्ठी हो जाएं, तो और ज्यादा developers के जुड़ने की प्रेरणा काफी बढ़ सकती है
    • हर कुछ महीनों में टूटने वाले API changes Google code में निराशाजनक रूप से अक्सर दिखते हैं
      ऐसा लगता है कि user code न टूटे, इसे अहम मानने वाली culture नहीं है
    • अगर Wasm अहम है तो Uno Platform काफी अच्छा support देता है, और AvaloniaUI भी है
      दोनों अभी stable हैं और इनके पास controls और libraries का अपेक्षाकृत समृद्ध collection है

  • Web पर यह Flutter की तरह सब कुछ canvas पर render करता दिखता है, और यह तरीका accessibility और native feel के लिहाज से समस्याग्रस्त माना जाता है

    • Web पर यह निश्चित रूप से native जैसा महसूस नहीं होता और accessibility भी अच्छी नहीं है
      radio buttons के बीच tab से move नहीं किया जा सकता, और macOS पर CMD+A text field में सब select नहीं करता जबकि CTRL+A करता है
    • accessibility के लिए canvas के साथ-साथ कोई अदृश्य DOM रखने वाला variant है या नहीं, यह जानने की उत्सुकता है
      संभव तो लगता है, लेकिन काम भी काफी ज्यादा होगा
    • iPhone पर copy या paste तक बिल्कुल काम नहीं करता
    • यह मूल रूप से web app framework नहीं, बल्कि native GUI toolkit है, जिसके पास web backend है

  • विषय से थोड़ा हटकर, लेकिन आजकल cross-platform mobile/web apps बनाने का सबसे अच्छा तरीका क्या है, यह सोच रहा हूं
    चाहे business logic और UI दोनों साझा करने हों, या सिर्फ business logic साझा करना हो
    gomobile, Rust, TypeScript जैसे विकल्पों के बीच सोचता रहा
    एक समय TypeScript सबसे portable तकनीक जैसी लगी थी, इसलिए उसे सभी business logic में इस्तेमाल करना चाहता था, लेकिन पता चला कि iOS पर JavaScript को अच्छी performance के साथ चलाने का कोई अच्छा तरीका नहीं है

    • अभी शायद Flutter सबसे अच्छा विकल्प हो सकता है: https://flutter.dev/
      अगर UI को native में लिखकर सिर्फ business logic साझा करना भी ठीक है, तो Kotlin भी एक विकल्प है: https://kotlinlang.org/docs/multiplatform.html#kotlin-multip...
      Compose इस्तेमाल करें तो Kotlin से UI भी बनाया जा सकता है: https://www.jetbrains.com/lp/compose-multiplatform/
      हालांकि iOS support अभी alpha है और web “experimental” है, इसलिए अगर framework के evolve होने के साथ code बदलने की स्थिति नहीं झेलनी, तो सभी platforms पर पहले से काफी stable Flutter ही सही है
      अगर आप TypeScript और React पहले से जानते हैं तो React Native पर भी विचार कर सकते हैं, लेकिन iOS या बाकी जगहों पर performance की गारंटी देकर कहना मुश्किल है: https://reactnative.dev/
    • जिन apps में polish चाहिए, उनके लिए native UI सही है
      ऐसे बहुत सारे frameworks देखे हैं जिन्होंने सब कुछ हल कर देने का वादा किया और निभा नहीं पाए
      शुरुआत में आप तेज़ी से शुरू करते हैं, लेकिन जल्द ही OS update के बाद FPS को native के करीब लाने या system animations को ज्यादा मिलता-जुलता बनाने के लिए core libraries patch करने लगते हैं
      समय सिर्फ तब बचता है जब UI को polish नहीं करना होता
      core logic साझा किया जा सकता है
      gomobile इस्तेमाल कर रहा हूं और कुल मिलाकर पसंद है, लेकिन runtime overhead 3MB है, इसलिए web के लिए ठीक नहीं है
      Kotlin Multiplatform अच्छा लगा था, लेकिन basic libraries गायब थीं, और शायद इसलिए कि वे Kotlin Android में पहले से हैं, उनके multiplatform counterparts बनाने वाले लोग कम थे
      Rust और Mozilla की language binding layer भी अच्छी लगती है, लेकिन अभी इस्तेमाल नहीं की है
    • React Native और Expo के combination की सलाह दूंगा
      Flutter भी बुरा नहीं है, लेकिन web canvas में render करता है, इसलिए feel और accessibility के मामले में खास नहीं है
      iOS में भी Impeller rendering engine आने के बाद भी अभी latency की समस्या है
      Bluesky client को देखें तो supported platforms पर performance ठीक है और single codebase इस्तेमाल करता है
      https://github.com/bluesky-social/social-app
    • Uno(https://platform.uno) है
      open source है और Android, iOS, Windows, Mac, Linux को target करता है: https://platform.uno/platforms/
      C# इस्तेमाल करता है, और हर platform के native UI framework में views और controls को automatically implement करता है
      Visual Studio, VS Code, Rider जैसे IDE का support भी अच्छा है और बाकी tools तक सीमित भी नहीं करता
      design collaboration के लिए Figma plugin भी है
    • हम Tauri इस्तेमाल करते हैं, लेकिन यह महत्वपूर्ण है कि हम इसे सिर्फ internal tools के लिए इस्तेमाल करते हैं
      consumer products के लिए भी यह अच्छा tool है या नहीं, पता नहीं
      हमारे use case के लिए यह काफी अच्छे से फिट बैठता है, क्योंकि ये मुख्य रूप से solar power plant technicians के tools हैं, और खराब internet conditions में cross-platform TypeScript इस्तेमाल करना छोटी team के लिए बहुत भारी पड़ने लगा था

  • मैं gioui से streaming app बना रहा हूं, और यह बहुत आसान है, upgrades भी हमेशा smooth रहते हैं
    क्योंकि यह Go है और core developers changes को काफी गंभीरता से लेते हैं
    जब web GUI की जरूरत होती है तो यह gioui plugin system इस्तेमाल करता हूं: https://github.com/gioui-plugins/gio-plugins
    WebView web, desktop, mobile पर काम करता है, यह हैरान करने वाला है
    deep links भी काम करते हैं, इसलिए email या Monike notification link भेजें तो user app GUI में ठीक उसी जगह खुलता है
    सभी OS के लिए notifications और share extensions भी हैं, इसलिए मुझे यह सच में लगभग complete system लगता है
    सभी OS support करना मुश्किल है, इस बात से सहमत हूं, लेकिन आज की दुनिया में diversity default है
    कई technologies के बीच आना-जाना किए बिना सिर्फ Go से यह सब कर पाना अच्छा लगता है
    Go backend हमेशा इस तरह लिखता हूं कि वह gio और HTML दोनों में चले
    SEO या video playback चाहिए तो WebView में handle करता हूं, और gio web side पर Google SEO को भी satisfy किया जा सकता है
    Hugo में Markdown डालकर Google SEO को दिखाता हूं

  • Go के शुरुआती व्यक्ति के नज़रिए से, documentation का यह हिस्सा जिज्ञासा पैदा करता है
    ops.Add(ColorOp{Color: red}) के बजाय op.ColorOp{Color: red}.Add(ops) इस्तेमाल करने की वजह यह बताई गई है कि Add method interface type argument न ले, ताकि call के समय allocation से बचा जा सके, और यह Gio के “zero allocation” design का मुख्य हिस्सा है
    मैं जानना चाहता हूँ कि allocation क्यों होता है, क्या allocate होता है, और इसे कैसे बचाया जाता है

    • यह Go द्वारा interface के ज़रिए dynamic type को handle करने के तरीके और struct के उसके साथ फिट होने के तरीके की वजह से है
      जब कोई function interface type argument लेता है और आप उसमें pure struct पास करते हैं, तो Go उसके आसपास एक wrapper बनाता है; quotation में जिस allocation की बात है, वही यह है
      यह wrapper type/vtable pointer और struct data pointer से बना pointer pair होता है
      इससे runtime type inference और implicit interface extension संभव होता है
      यानी interface implement करने के लिए methods implement करना काफी है, और ByteReader extends Reader की तरह type को explicit रूप से लिखने की जरूरत नहीं होती
      यह cost केवल इस्तेमाल करते समय चुकानी पड़ती है, इसलिए बहुत-सा fast-path code संभव हो तो सिर्फ structs का उपयोग करता है
    • Go में जब v := interfaceType(concreteTypeValue) करते हैं, तो low level पर मोटे तौर पर ऐसा होता है
      dataPtr := &concreteTypeValue, typePtr := typeData[concreteType](), और फिर data pointer और type pointer वाला interface value बनता है
      यहाँ पहली line allocation है, क्योंकि मेरी याद के नियम के अनुसार Go में pointers stack values की ओर point नहीं करते, इसलिए concreteTypeValue को heap पर allocate होना पड़ता है
      pointers का stack की ओर point न करना goroutine stacks को dynamically बढ़ाना आसान बनाने के लिए है
      https://go.dev/doc/faq#stack_or_heap देखें
    • पहले तरीके में ColorOp{Color: red} boxing होकर heap पर allocate होना पड़ता है
      क्योंकि ops.Add आम तौर पर concrete type value नहीं, बल्कि किसी खास interface को implement करने वाली value का मोटा pointer लेता है
    • सवाल का जवाब तो दूसरे जवाबों ने दे दिया है, लेकिन अलग से कहूँ तो op.ColorOp{Color: red}.Add(ops) पढ़ने में अजीब लगता है
      मुझे यह “op.ColorOp{Color: red} के result में ops जोड़ता है” जैसा पढ़ता है
      इसलिए मैं function का नाम AddTo रखना चाहूँगा: op.ColorOp{Color: red}.AddTo(ops)
      यह अब भी conventional नहीं है, लेकिन कम से कम यह signal देता है कि function argument modify होता है
    • https://stackoverflow.com/questions/39492539/go-implicit-con...

  • Windows 10 और Chrome चलाने वाले काफी सामान्य PC पर पहले page का WASM demo text वाली जगहों पर सिर्फ काले squares render कर रहा है, यह दिलचस्प है
    Android phone के Chrome पर यह सही render हुआ

    • सिर्फ मेरे साथ ऐसा नहीं था
      ऊपर से यह बेहद धीमा भी चला
    • Windows 11 के Edge पर भी वही हाल है

  • मैंने Go में Fyne इस्तेमाल करके एक छोटा app बनाया था, और अब दोबारा इस्तेमाल करने का इरादा नहीं है
    Gio और Fyne दोनों में Flutter जैसी polish और features की काफी कमी है
    core logic Golang में बनाकर उसे Android app में wrap करने का फैसला किया, लेकिन GUI ऐसा लगता था जैसे 2003 से निकला हो, और उसे ठीक करने के तरीके भी सीमित थे

    • एक और विकल्प Wails है
      सारा logic Go में लिखा जा सकता है और UI HTML में बनाया जा सकता है; web framework इस्तेमाल करें या न करें, दोनों ठीक हैं
      यह Electron जैसा है, लेकिन Chrome साथ में ship नहीं करता और system web viewer इस्तेमाल करता है, इसलिए हल्का है
      [1] https://github.com/wailsapp/wails
    • रोचक है
      अगर आप बता सकें कि Android app में इसे कैसे wrap किया, तो अच्छा होगा

  • ऐसी cross-platform GUI चीज़ें सब 50 साल पहले design की हुई जैसी क्यों दिखती हैं

    • मैं जानना चाहूँगा कि 1974 में आखिर आप क्या इस्तेमाल कर रहे थे कि यह आपको उस समय जैसा लगा

  • demo मेरे लिए काम नहीं कर रहा
    Win 11 के Chromium में कुछ buttons दिखते हैं, लेकिन ज़्यादातर सब काला है

  • Fyne के उलट, यह library मेरे पहले test यानी CJK text rendering में पास हो गई, यह अच्छा signal है
    Fyne यह तब तक नहीं कर पाता जब तक आप उसे सब कुछ render करने के लिए एक custom font न दें
    दुनिया भर में आम तौर पर इस्तेमाल होने वाली सभी writing systems, और emoji तक, संतोषजनक रूप से शामिल करने वाला एक font ढूँढना किस्मत की बात है
    इसलिए user-generated content, web content, या localization की थोड़ी भी संभावना वाली कोई चीज़ बनाते समय Fyne मेरे लिए तुरंत बाहर हो जाता है

    • इस मामले में Noto Sans काफी अच्छा है