I am always happy to see Go UI Toolkits. The lack of full macOS support on Goey and the decision to target GNUStep instead of Mac Cocoa proper is... interesting.
I’ll probably stick with Fyne for the time being. It’s fine.
I guess very close alternative to Goey will be GioUI [0]. It is really simple in the implementation, so it also covers many platforms as targets [1]. However, that is also a problem - there aren't many prepared components as in Qt or SwiftUI, no "native" feel of mouse or clipboard handling. One of the example of app I have found in the Internet is GUI for the password-store [2].
What good would accessing the API do without a Mac? If you are suggesting that you need a Mac to even write code that interacts with it then I would be shocked to find out that is true. Also, how would you even build something for the Cocoa API without a Mac?
Libui works on multiple platforms with native UI. QT, GTK and Fyne work around this each in their own way. Fyne is a very interesting solution as it just renders everything in OpenGL.
At first I didn’t like Fyne but from a visual standpoint but after switching to the light theme it has really grown on me. And the cross platform bugs I used to get with libui are pretty much non existent. It is so much simpler to support one rendering engine that all of the platforms support vs multiple implementations of the same thing. It might work for simple apps but the platform specific quirks start adding up and it becomes a maintenance headache. After switching to Fyne I’ve been very happy.
>What good would accessing the API do without a Mac?
... allowing ppl to write software without needing to shell out $$$'s to Apple ?
> Also, how would you even build something for the Cocoa API without a Mac?
well, with GNUStep which is a reimplementation of the Cocoa API, like the project we're discussing.
There's no issue building for instance stuff that targets Windows on Linux - I routinely build windows software from my linux by using MinGW and testing it with Wine. GNUStep provides a kind of approximation of that but it is much less up-to-date wrt Cocoa than MinGW is wrt Win32 API
> I don't write in Go but from what I read the language isn't oriented towards GUI app development.
Go was created as an improvement on C/C++ with faster compile times, mostly-safe memory management, easy threading implementations and cross-platform.
Usually, it'll be used in networking applications, but nothing keeps you from using Go in GUI apps.
> Are there any obvious reasons why Apple and Google haven't adopted it for mobile apps?
Android already has an incredible platform running on the JVM with years of work to optimize and create dev-friendly APIs. You could build a compiler that compiles Go running on the JVM and use Android APIs if you really hate Java.
A lot of GUI apps now use Electron, which is easy for web frontend devs to pick up and run. Plus you can use web frameworks like React, etc to run them. The major deficit here is that it uses a ton of memory for nothing, but hopefully frameworks like Flutter will come in and take their place.
It wasn't originally designed with GUIs in mind but that doesn't necessarily mean it would be bad at it. Some people don't consider Go well suited for GUI programming as most of that large GUI platforms are traditional Object Oriented frameworks that wouldn't work as well with Go.
Google and Apple haven't adopted it as they were already developing languages/platforms targeting GUI development (Dart/Flutter and Swift respectively). Also Go is a young language targeting a different niche so there was nothing pushing it this way.
The two layouts are very similar.
I’m a Professional Go Programmer, but I find the Swift example (and similar Flutter examples) much more suited to describing interfaces.
The approach is a hybrid. The declarative approach with reconcilation (tree diffing) comes from React. The automatic layout with constraints does come from Flutter.
Golang projects like to have a play on words with “go” or just prefixed like “go-commander”. Such as Hugo static site generator, the mascot gopher, Gorilla web toolkit...
Why not just put html/css inside a go-http-binary and use the browser as the UI part, that will be 100% portable and browser is universal these days anyways.
25 comments
[ 3.3 ms ] story [ 57.9 ms ] threadI’ll probably stick with Fyne for the time being. It’s fine.
For assets, I use go-bindata to embed them into my binary, personally.
https://github.com/go-bindata/go-bindata
Based on this line from the README, and the fact that the Cocoa screenshots are from Linux, I'd guess the author doesn't have a Mac:
>If you can either test on Macs, or provide build systems, please contact us.
[0]: https://gioui.org/
[1]: https://www.youtube.com/watch?v=PxnL3-Sex3o
[2]: https://git.wow.st/gmp/passgo
complain to Apple which makes it illegal to have access to the Cocoa API if you don't own a Mac
Libui works on multiple platforms with native UI. QT, GTK and Fyne work around this each in their own way. Fyne is a very interesting solution as it just renders everything in OpenGL.
At first I didn’t like Fyne but from a visual standpoint but after switching to the light theme it has really grown on me. And the cross platform bugs I used to get with libui are pretty much non existent. It is so much simpler to support one rendering engine that all of the platforms support vs multiple implementations of the same thing. It might work for simple apps but the platform specific quirks start adding up and it becomes a maintenance headache. After switching to Fyne I’ve been very happy.
That's true. For iOS too. Sorry.
... allowing ppl to write software without needing to shell out $$$'s to Apple ?
> Also, how would you even build something for the Cocoa API without a Mac?
well, with GNUStep which is a reimplementation of the Cocoa API, like the project we're discussing.
There's no issue building for instance stuff that targets Windows on Linux - I routinely build windows software from my linux by using MinGW and testing it with Wine. GNUStep provides a kind of approximation of that but it is much less up-to-date wrt Cocoa than MinGW is wrt Win32 API
Can anyone explain why this is the case? Are there any obvious reasons why Apple and Google haven't adopted it for mobile apps?
Go was created as an improvement on C/C++ with faster compile times, mostly-safe memory management, easy threading implementations and cross-platform.
Usually, it'll be used in networking applications, but nothing keeps you from using Go in GUI apps.
> Are there any obvious reasons why Apple and Google haven't adopted it for mobile apps?
Android already has an incredible platform running on the JVM with years of work to optimize and create dev-friendly APIs. You could build a compiler that compiles Go running on the JVM and use Android APIs if you really hate Java.
A lot of GUI apps now use Electron, which is easy for web frontend devs to pick up and run. Plus you can use web frameworks like React, etc to run them. The major deficit here is that it uses a ton of memory for nothing, but hopefully frameworks like Flutter will come in and take their place.
Google and Apple haven't adopted it as they were already developing languages/platforms targeting GUI development (Dart/Flutter and Swift respectively). Also Go is a young language targeting a different niche so there was nothing pushing it this way.
I don’t think any of them - maybe Swift - are terribly young at this point.
I also think it’s not quite right to call Swift object-oriented, at least not any more so than Go.
Compare SwiftUI’s way of writing a static UI view to Goey’s: https://www.objc.io/blog/2019/11/05/static-types-in-swiftui/
The two layouts are very similar. I’m a Professional Go Programmer, but I find the Swift example (and similar Flutter examples) much more suited to describing interfaces.
The approach is a hybrid. The declarative approach with reconcilation (tree diffing) comes from React. The automatic layout with constraints does come from Flutter.
I personally like that kind of syntax for UI development.
https://groovy-lang.org/swing.html
Really, most of the stuff people think it is new in Flutter, it really isn't.
Is it just by accident?
Golang projects like to have a play on words with “go” or just prefixed like “go-commander”. Such as Hugo static site generator, the mascot gopher, Gorilla web toolkit...
Anyway still fyne looks like another good option