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 :)
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.
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.
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.
Best way to view a preview of it: https://youtu.be/9D6eWP4peYM?t=113
"Hosting Gio on Sourcehut is an experiment just as Gio itself is."
Yeah, nice experiment. Now maybe try GitHub?
Nor is this thing used here a "great alternative".
By all means encourage different hosting platforms, but maybe in a tone more relevent to the current decade.
Also, please quit it with the $ instead of S trope, it's really immature.
>"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 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
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.
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.
-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.
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.
Rude to whom? Styles? UX? I'm pretty sure even the graphic/UX designers involved (if any) would agree.
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?
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.
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...
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.
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.
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.
Also, Sourcehut does have web-based bug submissions, and a nice tutorial for setting up terminal-based PR submissions.
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).
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.
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.
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.
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?
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?
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 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.
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).
I guess, though, that there aren't any widget libraries for it, yet? Anyone know different?