Live data from Hacker News

Gio UI – Cross-platform GUI for Go

gioui.org

91–100 of 224 posts

Re: Gio UI – Cross-platform GUI for Go

#92
post #23

How does this compare with Fyne?

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 dif…

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.

Re: Gio UI – Cross-platform GUI for Go

#94
post #2

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.

Expo targets iOS, Android, web.

Re: Gio UI – Cross-platform GUI for Go

#95

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

I...would like to know what you were using in 1974 that looked like that.

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.

Re: Gio UI – Cross-platform GUI for Go

#96
post #47

Earlier quoted context omitted.

Thanks, which of the two would people recommend for a C# beginner? And is oidc well supported on all target platforms?

Both frameworks have various packages that add OIDC support to them so that shouldn't be an issue. As for beginner - there's quite a bit of learning curve in terms of writing GUI applications themselves. Avalonia is kind of like WPF* but good(tm) and cross-platform. Uno platform is more like Xamarin and MAUI except in a better shape as of today. From technical perspective, Avalonia focuses on consistent rendering on…

[deleted]

Re: Gio UI – Cross-platform GUI for Go

#97
post #47

Earlier quoted context omitted.

Businesses do seem to like AvaloniaUI and Uno. https://avaloniaui.net/ https://platform.uno/

Thanks, which of the two would people recommend for a C# beginner? And is oidc well supported on all target platforms?

If you are to use Avalonia, which I highly recommend, it may be best to start with WPF. The Visual Studio Community Edition has really good IDE support for WPF and there is a huge amount of information on how to do things in WPF which thankfully hasn't changed in a very long time. Plenty of old books and blogs that go into all manner of detail. Once you have what you wanted working as you want it is straightforward to port the WPF to Avalonia for cross platform support.

Yes this would necessitate using Windows, an OS which I abhor, but as of now . In time I hope that will change with improvements in both JetBrains Ryder and Avalonia.

Re: Gio UI – Cross-platform GUI for Go

#98

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.

I really think that the Lazarus Component Library took the right approach: https://en.wikipedia.org/wiki/Lazarus_Component_Library

I wonder why the idea of widgetsets never really went anywhere: https://en.wikipedia.org/wiki/Widgetset

You could take a program that says you need a button in the window and it would make one for you on Qt, GTK or whatever else was supported, on any platform that you were compiling for.

We might as well have gone a step further: your programming language --> UI toolkit bindings for your language --> programming language independent GUI toolkit --> widgetsets for GTK, Qt, WPF, Win32 or whatever else --> executable for that specific platform

With that many layers of abstraction it's likely that we'd get the lowest common denominators for all functionality across platforms, but at least it would run better than web technology does, with the accessibility and platform look & feel you'd expect.

Of course, for whatever reason, seems like nobody wanted to undertake the borderline crazy effort of creating something like that, something foundational for others to build upon, so that's why we get super fragmented frameworks that are bound to specific languages nowadays and each of them have to reinvent a wheel a lot.

Either way, FreePascal/Lazarus were pretty amazing for RAD: https://en.wikipedia.org/wiki/Lazarus_(software) except that the community and ecosystem isn't exactly getting bigger.

Re: Gio UI – Cross-platform GUI for Go

#99

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.

Building a cross-platform GUI toolkit takes an incredible amount of work & time, especially at the systems level.[0] A robust cross-platform ecosystem for the underlying programming language is a necessary but insufficient piece of the puzzle. Given the proliferation of HTML and WebView/web-tech wrappers (Electron, Tauri, React Native etc.) there are now enough "good enough" solutions that most organizations that wou…

Isn't the whole "Flutter team layoffs" narrative somewhat debunked at this point? My understanding is that some positions were cut and some were moved, but no more than any other engineering area at Google.

Re: Gio UI – Cross-platform GUI for Go

#100
post #23

Earlier quoted context omitted.

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 dif…

> Gio is pure Go 7% C is not pure Go.

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.

Post reply on HN