12 ms·

Gio UI – Cross-platform GUI for Go

299 points by gjvc 2y ago

anon-3988 2y ago
How does this compare with Fyne?
- mappu 2y ago
  They both owner-draw every widget themselves (not using platform native widgets). Gio is pure Go, Fyne is cgo. Gio is immediate-mode, Fyne is retained-mode. Flamewar starts here: I don't know why anyone would seriously choose an immediate mode GUI toolkit. When you receive an event, in immediate mode you have to recreate the whole world, then the toolkit has to then either rerender the world from scratch, or else diff the world against a clone on the heap, and rerender dirty regions. These kind of toolkits "advertise" hitting 60fps rerender speed as if that was impressive. In retained mode you merely don't respond to events you don't need to, the framebuffer doesn't need modification at all, and getting only 60fps updates would be embarassingly slow. I understand the appeal of integrating e.g. Dear Imgui into your game's render loop if you're already re-rendering the whole viewport. But for desktop/mobile applications where the platform has a retained framebuffer, it seems like a deliberate deoptimisation.
  - ramon156 2y ago
    One positive side of immediate mode is that the code becomes a lot more straight forward. You only see that loop function, so it's very nice if you need a POC, or if it's going to be ran on embedded.
    - mappu 2y ago
      Here's some pseudocode for argument's sake: http://paste.debian.net/1317369 http://paste.debian.net/1317369 I don't think the immediate-mode code is really more straightforward. Retained mode looks just as simple and only has that one same function with the same 5 basic SLoC, only - (A) the ui library has to do less work at runtime, resulting in a more responsive app (as per parent comment); - (B) i was forced to reorder the component instantiation. In immediate mode, the counter's label depends on the button's state, whereas in retained mode, the button update callback depends on the counter instead; and - (C) immediate mode only needed one sprintf instead of two since the initialization and update logic is unified. You can combine them in retained mode with a helper function or closure (and in real-world apps you would); in this trivial case this increases the SLoC but in real-world cases it reduces it.
  - metaltyphoon 2y ago
    > Gio is pure Go 7% C is not pure Go.
    - tredre3 2y ago
      There is hardly any real C code in Gio, it's just bindings for the platforms' APIs (X11, Wayland, GL). Somehow, they managed to avoid requiring CGO on Windows so it's 100% Go there.
  - pants2 2y ago
    I recently wrote a little document previewer in Fyne. It's a great experience and super easy to build simple GUIs, however Fyne struggled with a few pages of text (slow scrolling and resizing). I'll have to try Gio.
gedw99 2y ago
Have been using gioui to build streaming apps. It’s very easy and upgrading is always easy because it’s golang and the core devs take it seriously when they make a change. When I need a web gui I use a gioui plugin system here: https://github.com/gioui-plugins/gio-plugins https://github.com/gioui-plugins/gio-plugins WebViews work on web, desktop and mobile. It’s amazing. Deep linking also so you can send out a link to an email or Monike notification and the users app will open the gio gui in the right part of the gui. It also has notifications and share extensions for all OS’s. It’s really a complete system. I can’t believe how much devs complain about things not being easy , when it’s all there. I definitely share the feelings that’s it’s so hard to support so many OS’s, but it’s the world we live in - plurality. I like how I can do all of this with only golang , instead of switching between bits and bobs. I always write my golang backend to work with gio and html. So if I need SEO or video playback I can still do it in a web view and also keep googles seo happy for the gio web. I just use Hugo and feed it markdown. This is what Google SEO sees.
bsaul 2y ago
A bit off-topic, but what's the best method to build cross-platform mobile & web apps nowadays ? I'm talking either business logic + UI , or just business logic ? like gomobile, rust, typescript, etc ? At some point i thought about using typescript for all business logic, as it seemed the most portable tech, but i realized there's no good way to have decent performance running javascript on iOS.
- Pepe1vo 2y ago
  What's your definition of decent performance? My company has built quite a few complex capacitor + Angular + Ionic apps and the performance on iOS is fine. Some even got featured by Apple, so that should be some indication that quality and performance was alright.
- devjab 2y ago
  We use Tauri, but I think that it’s important to know that we solely use it for internal tools. I have no idea if it’s a good tool for consumer facing products. It works well enough for what we use it for, which is mostly for our solar park technicians where using cross platform Typescript on terrible internet became too much work for our small team.
  - junon 2y ago
    We use Tauri at GitButler and love it.
  - DreaminDani 2y ago
    Agreed. Tauri for desktop, capacitor for mobile. Bring your own front-end library either way.
- brabel 2y ago
  The best option is probably Flutter right now: https://flutter.dev/ https://flutter.dev/ If you don't mind writing the UI native, sharing only business logic code, Kotlin is an option: https://kotlinlang.org/docs/multiplatform.html#kotlin-multiplatform-use-cases https://kotlinlang.org/docs/multiplatform.html#kotlin-multip... Kotlin also can do the UI if you use Compose: https://www.jetbrains.com/lp/compose-multiplatform/ https://www.jetbrains.com/lp/compose-multiplatform/ ... however, iOS support is still in alpha, and Web is "experimental". If you're not willing to cope with that (expect to have to change your code as they develop the framework) then Flutter is the way as it's pretty stable already on all platforms. If you already know Typescript and React, you may also consider React Native (but I can't attest to its performance on iOS or anywhere else): https://reactnative.dev/ https://reactnative.dev/
shikaan 2y ago
Go newbie here. Can anybody elaborate on this piece of the docs? """ You might be thinking that it would be more usual to have an ops.Add(ColorOp{Color: red}) method instead of using op.ColorOp{Color: red}.Add(ops). It’s like this so that the Add method doesn’t have to take an interface-typed argument, which would often require an allocation to call. This is a key aspect of Gio’s “zero allocation” design. """ Why would there be an allocation? Of what? How are we saving it?
- foldr 2y ago
  On the first approach ColorOp{Color: red} would have to be boxed and thus heap allocated. This is because ops.Add in general would receive a (fat) pointer to a value implementing a particular interface rather than a value of concrete type. (The sibling comment written at the same time has a more detailed explanation of the 'fat' part.)
- ainar-g 2y ago
  Whenever you do: v := interfaceType(concreteTypeValue) in Go, what you're actually doing on a lower level is: dataPtr := &concreteTypeValue typePtr := typeData[concreteType]() v := interfaceData{ data: dataPtr, typ: typePtr, } The first line here is the allocation, since (at least, the way I recall the rule) in Go pointers never point to values on the stack, so concreteTypeValue must be allocated on the heap. The rule about pointers not pointing to the stack is there to make it easier for goroutine stacks to grow dynamically. See https://go.dev/doc/faq#stack_or_heap https://go.dev/doc/faq#stack_or_heap.
  - foldr 2y ago
    >in Go pointers never point to values on the stack This is only the case for pointers that the compiler can't prove not to escape: >In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.
    - 2y ago
DrDroop 2y ago
Experience report: Impossible to write any serious complex application in this. Lacks components for basic things everyone gets for free on other platforms, things like video, maps or rich text components. Nor does if offer any clear easy path to add them yourself. Breaking API changes every few months. No way to theme something. Immediate mode graphics are great until you need to start managing some complex state, then you are forced to implement your own retainer mode graphics. Again it reintroduces problems that have been solved a long time ago. Very fancy renderer based on piet-gpu that only takes control points of a bezier curve as input and tessellates everything from that. Cool concept, but try drawing a real circle with that, and some some approximation with 4 bezier curves. Wasm is not more then a proof of concept that won't be production ready without years of engineering by compile team. Overall nice for Go developers that wanna do some simple UI with lists and input fields.
- gedw99 2y ago
  You can write anything with it. V0.6 made your issues much less tricky. Also there is a Material Design theme. And also light and dark. Here is an excellent example of a gioui app that has light / dark with a custom theme. https://github.com/chapar-rest/chapar https://github.com/chapar-rest/chapar If you’re on MAC or Windows it’s just “ go run .”. If you wanted text keening or text sweeping around an arc or RTL / LRT it can do it thanks to github.com/go-text/typesetting Complex widgets for Calendar spinners or diagrams are out there on GitHub. An effort to bring these together is lacking, and I reckon that if all these things weee brought together it would definitely encourage more developers to dive in.
- neonsunset 2y ago
  If you care about WASM, Uno Platform has decent support for it, there’s also AvaloniaUI and both are stable at this point with relatively rich control collections and libraries.
- mort96 2y ago
  > Breaking API changes every few months. I find this to be the case with a depressing amount of Google code. They do not seem to have a culture which values not breaking their users' code.
w1nst0nsm1th 2y ago
Blazor is cross-platform, in combo with MAUI.NET
- lakomen 2y ago
  I didn't downvote. AFAIK it's not supporting Linux as a target platform. Correct me if I'm wrong.
  - andsoitis 2y ago
    .NET MAUI supported platforms: * Android 5.0 (API 21) or higher is required. * iOS 11 or higher is required * macOS 10.15 or higher, using Mac Catalyst * Windows 11 and Windows 10 version 1809 or higher While Linux isn't supported, that is also not a typically significant market for GUI apps. https://learn.microsoft.com/en-us/dotnet/maui/supported-platforms?view=net-maui-8.0 https://learn.microsoft.com/en-us/dotnet/maui/supported-plat...
    - bornfreddy 2y ago
      However Linux has a non-negligible share among platforms that developers use (as a daily driver). To me, as a Go developer, this library is dead on arrival. It would take extraordinary circumstances to consider it for an app (even in business setting).
      - neonsunset 2y ago
        For Linux, there are Avalonia, Uno Platform and Gir.Core (rich GObject and GTK4 bindings). The point of MAUI is to be a successor to Xamarin, for which the primary target are mobile devices, by far the largest market niche.
shrubble 2y ago
The amazing thing is that 30 years ago there were cross platform toolkits like Neuron Data and the toolkit under OpenOffice(called StarOffice originally), and yet today the options are still fragmented and imperfect. We have far better compilers and even languages for cross-platform work, so it should be easier by now.
- throwaway894345 2y ago
  I’m not sure whether those toolkits abstracted over native GUI interfaces or whether they attempted to recreate a native look and feel or whether they attempted to provide their own look and feel across platforms, but in any case the problem isn’t languages and compilers, it’s that the expectations for a GUI toolkit are dramatically greater now than then. Here are a few things that are (I think) expected from GUI toolkits today, but not 30 years ago: * Hardware acceleration (in particular abstracting over metal, opengl, direct x, vulkan, etc) * More complex layouts * Animations * Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ * Accessibility And if you want to emulate a native experience, getting keyboard shortcuts, focus behavior, and a billion other details correct is nearly impossible. And by the way, today we have web engines that take care of most of these things for free and a huge pool of people who know how to build for them, so it’s often easier to leverage that capability than to essentially reinvent them. And if people can contain their knee-jerk anti-electron reaction for a moment, I think that’s a pretty reasonable approach. I would really like to see something like an unlocked ChromeOS where the browser is the native interface, but unlike electron, we don’t ship a web browser with each app. Especially as webasm takes form, I could see this as a more compelling solution for cross-platform graphics with multi-language support than cross-language bindings or by trying to maintain a toolkit per language while trying to maintain some illusion of a consistent experience.
  - jwells89 2y ago
    In some ways, expectations for UI toolkits have dropped too, though. Practically no UI toolkits created in the past 5-10 years come with a row recycling tableview/datagrid widget (table with column headers, sort by column, etc) for example, which used to be table stakes (which is why they’re present in Win32, MFC, AppKit, GTK, and Qt among others of the old guard). New toolkits that lacked a tableview would not have been taken seriously back then. This has been a major blocker for my adoption of newer toolkits. I understand that it’s a result of mobile UI trends dominating the space, but that’s not helpful when I’m looking to build useful desktop apps, for which these widgets are crucial. Relying on third party libraries to fill these gaps (if they even exist) isn’t appealing either, adding yet another dependency to the pile and making a major part of my app subject to likely eventual abandonment by the library’s dev.
oefrha 2y ago
It's a good sign that unlike fyne, this library passed the very first test I threw at it: rendering some CJK text. Fyne can't do that unless you give it one custom font to render everything in — well, good luck finding one satisfactory font encompassing all commonly used scripts around the world, not to mention emojis. Which means fyne is immediately dead to me whenever I'm building anything with a remote chance of user-generated/web content and/or localization.
- maccard 2y ago
  Noto sans is pretty good in this regard.
  - oefrha 2y ago
    Noto Sans isn't limited to Latin — it supports Cyrillic and Greek as well — but immediately fails my CJK test. Or Arabic, or various other scripts used by half of the world.
flohofwoe 2y ago
Interesting that the WASM demo on the front page just render a black rectangle where the text is supposed to be on my fairly vanilla Windows 10 PC with Chrome (it rendered fine in Chrome on my Android phone).
- bwat49 2y ago
  same here with edge on windows 11
- joezydeco 2y ago
  It wasn't just me. Whew. It also ran incredibly slow.
glass-z13 2y ago
Yet non of the GUI libraries/frameworks for GO support drag/drop file to get the real path
andsoitis 2y ago
doesn't appear to support Unicode.
diskdance 2y ago
Seemingly it's using a <canvas> to render everything just like Flutter on Web, which is known to have problems with accessibility and feel non-native.
- mort96 2y ago
  I mean it's not primarily a web app framework, it's a native GUI toolkit which has a web back-end.
  - Longhanks 2y ago
    It isn't native on any other platform either.
    - mort96 2y ago
      I used "native" as opposed to "web" (think "native code"), not as in "uses Cocoa on macOS". I should've been more precise.
- afavour 2y ago
  I’m curious if anyone has a variant of this idea where an invisible DOM lives alongside the canvas for accessibility reasons. It should work but I imagine it would also take a lot of work.
  - mwcampbell 2y ago
    This is how Flutter for web implements accessibility. It's been a while since I checked, but last time I tried using a Flutter app on the web with a screen reader, there were problems. I don't remember specifics.
    - serial_dev 2y ago
      Flutter on Web is still mainly not accessible when it comes to screen readers, despite what anyone wants to make you believe. I checked it last a couple of weeks ago on my Android phone, and the result was so poor, I didn't check with other platforms. You need to "opt in" to accessibility as a user, so in the beginning you have one button visible to screen readers, then your screen reader sees that single button, then you need to "double tap to activate" to make the rest of the document screen readable. Then, somehow they made a funky screen reader voice read stuff out loud, not my system's voice, with all the awkwardness and issues that come with it. On lists, it only recognized the items that were on screen, if you had to "scroll", you are out of luck. Now, I'm sure someone will come and tell me how I'm holding it wrong, but somehow, every website and even Flutter on mobile got the accessibility mainly right by default, on Flutter web the accessibility situation is very poor.
okasaki 2y ago
The demo doesn't work for me. I see some buttons but mostly it's all black. Chromium on Win 11.
andreygrehov 2y ago
Why do all these cross-platform GUIs look like they were designed 50 years ago?
- paulddraper 2y ago
  I...would like to know what you were using in 1974 that looked like that.
  - andreygrehov 2y ago
    Heh. The "50 years ago" part was an intentional stretch to add more weight to how disappointed I am. But seriously, the first demo they presented is an immediate rejection.
    - anthk 2y ago
      Smalltalk wasn't that far ;)
      - igouy 2y ago
        https://news.ycombinator.com/item?id=40400572 https://news.ycombinator.com/item?id=40400572
    - tazjin 2y ago
      The first demo is a Webassembly thing that looks like any generic web thing. The next one is a cryptocurrency app that seems to have a "modern" design. The other ones (gotraceui, sointu) seem like they might be what you're talking about. I can see how they might be scary to someone used to "modern" UIs because their information density is much higher. Personally I'd prefer if more people treated computers like a tool, and not some kind of art installation.
      - andreygrehov 2y ago
        I was referring to the Webassembly one. Looks like the design was largely inspired by the Material Design created by Google. Material Design is a massive failure and nobody should use it these days. The cryptocurrency app looks good. The gotraceui and sointu are actually decent. They are niche tools and look fine to me.
999900000999 2y ago
I built a small app in Go using Fyne. Never again. Both Gio and Fyne lack tons of polish and features Flutter provides. I built my core logic in Golang, and then decided to wrap it in an Android app. The GUI feels like it came out of 2003 with limited ways to fix it.
- saganus 2y ago
  Sounds interesting. How did you wrap it in an Android app if you could elaborate?
  - 999900000999 2y ago
    Simple, I basically wrote a script to figure out probabilities for gambling ( I won't open source it since I don't want someone angry at me when they lose money). Then you basically have the UI layer call the script. It's really hacked together, but it works.
- PhilippGille 2y ago
  A different option is Wails [1], which allows you to write all logic in Go, and the UI in HTML (with any or no web framework). It's like Electron but lighter because it doesn't ship Chrome but uses the system's web viewer instead. [1] https://github.com/wailsapp/wails https://github.com/wailsapp/wails
  - buildbuildbuild 2y ago
    Wails is great. Also, see Tauri for a similar lightweight approach in the Rust ecosystem.
- deleted 2y ago
  [deleted]
cabalamat 2y ago
I note form the demo that there's a "Flat" button that looks like normal text. This is a mis-feature and should be removed; controls should look different from things you can't interact with.
- gjvc 2y ago
  strongly agree
luismedel 2y ago
Not about Gio UI but related. I'm really enjoying the conversation around UI toolkits here. But I think we're all missing the elephant in the room and it's that we already had (have?) a superb toolkit and development model in the Visual Basic (later Windows Forms) era and nothing really manages to replicate that experience nowadays. Microsoft destroyed it when they tried to push WPF and later shenanigans, only to realize it was a mistake years later. I can't understand why we all, as a sector, agree about standards being a good thing, even if some are only de facto, and never agreed to maintain that really simple model. I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft". Edit: typo
- deleted 2y ago
  [deleted]
- skydhash 2y ago
  > I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft". > Microsoft destroyed it when they tried to[…] only to realize it was a mistake years later. Answer is right there.
siproprio 2y ago
Can't even right click text lol

299 points by gjvc 2y ago

anon-3988 2y ago

How does this compare with Fyne?

mappu 2y ago
They both owner-draw every widget themselves (not using platform native widgets). Gio is pure Go, Fyne is cgo. Gio is immediate-mode, Fyne is retained-mode. Flamewar starts here: I don't know why anyone would seriously choose an immediate mode GUI toolkit. When you receive an event, in immediate mode you have to recreate the whole world, then the toolkit has to then either rerender the world from scratch, or else diff the world against a clone on the heap, and rerender dirty regions. These kind of toolkits "advertise" hitting 60fps rerender speed as if that was impressive. In retained mode you merely don't respond to events you don't need to, the framebuffer doesn't need modification at all, and getting only 60fps updates would be embarassingly slow. I understand the appeal of integrating e.g. Dear Imgui into your game's render loop if you're already re-rendering the whole viewport. But for desktop/mobile applications where the platform has a retained framebuffer, it seems like a deliberate deoptimisation.
- ramon156 2y ago
  One positive side of immediate mode is that the code becomes a lot more straight forward. You only see that loop function, so it's very nice if you need a POC, or if it's going to be ran on embedded.
  - mappu 2y ago
    Here's some pseudocode for argument's sake: http://paste.debian.net/1317369 http://paste.debian.net/1317369 I don't think the immediate-mode code is really more straightforward. Retained mode looks just as simple and only has that one same function with the same 5 basic SLoC, only - (A) the ui library has to do less work at runtime, resulting in a more responsive app (as per parent comment); - (B) i was forced to reorder the component instantiation. In immediate mode, the counter's label depends on the button's state, whereas in retained mode, the button update callback depends on the counter instead; and - (C) immediate mode only needed one sprintf instead of two since the initialization and update logic is unified. You can combine them in retained mode with a helper function or closure (and in real-world apps you would); in this trivial case this increases the SLoC but in real-world cases it reduces it.
- metaltyphoon 2y ago
  > Gio is pure Go 7% C is not pure Go.
  - tredre3 2y ago
    There is hardly any real C code in Gio, it's just bindings for the platforms' APIs (X11, Wayland, GL). Somehow, they managed to avoid requiring CGO on Windows so it's 100% Go there.
- pants2 2y ago
  I recently wrote a little document previewer in Fyne. It's a great experience and super easy to build simple GUIs, however Fyne struggled with a few pages of text (slow scrolling and resizing). I'll have to try Gio.

gedw99 2y ago

Have been using gioui to build streaming apps. It’s very easy and upgrading is always easy because it’s golang and the core devs take it seriously when they make a change. When I need a web gui I use a gioui plugin system here: https://github.com/gioui-plugins/gio-plugins https://github.com/gioui-plugins/gio-plugins WebViews work on web, desktop and mobile. It’s amazing. Deep linking also so you can send out a link to an email or Monike notification and the users app will open the gio gui in the right part of the gui. It also has notifications and share extensions for all OS’s. It’s really a complete system. I can’t believe how much devs complain about things not being easy , when it’s all there. I definitely share the feelings that’s it’s so hard to support so many OS’s, but it’s the world we live in - plurality. I like how I can do all of this with only golang , instead of switching between bits and bobs. I always write my golang backend to work with gio and html. So if I need SEO or video playback I can still do it in a web view and also keep googles seo happy for the gio web. I just use Hugo and feed it markdown. This is what Google SEO sees.

bsaul 2y ago

A bit off-topic, but what's the best method to build cross-platform mobile & web apps nowadays ? I'm talking either business logic + UI , or just business logic ? like gomobile, rust, typescript, etc ? At some point i thought about using typescript for all business logic, as it seemed the most portable tech, but i realized there's no good way to have decent performance running javascript on iOS.

Pepe1vo 2y ago
What's your definition of decent performance? My company has built quite a few complex capacitor + Angular + Ionic apps and the performance on iOS is fine. Some even got featured by Apple, so that should be some indication that quality and performance was alright.
devjab 2y ago
We use Tauri, but I think that it’s important to know that we solely use it for internal tools. I have no idea if it’s a good tool for consumer facing products. It works well enough for what we use it for, which is mostly for our solar park technicians where using cross platform Typescript on terrible internet became too much work for our small team.
- junon 2y ago
  We use Tauri at GitButler and love it.
- DreaminDani 2y ago
  Agreed. Tauri for desktop, capacitor for mobile. Bring your own front-end library either way.
brabel 2y ago
The best option is probably Flutter right now: https://flutter.dev/ https://flutter.dev/ If you don't mind writing the UI native, sharing only business logic code, Kotlin is an option: https://kotlinlang.org/docs/multiplatform.html#kotlin-multiplatform-use-cases https://kotlinlang.org/docs/multiplatform.html#kotlin-multip... Kotlin also can do the UI if you use Compose: https://www.jetbrains.com/lp/compose-multiplatform/ https://www.jetbrains.com/lp/compose-multiplatform/ ... however, iOS support is still in alpha, and Web is "experimental". If you're not willing to cope with that (expect to have to change your code as they develop the framework) then Flutter is the way as it's pretty stable already on all platforms. If you already know Typescript and React, you may also consider React Native (but I can't attest to its performance on iOS or anywhere else): https://reactnative.dev/ https://reactnative.dev/

shikaan 2y ago

Go newbie here. Can anybody elaborate on this piece of the docs? """ You might be thinking that it would be more usual to have an ops.Add(ColorOp{Color: red}) method instead of using op.ColorOp{Color: red}.Add(ops). It’s like this so that the Add method doesn’t have to take an interface-typed argument, which would often require an allocation to call. This is a key aspect of Gio’s “zero allocation” design. """ Why would there be an allocation? Of what? How are we saving it?

foldr 2y ago
On the first approach ColorOp{Color: red} would have to be boxed and thus heap allocated. This is because ops.Add in general would receive a (fat) pointer to a value implementing a particular interface rather than a value of concrete type. (The sibling comment written at the same time has a more detailed explanation of the 'fat' part.)
ainar-g 2y ago
Whenever you do: v := interfaceType(concreteTypeValue) in Go, what you're actually doing on a lower level is: dataPtr := &concreteTypeValue typePtr := typeData[concreteType]() v := interfaceData{ data: dataPtr, typ: typePtr, } The first line here is the allocation, since (at least, the way I recall the rule) in Go pointers never point to values on the stack, so concreteTypeValue must be allocated on the heap. The rule about pointers not pointing to the stack is there to make it easier for goroutine stacks to grow dynamically. See https://go.dev/doc/faq#stack_or_heap https://go.dev/doc/faq#stack_or_heap.
- foldr 2y ago
  >in Go pointers never point to values on the stack This is only the case for pointers that the compiler can't prove not to escape: >In the current compilers, if a variable has its address taken, that variable is a candidate for allocation on the heap. However, a basic escape analysis recognizes some cases when such variables will not live past the return from the function and can reside on the stack.
  - 2y ago

DrDroop 2y ago

Experience report: Impossible to write any serious complex application in this. Lacks components for basic things everyone gets for free on other platforms, things like video, maps or rich text components. Nor does if offer any clear easy path to add them yourself. Breaking API changes every few months. No way to theme something. Immediate mode graphics are great until you need to start managing some complex state, then you are forced to implement your own retainer mode graphics. Again it reintroduces problems that have been solved a long time ago. Very fancy renderer based on piet-gpu that only takes control points of a bezier curve as input and tessellates everything from that. Cool concept, but try drawing a real circle with that, and some some approximation with 4 bezier curves. Wasm is not more then a proof of concept that won't be production ready without years of engineering by compile team. Overall nice for Go developers that wanna do some simple UI with lists and input fields.

gedw99 2y ago
You can write anything with it. V0.6 made your issues much less tricky. Also there is a Material Design theme. And also light and dark. Here is an excellent example of a gioui app that has light / dark with a custom theme. https://github.com/chapar-rest/chapar https://github.com/chapar-rest/chapar If you’re on MAC or Windows it’s just “ go run .”. If you wanted text keening or text sweeping around an arc or RTL / LRT it can do it thanks to github.com/go-text/typesetting Complex widgets for Calendar spinners or diagrams are out there on GitHub. An effort to bring these together is lacking, and I reckon that if all these things weee brought together it would definitely encourage more developers to dive in.
neonsunset 2y ago
If you care about WASM, Uno Platform has decent support for it, there’s also AvaloniaUI and both are stable at this point with relatively rich control collections and libraries.
mort96 2y ago
> Breaking API changes every few months. I find this to be the case with a depressing amount of Google code. They do not seem to have a culture which values not breaking their users' code.

w1nst0nsm1th 2y ago

Blazor is cross-platform, in combo with MAUI.NET

lakomen 2y ago
I didn't downvote. AFAIK it's not supporting Linux as a target platform. Correct me if I'm wrong.
- andsoitis 2y ago
  .NET MAUI supported platforms: * Android 5.0 (API 21) or higher is required. * iOS 11 or higher is required * macOS 10.15 or higher, using Mac Catalyst * Windows 11 and Windows 10 version 1809 or higher While Linux isn't supported, that is also not a typically significant market for GUI apps. https://learn.microsoft.com/en-us/dotnet/maui/supported-platforms?view=net-maui-8.0 https://learn.microsoft.com/en-us/dotnet/maui/supported-plat...
  - bornfreddy 2y ago
    However Linux has a non-negligible share among platforms that developers use (as a daily driver). To me, as a Go developer, this library is dead on arrival. It would take extraordinary circumstances to consider it for an app (even in business setting).
    - neonsunset 2y ago
      For Linux, there are Avalonia, Uno Platform and Gir.Core (rich GObject and GTK4 bindings). The point of MAUI is to be a successor to Xamarin, for which the primary target are mobile devices, by far the largest market niche.

shrubble 2y ago

The amazing thing is that 30 years ago there were cross platform toolkits like Neuron Data and the toolkit under OpenOffice(called StarOffice originally), and yet today the options are still fragmented and imperfect. We have far better compilers and even languages for cross-platform work, so it should be easier by now.

throwaway894345 2y ago
I’m not sure whether those toolkits abstracted over native GUI interfaces or whether they attempted to recreate a native look and feel or whether they attempted to provide their own look and feel across platforms, but in any case the problem isn’t languages and compilers, it’s that the expectations for a GUI toolkit are dramatically greater now than then. Here are a few things that are (I think) expected from GUI toolkits today, but not 30 years ago: * Hardware acceleration (in particular abstracting over metal, opengl, direct x, vulkan, etc) * More complex layouts * Animations * Much hateful text rendering (e.g., right-to-left language support): https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/ * Accessibility And if you want to emulate a native experience, getting keyboard shortcuts, focus behavior, and a billion other details correct is nearly impossible. And by the way, today we have web engines that take care of most of these things for free and a huge pool of people who know how to build for them, so it’s often easier to leverage that capability than to essentially reinvent them. And if people can contain their knee-jerk anti-electron reaction for a moment, I think that’s a pretty reasonable approach. I would really like to see something like an unlocked ChromeOS where the browser is the native interface, but unlike electron, we don’t ship a web browser with each app. Especially as webasm takes form, I could see this as a more compelling solution for cross-platform graphics with multi-language support than cross-language bindings or by trying to maintain a toolkit per language while trying to maintain some illusion of a consistent experience.
- jwells89 2y ago
  In some ways, expectations for UI toolkits have dropped too, though. Practically no UI toolkits created in the past 5-10 years come with a row recycling tableview/datagrid widget (table with column headers, sort by column, etc) for example, which used to be table stakes (which is why they’re present in Win32, MFC, AppKit, GTK, and Qt among others of the old guard). New toolkits that lacked a tableview would not have been taken seriously back then. This has been a major blocker for my adoption of newer toolkits. I understand that it’s a result of mobile UI trends dominating the space, but that’s not helpful when I’m looking to build useful desktop apps, for which these widgets are crucial. Relying on third party libraries to fill these gaps (if they even exist) isn’t appealing either, adding yet another dependency to the pile and making a major part of my app subject to likely eventual abandonment by the library’s dev.

oefrha 2y ago

It's a good sign that unlike fyne, this library passed the very first test I threw at it: rendering some CJK text. Fyne can't do that unless you give it one custom font to render everything in — well, good luck finding one satisfactory font encompassing all commonly used scripts around the world, not to mention emojis. Which means fyne is immediately dead to me whenever I'm building anything with a remote chance of user-generated/web content and/or localization.

maccard 2y ago
Noto sans is pretty good in this regard.
- oefrha 2y ago
  Noto Sans isn't limited to Latin — it supports Cyrillic and Greek as well — but immediately fails my CJK test. Or Arabic, or various other scripts used by half of the world.

flohofwoe 2y ago

Interesting that the WASM demo on the front page just render a black rectangle where the text is supposed to be on my fairly vanilla Windows 10 PC with Chrome (it rendered fine in Chrome on my Android phone).

bwat49 2y ago
same here with edge on windows 11
joezydeco 2y ago
It wasn't just me. Whew. It also ran incredibly slow.

glass-z13 2y ago

Yet non of the GUI libraries/frameworks for GO support drag/drop file to get the real path

andsoitis 2y ago

doesn't appear to support Unicode.

diskdance 2y ago

Seemingly it's using a <canvas> to render everything just like Flutter on Web, which is known to have problems with accessibility and feel non-native.

mort96 2y ago
I mean it's not primarily a web app framework, it's a native GUI toolkit which has a web back-end.
- Longhanks 2y ago
  It isn't native on any other platform either.
  - mort96 2y ago
    I used "native" as opposed to "web" (think "native code"), not as in "uses Cocoa on macOS". I should've been more precise.
afavour 2y ago
I’m curious if anyone has a variant of this idea where an invisible DOM lives alongside the canvas for accessibility reasons. It should work but I imagine it would also take a lot of work.
- mwcampbell 2y ago
  This is how Flutter for web implements accessibility. It's been a while since I checked, but last time I tried using a Flutter app on the web with a screen reader, there were problems. I don't remember specifics.
  - serial_dev 2y ago
    Flutter on Web is still mainly not accessible when it comes to screen readers, despite what anyone wants to make you believe. I checked it last a couple of weeks ago on my Android phone, and the result was so poor, I didn't check with other platforms. You need to "opt in" to accessibility as a user, so in the beginning you have one button visible to screen readers, then your screen reader sees that single button, then you need to "double tap to activate" to make the rest of the document screen readable. Then, somehow they made a funky screen reader voice read stuff out loud, not my system's voice, with all the awkwardness and issues that come with it. On lists, it only recognized the items that were on screen, if you had to "scroll", you are out of luck. Now, I'm sure someone will come and tell me how I'm holding it wrong, but somehow, every website and even Flutter on mobile got the accessibility mainly right by default, on Flutter web the accessibility situation is very poor.

okasaki 2y ago

The demo doesn't work for me. I see some buttons but mostly it's all black. Chromium on Win 11.

andreygrehov 2y ago

Why do all these cross-platform GUIs look like they were designed 50 years ago?

paulddraper 2y ago
I...would like to know what you were using in 1974 that looked like that.
- andreygrehov 2y ago
  Heh. The "50 years ago" part was an intentional stretch to add more weight to how disappointed I am. But seriously, the first demo they presented is an immediate rejection.
  - anthk 2y ago
    Smalltalk wasn't that far ;)
    - igouy 2y ago
      https://news.ycombinator.com/item?id=40400572 https://news.ycombinator.com/item?id=40400572
  - tazjin 2y ago
    The first demo is a Webassembly thing that looks like any generic web thing. The next one is a cryptocurrency app that seems to have a "modern" design. The other ones (gotraceui, sointu) seem like they might be what you're talking about. I can see how they might be scary to someone used to "modern" UIs because their information density is much higher. Personally I'd prefer if more people treated computers like a tool, and not some kind of art installation.
    - andreygrehov 2y ago
      I was referring to the Webassembly one. Looks like the design was largely inspired by the Material Design created by Google. Material Design is a massive failure and nobody should use it these days. The cryptocurrency app looks good. The gotraceui and sointu are actually decent. They are niche tools and look fine to me.

999900000999 2y ago

I built a small app in Go using Fyne. Never again. Both Gio and Fyne lack tons of polish and features Flutter provides. I built my core logic in Golang, and then decided to wrap it in an Android app. The GUI feels like it came out of 2003 with limited ways to fix it.

saganus 2y ago
Sounds interesting. How did you wrap it in an Android app if you could elaborate?
- 999900000999 2y ago
  Simple, I basically wrote a script to figure out probabilities for gambling ( I won't open source it since I don't want someone angry at me when they lose money). Then you basically have the UI layer call the script. It's really hacked together, but it works.
PhilippGille 2y ago
A different option is Wails [1], which allows you to write all logic in Go, and the UI in HTML (with any or no web framework). It's like Electron but lighter because it doesn't ship Chrome but uses the system's web viewer instead. [1] https://github.com/wailsapp/wails https://github.com/wailsapp/wails
- buildbuildbuild 2y ago
  Wails is great. Also, see Tauri for a similar lightweight approach in the Rust ecosystem.
deleted 2y ago
[deleted]

cabalamat 2y ago

I note form the demo that there's a "Flat" button that looks like normal text. This is a mis-feature and should be removed; controls should look different from things you can't interact with.

gjvc 2y ago
strongly agree

luismedel 2y ago

Not about Gio UI but related. I'm really enjoying the conversation around UI toolkits here. But I think we're all missing the elephant in the room and it's that we already had (have?) a superb toolkit and development model in the Visual Basic (later Windows Forms) era and nothing really manages to replicate that experience nowadays. Microsoft destroyed it when they tried to push WPF and later shenanigans, only to realize it was a mistake years later. I can't understand why we all, as a sector, agree about standards being a good thing, even if some are only de facto, and never agreed to maintain that really simple model. I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft". Edit: typo

deleted 2y ago
[deleted]
skydhash 2y ago
> I remember Mono tried to bring that to all platforms and everybody ignored/smashed them because "it's Microsoft". > Microsoft destroyed it when they tried to[…] only to realize it was a mistake years later. Answer is right there.

siproprio 2y ago

Can't even right click text lol