"Hands-On GUI Application Development in Go: Build responsive, cross-platform, graphical applications with the Go programming language"
https://www.amazon.de/-/en/Andrew-Williams-ebook/dp/B07GYLYS...
The "old" frameworks such as the GTK bindings are either unmaintaned or not complete or both. The new frameworks like Gio and Fyne are promising but not there yet. Maybe in 1-2 years if they are being worked on consistently.
I really wish to do my upcoming project natively in Go (also Rust would be fine) but I don't see how.
Regarding web technology as desktop solution: all of those solutions including Go are just a mess IMO. They force go into the stack even when it doesn't make sense. Write the frontend in Go, compile it to WASM, wrap it in some browser.. it's just more complexity for no real gain.
There are some promising ideas, such as webview and wails but again not production-ready.
My conclusion: if you are willing to use web technologies, just use electron at the moment.
With Go the only "possible" way is to write a server and open a tab in your browser. But if people would accept this as desktop solution is another question.
In last years a lot projects have appeared, which were trying to compete in GUI toolkit market share. All of them had its scope limited, however they brought quite fresh look on declarative programming interface [0][1], superb 2D rendering pipeline [2][3], ease of embedding [4] and adaption to low-power devices [5] but none of them is "complete".
Personally, I am amazed of the implementation of rxi/lite [6], which is just an app (C with Lua) based on SDL2 library. It uses 2x less RAM than sublime on 1GB file, has lower latency, covers clipboard, keyboard, mouse, drag and drop, some context menus but does it feel native? No. Among many issues, it is easy to report an error with screen-reading software but it is quite common problem in all aforementioned.
Perhaps in future, something like LSP specification will see a daylight, which in outcome will helps us to provide universal, modular, limited to certain scope libraries that can be easily plugged in case of need. Maybe then we will came closer to "native" GUIs. In my experience, there are numerous developers who were trying hard to deliver "complete" GUI toolkit but have failed.
[0]: https://github.com/cycfi/elements
[1]: https://flutter.dev/
[2]: https://github.com/linebender/druid
[3]: https://github.com/servo/pathfinder
[4]: https://github.com/ocornut/imgui
rxi/lite have tens of functions in C to provide operation of file-system, implement fuzzy-finder or simple rendering calls for rectangles. Rest of code is written in Lua that shares a lot of signature-compatible functions with Sublime Text API. There is only Lua, STB (stb_truetype) and SDL2. Also compilation script is basic shell script [0].
It is also worth noting there is interesting contribution to provide sub-pixel rendering [1] (now, a fork [2]) which includes usage of libagg [3].
[0]: https://github.com/rxi/lite/blob/master/build.sh
[1]: https://github.com/rxi/lite/issues/145#issuecomment-64155409...
So we have QT and GTK ...
gotk3 is maintained and most of the widgets are in place (technically it's not "complete", sure, but still).
My biggest gripe with it is that the whole documentation is just absolutely useless string of "this function is a wrapper for this function in C" over and over again instead of it being, well, the documentation for the function that is being wrapped.
But good to know. And yes I forgot to mention the documentation.. you are absolutely right.. so far I have had that experience with all things GTK.
That split model isn't limited to browser tabs. You can write a nice GUI (native, or tooling of your choice) that communicates with your go back-end via API bindings.
This model is well proven (dockerd/docker cli; various crypto wallets and their front-end UIs, etc), though attention needs to be given to security concerns. Running a local service means malicious software that knows about the service could access it without the user's knowledge if you're not careful, exposing private or sensitive data that the service has access to.
Can you clarify these security concerns? If the server is only listening on localhost I don't see a difference to "the classic desktop application". If the malicious software has access to your system the data is always endangered right? Or were you talking about services that are exposed to the outside?
That's what I meant as well. You have a go daemon/service running that does the heavy lifting; and your front end (whatever it may be) knows how to talk to it. The UI elements remain separated from the work of the daemon.
The browser-based/localhost approach works well for this too, but you can also take the same approach for rich/native client apps without having to make the daemon platform-specific.
> If the malicious software has access to your system the data is always endangered right?
This is what I was referring to - nothing new, but IMO worth mentioning in the context of setting up a new service to run on someone's system.
So now your app is either GPL or you fork something like 5 grands ...
Think Visual Basic but cross-platform, with a much better language and component architecture.
You can develop non-trivial apps in hours rather than days.
The IDE is here: www.lazarus-ide.org
Why Lazarus?
* Has a proper Rapid Application Development (RAD) IDE with visual layout, event handlers, component tool bars etc and also built in documentation
* Extremely fast to develop on: The IDE starts in a couple of seconds. Compilation to native binaries in seconds.
* Cross Platform - Windows, Linux, Mac OS and perhaps even Android
* Binaries are really fast
* Excellent set of visual components
* Excellent set of database components including grids, CRUD toolbars etc
* You can write your own components very easily.
* Very small executable
* Most Delphi documentation is directly usable
* Many existing products use Lazarus https://wiki.freepascal.org/Projects_using_Lazarus
* Demos and projects here: https://www.getlazarus.org/
I've actually done this, it works well, and the Lazarus GUI libraries manage to get a natural look and feel on all platforms.
Are you the person who wrote this? if so would like to contribute in some way.
I tried it a few years ago and ran away for this exact reason : I have VB PTSD from some complex Excel apps that I inherited at work ;)
But yeah if I was objective I could see a lot of value in Lazarus.
What the parent suggested was not using QT and not paying the company that makes it, but that its price makes it unusable for their purposes.
(Now, that might have been based on a misunderstanding of the licensing involved, but ignoring that, the point still stands. If one had to pay $5000 for a GUI library, and one didn't have $5000, then one could look elsewhere...).
$5000 is not the price for small developers by the way.
It is licensed under the LGPL though (however much its current owners may want to change this, they can't because of the KDE Free Qt agreement), which means you don't have to pay. All you have to do is dynamically link to the library instead of statically linking.
The major contributors for Qt have always been the same regardless of the legal name of Qt owner.
It is quite easy decision process, don't want to pay for Qt's development, use LGPL and GPL variants earn as much money as one is willing to give upstream.
Decide to go commercial, then pay accordingly upstream.
> Decide to go commercial, then pay accordingly upstream.
Hmm. The commercial license actually prohibits starting development under one of the open source licenses then switching to commercial. If you start under an open source license, you'll need to abide by the LGPL if you decide to go closed source (and of course what you've already released remains open source).
https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn...
Note that does not necessarily require “your code” to be/come open source.
Wasn't there talks about ending the lgpl version ? I thought I read somewhere that KDE devs were quite worried.
As far as I can tell from that the LGPLv3 seems to be required under the current terms of the agreement.