Tutorial on building a desktop app with Go and Goey(bitbucket.org)
bitbucket.org
Tutorial on building a desktop app with Go and Goey
https://bitbucket.org/rj/goey/wiki/Tutorial-Hello
25 comments
> The lack of full macOS support on Goey and the decision to target GNUStep instead of Mac Cocoa proper is... interesting.
complain to Apple which makes it illegal to have access to the Cocoa API if you don't own a Mac
complain to Apple which makes it illegal to have access to the Cocoa API if you don't own a Mac
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.
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.
> 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
That's true. For iOS too. Sorry.
That's true. For iOS too. Sorry.
>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
... 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
>The lack of full macOS support on Goey and the decision to target GNUStep instead of Mac Cocoa proper is... interesting.
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.
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.
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].
[0]: https://gioui.org/
[1]: https://www.youtube.com/watch?v=PxnL3-Sex3o
[2]: https://git.wow.st/gmp/passgo
[0]: https://gioui.org/
[1]: https://www.youtube.com/watch?v=PxnL3-Sex3o
[2]: https://git.wow.st/gmp/passgo
I don't write in Go but from what I read the language isn't oriented towards GUI app development.
Can anyone explain why this is the case? Are there any obvious reasons why Apple and Google haven't adopted it for mobile apps?
Can anyone explain why this is the case? Are there any obvious reasons why Apple and Google haven't adopted it for mobile apps?
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.
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.
Go is ten years old - older than Swift, as old as Dart.
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.
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.
> 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.
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.
GUI Toolkits often benefit from “looser” type requirements than Go provides.
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.
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.
Do you know if Fyne can completely bundle the binary for cross platform? That’s super useful.
Are we talking static compilation or assets? I don’t believe they’re fully static as they link out to OpenGL but I am not an expert.
For assets, I use go-bindata to embed them into my binary, personally.
https://github.com/go-bindata/go-bindata
For assets, I use go-bindata to embed them into my binary, personally.
https://github.com/go-bindata/go-bindata
AFAIR the name of the project sounds like "non-Jew" in Hebrew and Yiddish, in derogatory connotation.
Is it just by accident?
Is it just by accident?
I reckon it’s a phonetic play on “GUI”?
Yeah.
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...
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...
Is it just me or the syntax here resembles that of Flutter's Dart
And Flutter's Dart resembles Groovy's SwingBuilder:
https://groovy-lang.org/swing.html
Really, most of the stuff people think it is new in Flutter, it really isn't.
https://groovy-lang.org/swing.html
Really, most of the stuff people think it is new in Flutter, it really isn't.
The syntax is definitely Go :)
The approach is a hybrid. The declarative approach with reconcilation (tree diffing) comes from React. The automatic layout with constraints does come from Flutter.
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 understand it's Go. Just never thought that Go can also be written that way.
I personally like that kind of syntax for UI development.
I personally like that kind of syntax for UI development.
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.
Anyway still fyne looks like another good option
Anyway still fyne looks like another good option
[deleted]
I’ll probably stick with Fyne for the time being. It’s fine.