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 :)
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.
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.
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.
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.
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-,
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
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.
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.
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.
-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.
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.
>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...
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.
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.
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.
>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.
>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.
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.
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.
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!
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?
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).
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.
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.
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...
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...
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 :)