Gio: Portable, Immediate Mode GUI in Go(git.sr.ht)
git.sr.ht
Gio: Portable, Immediate Mode GUI in Go
https://git.sr.ht/~eliasnaur/gio
77 comments
For Flutter desktop support consider https://github.com/go-flutter-desktop/go-flutter : imho it works better than the official Google lib actually to compile Flutter desktop guis
Looks fantastic, thanks!
Basically this is the UI FX used to build https://scatter.im
Best way to view a preview of it: https://youtu.be/9D6eWP4peYM?t=113
Best way to view a preview of it: https://youtu.be/9D6eWP4peYM?t=113
Is it just me or do are there a lot of developers who don't believe in the saying "One picture is worth a 1000 words"? Is it a Linux thing, something peculiar to developers in the Github era?
If you go to a forum such a the Lazarus forums, any announced projects show pics on the forum itself, or on the websites linked.
It makes me long for the bad old day so of windows when showing pics of your project was all the rage and still is.
This is not just in relation to Gio, but I see so many GUI projects on Github with nary a picture in sight.
Do their developers want those intrigued to go to the effort of setting up a development environment (if that succeeds) only to find that the project is half-baked mush of an apple pie?
If you go to a forum such a the Lazarus forums, any announced projects show pics on the forum itself, or on the websites linked.
It makes me long for the bad old day so of windows when showing pics of your project was all the rage and still is.
This is not just in relation to Gio, but I see so many GUI projects on Github with nary a picture in sight.
Do their developers want those intrigued to go to the effort of setting up a development environment (if that succeeds) only to find that the project is half-baked mush of an apple pie?
On Ubuntu 19.04 I get the error message "wayland: wl_display_connect failed". Can’t run the hello program to see something.
First time I hear about immediate mode GUI. Here's a previous HN coversartion about it: https://news.ycombinator.com/item?id=19744513
Off topic but...
In the web world we have benchmarks for UI libraries. Is there anything similar for the native world?
I remember a couple of years ago there was the bunny mark benchmark for 2d game engines (OpenFL, Flash, Pixi, etc).
In the web world we have benchmarks for UI libraries. Is there anything similar for the native world?
I remember a couple of years ago there was the bunny mark benchmark for 2d game engines (OpenFL, Flash, Pixi, etc).
Vector shapes and text can go a long way but what about rendering images, video, or even SVG for icons and such?
I wanted to try this out right away, but stumbled over the fact that I don't know how to use "go get" with Sourcehut, or even if it's supported. Of course it's probably easy to find out, but a "getting started" section wouldn't hurt. The "installation" page only describes the installation of the dependencies...
go get has nothing to do with github. Why wouldn't it work? Just use it the usual way. The readme directs you to a hello world program:
https://git.sr.ht/~eliasnaur/gio/tree/master/example/hello/h...
https://git.sr.ht/~eliasnaur/gio/tree/master/example/hello/h...
Ok, after I noticed that the URL of the git repo is at the top of the page (somehow I managed to overlook it), I tried "go get git.sr.ht/~eliasnaur/gio", only to find out that wasn't correct, because the project uses a "vanity URL", so apparently I have to use "go get gioui.org/gio" or something like that. My point was that even if it's pretty straightforward for a reasonably experienced Go developer, it doesn't hurt to mention it...
It appears to support Windows, MacOS, Linux, IOS, and Android. See also this youtube video from GopherCon 2019 on this ui library:
https://www.youtube.com/watch?v=9D6eWP4peYM&t=636s
https://www.youtube.com/watch?v=9D6eWP4peYM&t=636s
Love the idea not a fan of the tough to google name. I had issues googling for it a couple of times to show people Gio.
How about "Gio golang UI library"?
What exactly is hard about that (or several similar variations) -- which give me a first page full of relevant results?
Does the term have to be "Gio" or bust?
What exactly is hard about that (or several similar variations) -- which give me a first page full of relevant results?
Does the term have to be "Gio" or bust?
Should I really be forced to memorize word soup to find what I am looking for though? Thats just absurd to me.
To me it is more absurd that you act as if it is impossible to search for what you are looking for using more than one word.
You aren't supposed to memorize a word soup. You are supposed to search for what you are looking for based on some hints you may remember - e.g. gio gui library for golang. Even duckduckgo which isn't always the best when it comes to searching vague stuff gives gio as the third result (google shows the gio repository as the first result).
You aren't supposed to memorize a word soup. You are supposed to search for what you are looking for based on some hints you may remember - e.g. gio gui library for golang. Even duckduckgo which isn't always the best when it comes to searching vague stuff gives gio as the third result (google shows the gio repository as the first result).
I probably typed into Google several things, and I'm not sure if the filter bubble Google has around me was screwing it up, or not getting the right word soup. Sometimes it shows up, other times it does not. Maybe Gio is finally getting enough attention.
Do you really need to memorize it?
You should absolutely be able to derive additional search terms from first principles, assuming you know that Gio is a golang library for GUI...
If you don't know what it is, then why would you be searching for it in the first place?
If anything, you have it backwards: it is the Gio name itself (or whatever more unique you suggest) that you'd need to absolutely memorize.
Additional terms ("golang", "GUI", "library", and several others one could use) come naturally from knowing what Gio is, no memorization required.
You should absolutely be able to derive additional search terms from first principles, assuming you know that Gio is a golang library for GUI...
If you don't know what it is, then why would you be searching for it in the first place?
If anything, you have it backwards: it is the Gio name itself (or whatever more unique you suggest) that you'd need to absolutely memorize.
Additional terms ("golang", "GUI", "library", and several others one could use) come naturally from knowing what Gio is, no memorization required.
Same as Go where you search for "golang". I get good results using "gioui".
No screenshots for a GUI library?
Watch his Gophercon talks, around minutes 4-7 show what it’s capable of. Screenshots simply show native interfaces, so it isn’t some kind of skin that’s readily apparent from screenshots. The more interesting action happens in the code and his philosophy towards multi-platform UI.
That's a lazy excuse, sorry :) The talk is not even linked in the readme.
Display me what this awesome philosophy is capable of. I understand that this is somebody's side project, but come on, grab my attention, since we have a sea of GUI libraries out there. He must have built something amazing in it, just throw it there. It took me quite a while to find the slide deck link in the readme and I only kept looking because I couldn't believe that I can't see this thing in action.
Display me what this awesome philosophy is capable of. I understand that this is somebody's side project, but come on, grab my attention, since we have a sea of GUI libraries out there. He must have built something amazing in it, just throw it there. It took me quite a while to find the slide deck link in the readme and I only kept looking because I couldn't believe that I can't see this thing in action.
As far as I know, the "native interface" in Windows is not immediate-mode. Also Linux barely has one, so that's very confusing too. How does that work out?
I too feel the project page really could use a couple of screenshots, since when talking about visual things, pictures do help.
Update: I watched the video, it looks really nice and smooth but seems to be the basic framework on which you can build a user interface, not an actual user interface. For instance he shows off basic drawing, and support for dynamic layout of user interface elements, but no ready-made widgets. Maybe I'm still not getting the full picture.
I too feel the project page really could use a couple of screenshots, since when talking about visual things, pictures do help.
Update: I watched the video, it looks really nice and smooth but seems to be the basic framework on which you can build a user interface, not an actual user interface. For instance he shows off basic drawing, and support for dynamic layout of user interface elements, but no ready-made widgets. Maybe I'm still not getting the full picture.
> Screenshots simply show native interfaces
Yeah, but accompanied by code snippets they would make a lot of sense on a GUI library's landing page. Not to advertise the look of the widgets, but to advertise the ease or flexibility of the library.
Yeah, but accompanied by code snippets they would make a lot of sense on a GUI library's landing page. Not to advertise the look of the widgets, but to advertise the ease or flexibility of the library.
especially since it supports WebAssembly as a backend, it would be nice to get a online demo page.
No x11 support?
It IS being worked on but in the meantime, gio apps can be run on X using https://github.com/Hjdskes/cage (a very simple wayland compositor)
I've poked around some of the gioui windowing code. It should be pretty easy to add an X11 backend if you're up for the task.
Yeah, that makes it a no-starter for me.
This looks really interesting to me but I'm a bit lost on how exactly it'd work in practise. Are there anymore docs somewhere?
His GopherCon talks are pretty gentle tutorials. In practice, looks like your program becomes responsible for quite a bit of scaffolding that UI coders take for granted these days, in exchange for multi-platform write-once. Kind of reminds me of GUI programming back in the 80’s, where your program is responsible for managing every state refresh and screen update. It’s efficient, but I’ve seen larger teams without sufficient discipline have a challenge coping with this style. For a lot of useful problem domains however, it’s really tough to beat its time to market and efficiency. Lots of startups would probably love this.
At this point electron will beat something like this on a time to market front. I suspect this framework would work better for people who want to do real-time drawing but stick with go and not setup a bunch of OpenGL boilerplate.
Thanks for the detailed response, I'm going to take a look into the videos.
A GUI library with no screenshots, no widget gallery, and no (easily found) reference?
"Hosting Gio on Sourcehut is an experiment just as Gio itself is."
Yeah, nice experiment. Now maybe try GitHub?
"Hosting Gio on Sourcehut is an experiment just as Gio itself is."
Yeah, nice experiment. Now maybe try GitHub?
Why further strenghten Microsoft's monopoly on developers? With several great alternatives available today, I say steer clear and as far away from Github as possible.
99% of Go projects, and Go itself, use GitHub, so I don't see how you'd "steer clear and away" when to use Gio you'd need to be using Go anyway...
Nor is this thing used here a "great alternative".
Nor is this thing used here a "great alternative".
The Go tooling works fine with repositories hosted elsewhere. It’s a minor inconvenience for contributors, potentially.
The same can be said about Go
This M$ = bad trope is really tired and outdated and not representative of its value to devs.
By all means encourage different hosting platforms, but maybe in a tone more relevent to the current decade.
By all means encourage different hosting platforms, but maybe in a tone more relevent to the current decade.
No. After the decades of sustained bad behavior, they do not get a pass so easily. Not for several more decades at least.
Also, please quit it with the $ instead of S trope, it's really immature.
Also, please quit it with the $ instead of S trope, it's really immature.
So don't use the tone.
It's really not.
Rude. What's you beef with Sourcehut? "Other projects use Github" will not be accepted as an answer.
That it's between GNU project webpages and Sourceforge circa 2002?
>"Other projects use Github" will not be accepted as an answer
Well, not that I care whether it would or would not be accepted, but It would still be a valid answer: using common services others use, makes for less friction:
1) immediate familiarity for most (not having to learn yet another thing)
2) common tooling with what other projects you use, use,
3) more available tooling -thanks to popularity-
4) more dependable to be around,
5) easier to engage with others since they more likely already use it -network effects-,
and so on...
>"Other projects use Github" will not be accepted as an answer
Well, not that I care whether it would or would not be accepted, but It would still be a valid answer: using common services others use, makes for less friction:
1) immediate familiarity for most (not having to learn yet another thing)
2) common tooling with what other projects you use, use,
3) more available tooling -thanks to popularity-
4) more dependable to be around,
5) easier to engage with others since they more likely already use it -network effects-,
and so on...
> Sourceforge circa 2002?
Sourceforge has one thing that other services do not seem to have: it is user centric instead of developer centric. With that i mean that for any project you get information that would be interesting to the (potential) users of that project, such as up front information about what the project is all about, collection of screenshots (where that applies), a big fat button to download the latest release (instead of a repository snapshot - note that a release can be different from a repo snapshot, e.g. it can contain pregenerated configure and/or makefiles and documentation whereas a repo snapshot may only contain the "source" for those - and of course a release may also be in binary form), comments and reviews from other users, discussion mailing lists/forums, information about the project's category/tags and similar projects, etc.
FWIW of all the above, the only thing that sourcehut does is having an optional "what is this all about" page (article). Though even that still puts it above the likes of GitHub (that front load each project's page with the file tree of its source code) - again from a users' perspective. Though even a self-contained Fossil repository is still better than that (but you still need to do customizations to make it more user oriented).
Of course that might be just a sign that (considering the popularity of GitHub) the majority of developers do not care about users :-P
Sourceforge has one thing that other services do not seem to have: it is user centric instead of developer centric. With that i mean that for any project you get information that would be interesting to the (potential) users of that project, such as up front information about what the project is all about, collection of screenshots (where that applies), a big fat button to download the latest release (instead of a repository snapshot - note that a release can be different from a repo snapshot, e.g. it can contain pregenerated configure and/or makefiles and documentation whereas a repo snapshot may only contain the "source" for those - and of course a release may also be in binary form), comments and reviews from other users, discussion mailing lists/forums, information about the project's category/tags and similar projects, etc.
FWIW of all the above, the only thing that sourcehut does is having an optional "what is this all about" page (article). Though even that still puts it above the likes of GitHub (that front load each project's page with the file tree of its source code) - again from a users' perspective. Though even a self-contained Fossil repository is still better than that (but you still need to do customizations to make it more user oriented).
Of course that might be just a sign that (considering the popularity of GitHub) the majority of developers do not care about users :-P
Gioui is a library for developers, though. End-users don't end up here.
Note that i'm comparing the overall UI/UX of these services not just for this specific project.
However libraries also have end users - the developers who are going to use the library (vs the developers who will work on the library). A library can have a release version (with e.g. pregenerated documentation, configure, make or whatever) which is different from a repo snapshot similar to how an application can have a release version.
However libraries also have end users - the developers who are going to use the library (vs the developers who will work on the library). A library can have a release version (with e.g. pregenerated documentation, configure, make or whatever) which is different from a repo snapshot similar to how an application can have a release version.
Aye. However, git.sr.ht doesn't aim to be your project's home page, but rather its git repo. Its design is optimized for its usage as such.
In the future, Sourcehut will have a project hub which is more suited to being the public face of your project, and will have static site hosting for your project website.
In the future, Sourcehut will have a project hub which is more suited to being the public face of your project, and will have static site hosting for your project website.
Yes, note that i'm explicitly saying "from the user's perspective" here. Of course i'm not expecting sourcehut (or github or anything) to do something they do not even meant to do. Even projects in Sourceforge often have their code repository in other places.
-1) promotes ecosystem monoculture
-2) centralizes point of systemic failure
-3) a downside to the "network effects" benefit is that it is becoming a "social coding" platform, with all the toxic effects and perverse incentives endemic to social media
-4) Owned and controlled by a company which, while acting better in recent years (and I do believe the people involved are sincere!), still has not even apologized for their truly vicious attacks on free/libre and open source software in years past, and no indication that they've atoned for embrace-extend-extinguish.
-2) centralizes point of systemic failure
-3) a downside to the "network effects" benefit is that it is becoming a "social coding" platform, with all the toxic effects and perverse incentives endemic to social media
-4) Owned and controlled by a company which, while acting better in recent years (and I do believe the people involved are sincere!), still has not even apologized for their truly vicious attacks on free/libre and open source software in years past, and no indication that they've atoned for embrace-extend-extinguish.
>That it's between GNU project webpages and Sourceforge circa 2002?
Even more rude. This looks nothing like either. GNU Savannah has a garish color scheme and completely unplanned UI. Sourceforge is overplanned and looks like a mid-2000's ad-ridden malware distribution site.
>Well, not that I care whether it would or would not be accepted, but It would still be a valid answer: using common services other's use, make for less friction
Then you'll never get new services. You'll bow to your Microsoft overlords and take what Github gives you, and be thankful for it. Github is proprietary and profit driven. It's going to do what's best for it, not what's best for you. This is a pretty naive and immature line of reasoning.
Even more rude. This looks nothing like either. GNU Savannah has a garish color scheme and completely unplanned UI. Sourceforge is overplanned and looks like a mid-2000's ad-ridden malware distribution site.
>Well, not that I care whether it would or would not be accepted, but It would still be a valid answer: using common services other's use, make for less friction
Then you'll never get new services. You'll bow to your Microsoft overlords and take what Github gives you, and be thankful for it. Github is proprietary and profit driven. It's going to do what's best for it, not what's best for you. This is a pretty naive and immature line of reasoning.
>Even more rude.
Rude to whom? Styles? UX? I'm pretty sure even the graphic/UX designers involved (if any) would agree.
Rude to whom? Styles? UX? I'm pretty sure even the graphic/UX designers involved (if any) would agree.
That's the founder and lead dev of sourcehut you're talking to. I'm pretty sure he wouldn't object if he agreed.
Well, that's a blunder for sure!
Didn't know it, thought I was talking to just some FOSS proponent, so sorry.
But even so, we can surely agree that the design is basic compared to GitHub no?
Didn't know it, thought I was talking to just some FOSS proponent, so sorry.
But even so, we can surely agree that the design is basic compared to GitHub no?
The design is different, but I wouldn't say it's worse than github. I actually prefer sourcehut's design to github's. If nothing else, there are some undeniable benefits to sourcehut's style, such as faster page loading time and less memory usage.
How would your criticism change if you knew who you were talking to? Why not just always assume the developer of anything will be reading HN comments that mention their thing, and form your comments as such? Developers are human, after all.
How would your criticism change if you knew who you were talking to? Why not just always assume the developer of anything will be reading HN comments that mention their thing, and form your comments as such? Developers are human, after all.
>Then you'll never get new services. You'll bow to your Microsoft overlords and take what Github gives you, and be thankful for it.
Well, that escalated quickly.
Or, you know, we'll leverage the commonality as long as it suits us, and jump ship when it doesn't. Like we did with Sourceforge itself, and like people did with common once dominant and good to use because of network effects projects...
How about that? As if we have agency, and are not just mindless automata, that just because we chose an option are forced to live with it forever...
>Github is proprietary and profit driven.
Both are acceptable, even in polite society...
Well, that escalated quickly.
Or, you know, we'll leverage the commonality as long as it suits us, and jump ship when it doesn't. Like we did with Sourceforge itself, and like people did with common once dominant and good to use because of network effects projects...
How about that? As if we have agency, and are not just mindless automata, that just because we chose an option are forced to live with it forever...
>Github is proprietary and profit driven.
Both are acceptable, even in polite society...
>Both are acceptable, even in polite society...
Proprietary is not acceptable.
Profit-driven can be acceptable, but time and again we've seen that companies driven by profits don't make decisions in the best interests of their users, i.e. you.
Proprietary is not acceptable.
Profit-driven can be acceptable, but time and again we've seen that companies driven by profits don't make decisions in the best interests of their users, i.e. you.
>Proprietary is not acceptable.
Do you speak for everybody?
Because you can pry Sublime Text, Final Cut Pro X or Cubase from my dead hands, and all those are proprietary...
>Profit-driven can be acceptable, but time and again we've seen that companies driven by profits don't make decisions in the best interests of their users, i.e. you.
We've seen time and again than FOSS project leaders also don't make decisions in the best interests of their users.
And we've also seen that just their being open source just raises the chances of somebody having the will/resources/knowledge/time to fork them and do them right from 0% (for proprietary) to near 0 (for FOSS). As for me, one of said users, doing it, it's 0% in both cases.
Do you speak for everybody?
Because you can pry Sublime Text, Final Cut Pro X or Cubase from my dead hands, and all those are proprietary...
>Profit-driven can be acceptable, but time and again we've seen that companies driven by profits don't make decisions in the best interests of their users, i.e. you.
We've seen time and again than FOSS project leaders also don't make decisions in the best interests of their users.
And we've also seen that just their being open source just raises the chances of somebody having the will/resources/knowledge/time to fork them and do them right from 0% (for proprietary) to near 0 (for FOSS). As for me, one of said users, doing it, it's 0% in both cases.
> "Other projects use Github" will not be accepted as an answer.
It's not just because "other projects use GitHub", but it's that because "other projects use GitHub", discoverability of projects that are hosted in GitHub tends to be higher than ones that do not.
Also the workflow is vastly different (AFAIK Sourcehut doesn't have web-based bug report/PR, I think you mentioned it being developed... looking forward for it) from most OSS contributors/users, and forcing a different workflow will turn them away.
I think hosting the primary repo on sr.ht with a mirror on GitHub, and getting bug reports/PRs with both services might be a better solution IMHO.
It's not just because "other projects use GitHub", but it's that because "other projects use GitHub", discoverability of projects that are hosted in GitHub tends to be higher than ones that do not.
Also the workflow is vastly different (AFAIK Sourcehut doesn't have web-based bug report/PR, I think you mentioned it being developed... looking forward for it) from most OSS contributors/users, and forcing a different workflow will turn them away.
I think hosting the primary repo on sr.ht with a mirror on GitHub, and getting bug reports/PRs with both services might be a better solution IMHO.
I really hate this argument because it's an insurmountable problem for new platforms. It's really not reasonable to expect that of any platform. The project isn't on Github, but you seem to have discovered it just fine. Give it a chance.
Also, Sourcehut does have web-based bug submissions, and a nice tutorial for setting up terminal-based PR submissions.
Also, Sourcehut does have web-based bug submissions, and a nice tutorial for setting up terminal-based PR submissions.
>it's an insurmountable problem for new platforms.
It's not. The solution is to use design language that people are familiar with. Nobody wants to feel stupid when they use a product. So instead make them feel smart by creating a UI that is already familiar to them.
For example, why can't I find the issues/todos from the main repository page? For some reason, there's no button to get to here (https://todo.sr.ht/~eliasnaur/gio) from here (https://git.sr.ht/~eliasnaur/gio).
It's not. The solution is to use design language that people are familiar with. Nobody wants to feel stupid when they use a product. So instead make them feel smart by creating a UI that is already familiar to them.
For example, why can't I find the issues/todos from the main repository page? For some reason, there's no button to get to here (https://todo.sr.ht/~eliasnaur/gio) from here (https://git.sr.ht/~eliasnaur/gio).
>The solution is to use design language that people are familiar with.
Then all you end up with are clones of the same platform. Not much better imo.
>For example, why can't I find the issues/todos from the main repository page?
Because unlike Github, the repository is not the main home of the project. This is true even of many projects hosted on Github. The git repo is often one of many, or the wrong place to file issues, or isn't where the docs live. A centralized idea of a "project" with links backwards and forwards is a blocking planned feature of the Sourcehut beta. But if you're comfortable using a beta-quality UI library then you can live with using a beta-quality project host.
Then all you end up with are clones of the same platform. Not much better imo.
>For example, why can't I find the issues/todos from the main repository page?
Because unlike Github, the repository is not the main home of the project. This is true even of many projects hosted on Github. The git repo is often one of many, or the wrong place to file issues, or isn't where the docs live. A centralized idea of a "project" with links backwards and forwards is a blocking planned feature of the Sourcehut beta. But if you're comfortable using a beta-quality UI library then you can live with using a beta-quality project host.
Thanks for the reply!
>Then all you end up with are clones of the same platform.
There are ways to use familiar design language while at the same time innovating. Like I said before, I just don't want to feel stupid.
>Because unlike Github, the repository is not the main home of the project.
I don't think your UI is terrible btw. I think I'm just primarily confused about this point.
>A centralized idea of a "project" with links backwards and forwards is a blocking planned feature of the Sourcehut beta.
I think this would be so helpful. If I can't see a link to Todos.sr.ht from Git.sr.ht, then how would I know that I have to change the subdomain in order to get there?
For what it's worth, Gitlab is a UI nightmare compared to Sourcehut. So I very much value your emphasis on the clean and simple.
>Then all you end up with are clones of the same platform.
There are ways to use familiar design language while at the same time innovating. Like I said before, I just don't want to feel stupid.
>Because unlike Github, the repository is not the main home of the project.
I don't think your UI is terrible btw. I think I'm just primarily confused about this point.
>A centralized idea of a "project" with links backwards and forwards is a blocking planned feature of the Sourcehut beta.
I think this would be so helpful. If I can't see a link to Todos.sr.ht from Git.sr.ht, then how would I know that I have to change the subdomain in order to get there?
For what it's worth, Gitlab is a UI nightmare compared to Sourcehut. So I very much value your emphasis on the clean and simple.
>What's you beef with Sourcehut?
It's more difficult to keep up with a project that I find interesting. That's literally my only problem with it.
I want to be notified of new releases. The only option Sourcehut has right now is subscribing via RSS to every single commit.
I also don't want to have to bookmark every project I find interesting. I like that Github lets you star projects and then search or filter your starred projects. This is slightly less important for me though.
It's more difficult to keep up with a project that I find interesting. That's literally my only problem with it.
I want to be notified of new releases. The only option Sourcehut has right now is subscribing via RSS to every single commit.
I also don't want to have to bookmark every project I find interesting. I like that Github lets you star projects and then search or filter your starred projects. This is slightly less important for me though.
Projects are encouraged to have -announce mailing lists, which you can subscribe to for announcements.
Take this as you will: I am in my late 20's and have never intentionally signed up for a mailing list in my life. Not sure why. I guess I've just never thought of my email inbox as a social hub that connects services. I pretty much just use my email as a way to reset passwords.
Yah I immediately looked everywhere for examples, even checked out the presentation, demo links, no images of what this graphical library produces.
yea i agree, trying to look at the code etc on sourcehut was just painful the first thing i said to myself was "wish this was on github" then came here to see i wasn't alone in that sentiment!
this looks great, exactly what I need. I'll go try it out and see if it lives up to the promise :)
I guess, though, that there aren't any widget libraries for it, yet? Anyone know different?
I guess, though, that there aren't any widget libraries for it, yet? Anyone know different?
Very badly chosen name. GIO is already GLib's filesystem abstraction API: https://developer.gnome.org/gio/
Tons of programming projects has the name of an existing project. Go itself is an illustration of that fact.
That'll be fun to get Google results for. I suppose we can be glad they didnt go for Go + UI, you know, GUI.
Other projects that I am considering to use: https://github.com/wailsapp/wails (looks very decent and I would be happy to use Vue.js for a UI bit) and Flutter with desktop support (https://github.com/google/flutter-desktop-embedding, in this case it's not directly using Go but you can bind them together).
If this would mean that I can just use Go for everything - that's great but the only concern for me I guess is just the availability of examples and widgets. I don't consider myself a good UI designer so relying on libraries is important :)