5 ms·

Didn't read the book but I had a looong look at all kinds of "native" Go Gui toolkits and have to say there is none ready for professional / commercial cross-pl

Didn't read the book but I had a looong look at all kinds of "native" Go Gui toolkits and have to say there is none ready for professional / commercial cross-platform GUI applications. 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.

graynk 6y ago
> The "old" frameworks such as the GTK bindings are either unmaintaned or not complete or both 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.
- fileeditview 6y ago
  Interesting.. I would have sworn that I just visited the gotk3 Github page and the project was archived.. very strange. 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.
pqb 6y ago
Indeed, however I think we might replace Go with any programming language and your comment will still make sense. Currently, web-browsers are the best have-it-all platforms, and outside web-technologies there isn't many good alternatives. We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK). 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 https://github.com/cycfi/elements [1]: https://flutter.dev/ https://flutter.dev/ [2]: https://github.com/linebender/druid https://github.com/linebender/druid [3]: https://github.com/servo/pathfinder https://github.com/servo/pathfinder [4]: https://github.com/ocornut/imgui https://github.com/ocornut/imgui [5]: https://github.com/Immediate-Mode-UI/Nuklear https://github.com/Immediate-Mode-UI/Nuklear [6]: https://github.com/rxi/lite https://github.com/rxi/lite
- fileeditview 6y ago
  Funny how i have visited almost all of your links before. Do I understand it correctly that rxi/lite is just using plain SDL2 underneath to render the UI, do input processing, windowing,..? They must have had a lot of work implementing all of that. I always wondered why there are no well known ui frameworks on top of SDL.
  - pqb 6y ago
    Yes, that's right. To be honest, I spent some time already to inspect and analyze its code, because I found it as a nice example to learn Rust by rewriting this project. 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 https://github.com/rxi/lite/blob/master/build.sh [1]: https://github.com/rxi/lite/issues/145#issuecomment-641554095 https://github.com/rxi/lite/issues/145#issuecomment-64155409... [2]: https://github.com/franko/lite-xl https://github.com/franko/lite-xl [3]: http://antigrain.com/ http://antigrain.com/
- jhoechtl 6y ago
  > We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK). So we have QT and GTK ...
_wldu 6y ago
GTK3 and Go work pretty well. Nice article about it here with example code: https://sudonull.com/post/12576-GUI-on-Golang-GTK-3 https://sudonull.com/post/12576-GUI-on-Golang-GTK-3
GrinningFool 6y ago
> With Go the only "possible" way is to write a server and open a tab in your browser. 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.
- fileeditview 6y ago
  I agree that can be a viable solution. Mainly if the backend is also used without GUI. However what I meant is that the Go part of the application will be only the server part. 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?
  - GrinningFool 6y ago
    > However what I meant is that the Go part of the application will be only the server part. 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.

graynk 6y ago

> The "old" frameworks such as the GTK bindings are either unmaintaned or not complete or both 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.

fileeditview 6y ago
Interesting.. I would have sworn that I just visited the gotk3 Github page and the project was archived.. very strange. 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.

pqb 6y ago

Indeed, however I think we might replace Go with any programming language and your comment will still make sense. Currently, web-browsers are the best have-it-all platforms, and outside web-technologies there isn't many good alternatives. We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK). 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 https://github.com/cycfi/elements [1]: https://flutter.dev/ https://flutter.dev/ [2]: https://github.com/linebender/druid https://github.com/linebender/druid [3]: https://github.com/servo/pathfinder https://github.com/servo/pathfinder [4]: https://github.com/ocornut/imgui https://github.com/ocornut/imgui [5]: https://github.com/Immediate-Mode-UI/Nuklear https://github.com/Immediate-Mode-UI/Nuklear [6]: https://github.com/rxi/lite https://github.com/rxi/lite

fileeditview 6y ago
Funny how i have visited almost all of your links before. Do I understand it correctly that rxi/lite is just using plain SDL2 underneath to render the UI, do input processing, windowing,..? They must have had a lot of work implementing all of that. I always wondered why there are no well known ui frameworks on top of SDL.
- pqb 6y ago
  Yes, that's right. To be honest, I spent some time already to inspect and analyze its code, because I found it as a nice example to learn Rust by rewriting this project. 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 https://github.com/rxi/lite/blob/master/build.sh [1]: https://github.com/rxi/lite/issues/145#issuecomment-641554095 https://github.com/rxi/lite/issues/145#issuecomment-64155409... [2]: https://github.com/franko/lite-xl https://github.com/franko/lite-xl [3]: http://antigrain.com/ http://antigrain.com/
jhoechtl 6y ago
> We landed in 2020 and we don't have any complete, native-like, cross-platform GUI toolkit (if we skip Qt and GTK). So we have QT and GTK ...

_wldu 6y ago

GTK3 and Go work pretty well. Nice article about it here with example code: https://sudonull.com/post/12576-GUI-on-Golang-GTK-3 https://sudonull.com/post/12576-GUI-on-Golang-GTK-3

GrinningFool 6y ago

> With Go the only "possible" way is to write a server and open a tab in your browser. 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.

fileeditview 6y ago
I agree that can be a viable solution. Mainly if the backend is also used without GUI. However what I meant is that the Go part of the application will be only the server part. 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?
- GrinningFool 6y ago
  > However what I meant is that the Go part of the application will be only the server part. 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.